Modelos de Consistência de Dados e Desempenho: Couchbase vs. CockroachDB

Decisões de design influenciadas pelo Teorema CAP

O teorema CAP afirma que um banco de dados não pode fornecer simultaneamente todas as três garantias a seguir:

• Cconsistência (as informações mais recentes estão sempre disponíveis em todos os lugares)
• ADisponibilidade (cada solicitação de leitura e escrita recebe uma resposta)
• PTolerância a particionamento (pense nisso como uma forma de tolerância a falhas)

No teorema CAP para bancos de dados, a maioria dos bancos de dados precisa persistir o estado e o valor de seus dados. Os dados precisam de um contêiner e de um sistema host. Mas executar uma única cópia dos dados em um único host só funciona se o host tiver eletricidade. E os dados só podem estar disponíveis no host antes e depois de uma queda de energia se forem persistidos em um armazenamento capaz de tolerar a falta de eletricidade. Essas duas necessidades geram a exigência de fazer cópias dos dados e armazená-las em vários hosts e unidades de armazenamento. Assim, clusters são necessários para Partição tolerância a partições (o P no teorema CAP).

Portanto, se você precisa de tolerância a partições, as escolhas para bancos de dados distribuídos são entre Consistência e Disponibilidade. A consistência exige que as gravações em cada nó ou partição de dados sejam consistentes entre si em todo o cluster, porque a integridade dos dados é a coisa mais importante. O CockroachDB gosta de citar exemplos de dados importantes como “os códigos nucleares”.” 

A disponibilidade é o outro atributo do CAP que um banco de dados deve suportar para a confiabilidade operacional – assim como a Partição, o banco de dados é inútil se você não puder encontrá-lo. Em muitos casos, é importante estar sempre “ligado” e nunca perder uma solicitação para salvar ou recuperar os dados. Tanto para pessoas quanto para incontáveis aplicativos, um banco de dados indisponível é um obstáculo intransponível. Portanto, para sistemas AP, a experiência é a coisa mais importante.

O CockroachDB é baseado em CP, o Couchbase é Variável de CP para AP

O CockroachDB é um banco de dados baseado em CP; toda escrita no CockroachDB é transacional e replicada de acordo com o mecanismo baseado em consenso Raft protocolo para discos contendo intervalos de dados de Chave/Valor. Portanto, o CockroachDB é um banco de dados extremamente fortemente consistente. O ótimo blog deles explica que eles “quase” conseguem dar suporte O “Strict Serializable” de Jepsen” nível de consistência em seu banco de dados.

O Couchbase é de fato um banco de dados fortemente consistente também, mas oferece variáveis para permitir que ele próprio modifique os níveis de consistência em prol da disponibilidade, transformando-o em um sistema AP. A consistência ainda pode ser alcançada em milissegundos por meio de replicação assíncrona em um cluster, devido ao seu design em memória. Em contrapartida, o Couchbase concentra-se em entregar desempenho extremamente alto, capacidade de ajuste e disponibilidade. Entregar baixa latência para aplicações é um princípio fundamental de design.

A força do Cockroach é o foco na transacionalidade por meio de um design de cluster escalável. A força do Couchbase é o foco no desempenho e na flexibilidade em escala. A principal preocupação deles com uma aplicação é a integridade dos dados, enquanto a nossa é como os dados são usados (muitas vezes por pessoas). Os dados não dizem quando estão com o valor errado, mas as pessoas dirão quando sua aplicação estiver lenta ou indisponível.

Transações ACID

Do ponto de vista transacional, o Couchbase não está seguindo o protocolo RAFT, mas os princípios são os mesmos. No entanto, o Couchbase oferece, e recentemente obteve aprovação de patente para, multidocumento Transações ACID para documentos JSON. Ao contrário do CockroachDB, esses recursos são ajustáveis para durabilidade e níveis de isolamento. De acordo com Jepsen, as transações podem ser isoladas para apoiar Leituras Atômicas Monotônicas, que é o nível mais alto de isolamento oferecido a sistemas sempre disponíveis.

Dimensionamento de clusters por meio de Mapas de Localização de Dados

Ambos os bancos de dados distribuídos escalam bem. O CockroachDB escala seus nós definindo clusters raft (geralmente três) de intervalos de dados de chave/valor em uma partição ou armazenamento de dados. Um nó do CockroachDB pode hospedar tanto líderes quanto réplicas dos intervalos de dados em seu armazenamento, e o tamanho dos intervalos é gerenciado e particionado automaticamente. A parte inteligente do CockroachDB é que esses intervalos de dados KV baseados em raft são pequenos e facilmente replicáveis para outros nós. Assim, uma instância EC2 pode hospedar muitos conjuntos de intervalos de dados de um líder e duas réplicas. 

