O que é o Couchbase

Por que o Couchbase?

O Couchbase Server é um banco de dados de documentos JSON distribuído e de código aberto. Ele expõe um armazenamento de chave-valor escalável com cache gerenciado para operações de dados de menos de um milissegundo, indexadores criados especificamente para consultas eficientes e um mecanismo de consulta poderoso para executar consultas semelhantes a SQL. Para ambientes móveis e de Internet das Coisas, o Couchbase também é executado nativamente no dispositivo e gerencia a sincronização com o servidor.

O Couchbase Server é especializado para fornecer gerenciamento de dados de baixa latência para aplicativos interativos da Web, móveis e IoT em grande escala. Os requisitos comuns que o Couchbase Server foi projetado para atender incluem:

Interface de programação unificada
Consulta
Pesquisar
Celular e IoT
Análise
Mecanismo de banco de dados principal
Arquitetura escalável
Arquitetura que prioriza a memória
Big data e integrações SQL
Segurança de pilha completa
Implantações de contêiner e nuvem
Alta disponibilidade

Muitos bancos de dados são capazes de atender a um ou mais desses requisitos, mas exigem compensações ao serem executados em produção com aplicativos de missão crítica em escala de internet. Por exemplo, uma solução pode fornecer flexibilidade de modelo de dados, mas pode não ter a capacidade de adicionar ou remover nós sem afetar o tempo de atividade ou o desempenho. Outra solução pode demonstrar boa escalabilidade de gravação sem poder indexar ou alterar o modelo de dados em tempo real. O Couchbase Server foi projetado para fornecer uma experiência produtiva de desenvolvedor e administração, além de fornecer desempenho em escala, seja na nuvem, em um contêiner, no local ou em um dispositivo de borda.

Referência de desempenho do Nosql

Novo benchmark comparando MongoDB, DataStax e Couchbase Server demonstra o Couchbase como o banco de dados NoSQL mais escalável e com melhor desempenho.

Padrão de comparação baseado em nós .

De acordo com CAP Theorem Couchbase .

Teorema Cap

O Couchbase está no diagrama CP e AP.

Detalhes do diagrama de CP e AP do Couchbase.

O que é XDCR?

Cross Data Center Replication (XDCR) replica dados entre clusters:isso fornece proteção contra falhas de data center e também fornece acesso a dados de alto desempenho para aplicativos de missão crítica distribuídos globalmente.

O XDCR replica dados de um bucket específico no cluster de origem para um bucket específico no cluster de destino. Os dados do bucket de origem são enviados para o bucket de destino por meio de um agente XDCR, executado no cluster de origem, usando o Database Change Protocol. Qualquer bucket (Couchbase ou Ephemeral) em qualquer cluster pode ser especificado como origem ou destino para uma ou mais definições de XDCR.

Uma descrição arquitetônica completa do XDCR é fornecida em Cross Data Center Replication (XDCR). Você pode querer se familiarizar com as informações fornecidas antes de executar as rotinas fornecidas nesta seção.

Estrutura básica do Xdcr;

Pré-requisitos;

Confirme se seu cluster está dimensionado corretamente e é capaz de lidar com novos fluxos XDCR. Por exemplo, o XDCR precisa de 1 a 2 núcleos de CPU adicionais por fluxo e, em alguns casos, também exigirá mais RAM e recursos de rede. Se um cluster não for dimensionado adequadamente para a carga de trabalho existente mais os novos fluxos XDCR, o XDCR poderá competir pelos recursos do servidor e ter um impacto negativo no desempenho geral.
O Couchbase Server usa a porta TCP/IP 8091 para trocar informações de configuração do cluster. Se você estiver se comunicando com um cluster de destino por uma conexão dedicada ou pela Internet, verifique se todos os nós nos clusters de destino e de origem podem se comunicar entre si pelas portas 8091 e 8092.

Portas listadas por caminho de comunicação

XDCR (cluster a cluster)

