Cos'è Couchbase

Couchbase Server è un database di documenti JSON distribuito e open source. Espone un archivio chiave-valore a scalabilità orizzontale con cache gestita per operazioni sui dati inferiori al millisecondo, indicizzatori appositamente creati per query efficienti e un potente motore di query per l'esecuzione di query di tipo SQL. Per gli ambienti mobile e Internet of Things, Couchbase funziona anche in modo nativo sul dispositivo e gestisce la sincronizzazione con il server.

Perché Couchbase?

Couchbase Server è specializzato nella gestione dei dati a bassa latenza per applicazioni Web interattive, mobili e IoT su larga scala. I requisiti comuni che Couchbase Server è stato progettato per soddisfare includono:

Interfaccia di programmazione unificata
Interroga
Cerca
Mobile e IoT
Analisi
Motore di base del database
Architettura a scalabilità orizzontale
Architettura incentrata sulla memoria
Big data e integrazioni SQL
Sicurezza completa
Distribuzioni di container e cloud
Alta disponibilità

Molti database sono in grado di soddisfare uno o più di questi requisiti, ma richiedono compromessi quando vengono eseguiti in produzione con applicazioni mission-critical su scala Internet. Ad esempio, una soluzione potrebbe offrire flessibilità del modello di dati ma potrebbe non essere in grado di aggiungere o rimuovere nodi senza influire sui tempi di attività o sulle prestazioni. Un'altra soluzione potrebbe dimostrare una buona scalabilità in scrittura senza essere in grado di indicizzare o modificare il modello di dati al volo. Couchbase Server è progettato per offrire un'esperienza di sviluppo e amministrazione produttiva, fornendo al contempo prestazioni su larga scala, nel cloud, in un container, in locale o su un dispositivo perimetrale.

Benchmark delle prestazioni di Nosql

Il nuovo benchmark che confronta MongoDB, DataStax e Couchbase Server dimostra che Couchbase è il database NoSQL più scalabile e con le migliori prestazioni.

Benchmark basato su nodi.

Secondo il teorema CAP Couchbase .

Teorema di Cap

Couchbase è sul diagramma CP e AP.

Dettaglio del diagramma Couchbase CP e AP.

Cos'è XDCR?

Cross Data Center Replication (XDCR) replica i dati tra cluster:questo fornisce protezione contro i guasti del data center e fornisce anche accesso ai dati ad alte prestazioni per applicazioni mission-critical distribuite a livello globale.

XDCR replica i dati da un bucket specifico nel cluster di origine a un bucket specifico nel cluster di destinazione. I dati dal bucket di origine vengono inviati al bucket di destinazione tramite un agente XDCR, in esecuzione sul cluster di origine, utilizzando il Database Change Protocol. Qualsiasi bucket (Couchbase o Ephemeral) su qualsiasi cluster può essere specificato come origine o destinazione per una o più definizioni XDCR.

Una descrizione architettonica completa di XDCR è fornita in Cross Data Center Replication (XDCR). Potresti voler familiarizzare con le informazioni fornite lì, prima di eseguire le routine fornite in questa sezione.

Struttura di base Xdcr;

Prerequisiti;

Conferma che il tuo cluster abbia le dimensioni corrette e sia in grado di gestire nuovi flussi XDCR. Ad esempio, XDCR necessita di 1-2 core CPU aggiuntivi per flusso e in alcuni casi richiederà anche più RAM e risorse di rete. Se un cluster non è dimensionato correttamente per il carico di lavoro esistente più i nuovi flussi XDCR, XDCR può competere per le risorse del server e avere un impatto negativo sulle prestazioni complessive.
Couchbase Server utilizza la porta TCP/IP 8091 per scambiare informazioni sulla configurazione del cluster. Se stai comunicando con un cluster di destinazione tramite una connessione dedicata o Internet, dovresti assicurarti che tutti i nodi nei cluster di destinazione e di origine possano comunicare tra loro sulle porte 8091 e 8092.

Porte elencate per percorso di comunicazione

XDCR (da cluster a cluster)

Versione 1 (CAPI)
- Non crittografato :8091, 8092
Versione 2 (XMEM)
- Non crittografato :8091, 8092, 11210
- Crittografato :11207, 18091, 18092

Couchbase memorizza i dati sia su disco che nella RAM. Il comportamento predefinito è scrivere il documento su disco in un momento arbitrario (di solito rapidamente) dopo l'archiviazione nella RAM. Ciò lascia una breve finestra in cui un errore del nodo può causare la perdita di dati.