A camada de distribuição da arquitetura deles é o que cada nó no CockroachDB usa para encontrar a localização dos dados da aplicação usando sua “estrutura de mapa ordenado monolítico”. A estrutura em árvore desse mapa é chamada recursivamente e armazena em cache as localizações no nó. Em seguida, as RPCs enviam solicitações de consulta em lote para o nó que hospeda o líder da faixa raft.

O CockroachDB foi projetado de forma que cada nó seja homogêneo, exija pouca configuração e todos os nós façam o mesmo tipo de trabalho. Eles caracterizam seu design de disponibilidade como “disponibilidade multi-ativa”.”

Design de cluster ativo-ativo

O Couchbase suporta um design de cluster ativo-ativo onde qualquer membro do cluster pode receber uma gravação ou uma leitura. Essa flexibilidade é possibilitada por duas decisões de design. Primeiro, de forma semelhante ao CockroachDB, a localização dos dados do Couchbase é gerenciada pelo cluster. Mas, ao contrário do CockroachDB, que exige que cada nó para gerenciar, consultar e fazer cache do mapa, o Couchbase entrega o mapa do cluster ao aplicativo dentro do SDK do Couchbase. Dessa forma, a aplicação sempre sabe onde seus dados estão, eliminando consultas de localização que frequentemente drenam os recursos da infraestrutura. O Couchbase reduz o tráfego ruidoso dentro do banco de dados para que ele possa armazenar em cache o trabalho real. Uma explicação das diferenças pode ser encontrada neste apresentação de processamento de dados baseado em nuvem.

Os recursos de replicação e particionamento automático do Couchbase são gerenciados de forma semelhante ao Cockroach — os vBuckets dividem os dados do Couchbase em partições para gerenciamento de armazenamento e replicação. O mapa do cluster do Couchbase informa à aplicação onde o nó ativo gravável para o vBucket existe e onde suas réplicas estão localizadas. Em caso de falha de um vBucket ativo, uma réplica assume o controle e se torna o conjunto ativo e gravável de documentos. Em seguida, uma réplica de substituição é construída e preenchida. Toda a replicação intra-cluster (e a replicação inter-cluster via XDCR) ocorre na memória e seu desempenho é ajustável.

Cache em memória e otimização de desempenho

O Blog do CockroachDB explica o consumo de memória, pois ela pode ser usada simultaneamente para vários tipos de atividades de cache, como o cache do RocksDB (que contém os dados de chave-valor para um intervalo de dados), o mapa que localiza os nós onde os líderes de intervalos de dados estão hospedados, conexões de sessão de clientes, canais de consulta para execução de consultas SQL, operações de consulta SQL e outras atividades de cada camada arquitetônica. Naturalmente, quanto mais rápido for a CPU do host, mais rápidas se tornam algumas operações. Ainda assim, parece não haver maneira de equiparar o desempenho de recursos a operações específicas, como o dimensionamento multidimensional do Couchbase.

Assim como o CockroachDB, no núcleo do Couchbase há um armazenamento de dados Chave/Valor de alto desempenho (chamado Magma), que suporta acesso de alta velocidade aos dados. O Couchbase adicionalmente se baseia em seu memcached raízes, oferecendo processamento em memória não apenas para este acesso Chave/Valor, mas também para todas as operações internas, incluindo replicação intra-cluster para tolerância a falhas, replicação inter-cluster (XDCR) para localidade geográfica, bem como operações de consulta, busca, análise e eventos. Mas, ao contrário do CockroachDB, o Couchbase tem desempenho configurável, de modo que qualquer um desses serviços do Couchbase pode ter seu desempenho ajustado à sua infraestrutura de hospedagem e aos requisitos da aplicação. Se o serviço de acesso a dados precisar de mais memória ou CPU, dê a ele mais nós, RAM ou CPU. Você pode fazer o mesmo com todos os serviços independentes do Couchbase. Esse recurso é chamado escalonamento multidimensional, e é exclusiva do Couchbase.

Com o dimensionamento multidimensional do Couchbase, os serviços de replicação de dados e acesso podem ter seu próprio conjunto de nós dedicados e alocações de memória, assim como cada um dos serviços de consulta, indexação, busca, "eventing" e análise.

Suporte a consultas SQL

Ambos os bancos de dados oferecem suporte a SQL. No entanto, o CockroachDB oferece suporte à API do PostgreSQL, a estruturas de esquema e ao ANSI SQL. O Couchbase não exige estruturas de esquema, mas elas estão disponíveis. Da mesma forma, o Couchbase não exige tipagem de dados forte, nem oferece suporte a restrições de esquema específicas dentro do banco de dados, deixando para o desenvolvedor do aplicativo a responsabilidade de implementá-las.