Versão 1 (CAPI)
- Não criptografado :8091, 8092
Versão 2 (XMEM)
- Não criptografado :8091, 8092, 11210
- Criptografado :11207, 18091, 18092

O Couchbase armazena dados em disco e em RAM. O comportamento padrão é gravar o documento no disco em algum momento arbitrário (geralmente rapidamente) após o armazenamento na RAM. Isso deixa uma janela curta em que a falha do nó pode resultar em perda de dados.

De qualquer forma, após a gravação na RAM, o documento será gravado no disco. O Couchbase mantém uma fila de gravação de disco que você pode verificar na página de relatório de métricas no console de gerenciamento. Agora, o CB sincroniza gravações no cluster e acredito que uma gravação será sincronizada em um cluster antes que o Couchbase reconheça que a gravação aconteceu (por exemplo, antes que o método de gravação retorne ao chamador).

Se você tiver mais documentos do que a RAM disponível, apenas os documentos acessados com mais frequência serão armazenados na RAM para recuperação rápida, com todos os outros sendo “despejados” para o disco.

Conselhos;

Quando o tamanho do bucket foi reduzido de 200 gb para 10 gb na origem, a replicação ficou mais rápida. Em outras palavras, se o tamanho do bucket for alto e embora todos os dados estejam em ram, vi que a replicação tinha um intervalo de 10 segundos.

Origem e destino têm a mesma configuração linux e os mesmos recursos. Este é apenas um conselho.

O residente do bucket de produção deve ser %100. Porque a velocidade de replicação é 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

Conselhos;

Recomendo que a origem e o destino tenham a mesma configuração e tenham os mesmos recursos.

São configurações de bucket, configuração de cluster, cpu, memória, qualidade de disco etc.

A replicação Xdcr é apenas replicação de dados. Antes da replicação , você deve criar metadados de bucket.

Se você quiser, você cria usuário, índice, visualização, evento etc.

Como informações adicionais;

Você pode fazer a replicação xdcr na versão da comunidade.

Você pode fazer a replicação xdcr na versão corporativa. Isso precisa de licença adicional. Se você não usar o modo de espera como um produto, não é uma taxa alta.

outros conectores do Couchbase para XDCR; Elasticsearch, Hadoop, Kafka, Spark, Talend, SQL (ODBC / JDBC)

O gerenciamento do Couchbase pode ser feito via WEB UI, REST API e CLI. Em particular, a interface do usuário da web é muito simples e direta de usar. Você pode fazer muitas transações e consultas operacionais por meio da interface do usuário.

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

As configurações de memória para configurações de cluster Xdcr são fornecidas de acordo com o valor de memória do servidor.

Deve ser tamanho livre para a memória do servidor.

O Xdcr precisa de memória adicional no cluster de produção.

Replicação de vários buckets de base de sofá é possível.

Exemplo de operação simples de replicação XDCR;

Guia Xdcr selecionada na página inicial do couchbase.

A guia Adicionar cluster remoto está selecionada na guia xdcr selecionada.

A operação de adição de cluster remoto é feita seguindo .

A guia Adicionar replicação está selecionada na guia xdcr selecionada .

A operação de replicação de bucket é feita seguindo .

Melhores parâmetros para desempenho xdcr. Mas pode ser definido novamente para o seu sistema.

Status da replicação na guia xdcr da origem (prod)

Estatísticas de replicação de bucket

Desempenho de replicação no alvo;

Desempenho de replicação na origem;

Referências;

1-) https://resources.couchbase.com/nosql_comparison_web/altoros-nosql-performance-benchmark

2-) https://docs.couchbase.com/

3-) https://www.businesswire.com/news/home/20140625005778/en/Couchbase-Blows-Past-Competition-in-NoSQL-Performance-Benchmark

4-) https://www.quora.com/What-is-the-relation-between-SQL-NoSQL-the-CAP-theorem-and-ACID

Fatih Genciali – Certificações Couchbase

Replicação Couchbase XDCR – Passo a passo – Melhores práticas