In ogni caso, dopo aver scritto sulla RAM, il documento verrà eventualmente scritto su disco. Couchbase mantiene una coda di scrittura su disco che puoi controllare nella pagina del rapporto sulle metriche nella console di gestione. Ora, CB sincronizza le scritture nel cluster e credo che una scrittura verrà sincronizzata in un cluster prima che Couchbase riconosca che la scrittura è avvenuta (ad esempio prima che il metodo di scrittura ritorni al chiamante).

Se hai più documenti della RAM disponibile, solo i documenti a cui si accede più frequentemente verranno archiviati nella RAM per un rapido recupero, mentre tutti gli altri verranno "sfrattati" su disco.

Consigli;

Quando le dimensioni del bucket sono state ridotte da 200 GB a 10 GB nel codice sorgente, la replica è diventata abbastanza veloce. In altre parole, se la dimensione del bucket è elevata e anche se tutti i dati sono in ram, ho visto che la replica ha avuto un intervallo di 10 secondi.

Sorgente e destinazione devono avere la stessa impostazione Linux e le stesse risorse. Questo è solo un consiglio.

Il residente del bucket di produzione deve essere %100. Perché la velocità di replica è importante.

Bucket replication best settings ;

XDCR Source Nozzles per Node: 2 --> 8

XDCR Target Nozzles per Node: 2 --> 24

(Nozzles=Channel=parallel , as  cpu core)

XDCR Checkpoint Interval (sn): 1800 --> 60

Control frequency is low, but not as much as waiting in the queue. The higher this value, the longer it takes for XDCR queues to grow.

XDCR Batch Count: 500 --> 2000

It is beneficial to increase by 2.3 times. It also sends so many data groups at the same time.

XDCR Batch Size (kB): 2048 --> 8192

It is beneficial to increase by 2.3 times. At the same time, it sends such a large amount of data.

XDCR Failure Retry Interval: 10 --> 10

It is used for retry attempts in network errors.

XDCR Optimistic Replication Threshold: 256 --> 1024 --> 256 --> 128 

Increasing or decreasing this value appropriately can speed up replication, collect data above 1 mb and send it in bulk. But collection can be a waste of time and waiting in the queue.

This is the compressed document size in bytes. 0 - 2097152 Bytes (20MB). Default is 256 Bytes. XDCR retrieves metadata for documents larger than this size at once before copying the uncompressed document to a destination set. This option improves XDCR latency.

XDCR Statistics Collection Interval (ms): 1000 --> 1000

XDCR Logging Level: info --> info

Consigli;

Consiglio che origine e destinazione siano la stessa impostazione e abbiano le stesse risorse.

Questi sono l'impostazione del bucket, l'impostazione del cluster, la CPU, la memoria, la qualità del disco ecc.

La replica Xdcr è solo la replica dei dati. Prima della replica , devi creare metadati del bucket.

Se vuoi, crei utente, indice, vista, evento ecc.

Come informazione aggiuntiva;

Puoi eseguire la replica xdcr sulla versione community.

È possibile eseguire la replica xdcr sulla versione enterprise. Ciò richiede una licenza aggiuntiva. Se non usi lo standby come prod, non è una tariffa elevata.

Gli altri connettori di Couchbase per XDCR; Elasticsearch, Hadoop, Kafka, Spark, Talend, SQL (ODBC / JDBC)

La gestione di Couchbase può essere effettuata tramite WEB UI, REST API e CLI. In particolare, l'interfaccia utente web è molto semplice e immediata da usare. Puoi effettuare molte transazioni e query operative tramite l'interfaccia utente.

Replication Summary;

Stby=Xdcr=Target=Remote same term.

A different name xdcr cluster is established with the same features.

The buckets with the same name with the same features are created in the xdcr cluster.

In Prod, add remote server and xdcr information are entered in the xdcr tab.

Prod in xdcr tab with add remote cluster;

Cluster Name= Xdcr couchbase name

IP/Hostname= Xdcr ip / hostname

Username=Xdcr Admin username

Password=Xdcr Admin user password




Prod in xdcr tab with add bucket replication;

Replicate From Bucket = Bucket name in the prod

Remote Cluster = Added Xdcr name

Remote Bucket = Bucket name added in Xdcr

Le impostazioni di memoria per le impostazioni del cluster Xdcr sono fornite in base al valore della memoria del server.

Dovrebbe essere una dimensione libera per la memoria del server.

Xdcr necessita di memoria aggiuntiva nel cluster di produzione.

È possibile la replica di più bucket couchbase.