O Couchbase usa JSON como seu formato de acesso a dados flexível e facilmente modificado, e o estendeu para dar suporte a Pesquisa de Texto Completo (Full-Text Search) e estruturas de Séries Temporais (Time Series), entre outros. Essa extensibilidade dá ao Couchbase a vantagem de poder realizar o trabalho de até seis produtos diferentes. O Couchbase também oferece mecanismos de serviços para eventos em JavaScript e Python, Funções Definidas pelo Usuário, um otimizador de consultas baseado em custo para SQL++ (SQL para JSON, anteriormente chamado de N1QL), agregações analíticas em dados ativos e realização de backups do banco de dados. As interfaces para esses serviços são intencionalmente intuitivas para ajudar na integração rápida, por exemplo, usando SQL++ já que ele opera de forma idêntica ao SQL para a maioria dos usuários.

Replicação e sincronização

O CockroachDB não oferece suporte à replicação entre data centers, mas pode implantar nós de cluster em diferentes regiões geográficas. O Couchbase oferece suporte à consistência eventual para o XDCR e usa um método de resolução de conflitos baseado em CAS (Check and Swap) quando são encontrados documentos com o mesmo valor CAS carimbado por HCL (relógio híbrido local). Nesse caso, o documento acessado mais ativamente ou o mais recente pode ser especificado como o vencedor. O CockroachDB também usa um HCL como seu carimbo de data/hora para consistência e resolução de conflitos. O Couchbase também oferece recursos de sincronização móvel para seu banco de dados móvel Couchbase Lite.

Lendo dados desatualizados

Os recursos de replicação, incluindo aqueles para manter a consistência de leitura e escrita (Serializada para o CockroachDB, Visão Atômica Monotônica para transações distribuídas do Couchbase) e qualquer outra atividade no CockroachDB, são tratados como uma transação com garantias ACID. Para leituras, o CockroachDB oferece ambos:

• Fortemente consistente (“não obsoleto”) lêO tipo de leitura padrão e mais comum, eles passam pelo arrendatário onde essas leituras veem todas as gravações realizadas por escritores que se confirmaram antes que a transação de leitura começasse. Elas sempre retornam dados corretos e atualizados.
• Leituras desatualizadasÚtil em situações em que você pode se dar ao trabalho de ler dados ligeiramente desatualizados em troca de leituras mais rápidas. Eles só podem ser usados em transações somente leitura que usam o A PARTIR DA HORA DO SISTEMA cláusula. Eles não precisam passar pelo locatário, pois garantem consistência fazendo a leitura de uma réplica local em um carimbo de data/hora que nunca é superior ao carimbo de data/hora de fechamento.

O Couchbase é um banco de dados fortemente consistente cujo nível de isolamento deve ser considerado Visão Atômica Monotônica para leituras transacionais. O Couchbase pode retornar dados desatualizados quando não se usam transações ACID, mas isso é controlável pelo desenvolvedor.  

Qual banco de dados escolher?

Se transações duráveis para 100% dos seus dados forem sua principal (ou única) preocupação, opte pelo CockroachDB. No entanto, devido à sua rigidez — por se tratar de um projeto relacional e de uma instalação monolítica —, ele não é facilmente ajustável às necessidades de desempenho e escalabilidade do seu aplicativo, exceto no que diz respeito à escalabilidade de transações e armazenamento. Por isso, é provável que o CockroachDB apresente problemas de desempenho imprevistos, cuja única solução seja o escalonamento vertical — por meio da adição de RAM ou CPU —, além do escalonamento horizontal para armazenamento. Como utiliza um projeto baseado em esquema, será mais difícil evoluir e fazer alterações depois que o banco de dados for implantado.

Se desempenho, flexibilidade, adaptabilidade da aplicação, satisfação do usuário, escala geográfica, custo-benefício ou mobilidade forem motivo de preocupação, use o Couchbase. O Couchbase oferece inúmeros recursos de ajuste de desempenho e otimização de infraestrutura que podem maximizar a eficiência do seu ambiente. O Couchbase entregará tempos de latência impressionantemente baixos que não se deteriorarão sob carga ou em escala. Isso garante que o Couchbase possa realizar mais trabalho com menos recursos e também seja mais custo-efetivo no geral.

O design baseado em JSON do Couchbase permite que a equipe de desenvolvimento controle as estruturas de dados usadas pela aplicação, e modificações nessas estruturas podem ser feitas de forma contínua, mesmo após a aplicação estar em produção. O Couchbase oferece transações ACID distribuídas e multi-documento, mas não as torna obrigatórias. Essa escolha de design permite que os desenvolvedores equilibrem garantias transacionais com necessidades de desempenho e disponibilidade. 

O Couchbase oferece XDCR e serviços de aplicativos móveis, incluindo um banco de dados embutido, o Couchbase Lite. Em última análise, o Couchbase entrega dados mais perto de onde um aplicativo irá consumi-los e suporta mais padrões de design de acesso a dados (Chave/Valor, JSON, Busca, relacional, série temporal, analítico e de eventos), oferecendo aos desenvolvedores mais liberdade de recursos sem introduzir mais complexidade arquitetural. O Couchbase oferece às equipes de desenvolvimento mais opções e liberdade para construir o que precisam.  

Ambos são ótimos bancos de dados, mas por motivos diferentes.