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:
-
- Consistência (as informações mais recentes estão sempre disponíveis em todos os lugares)
- Adisponibilidade (cada solicitação de leitura e gravação recebe uma resposta)
- PTolerância de 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 manter o estado e o valor de seus dados. Os dados precisam de um contêiner e de um sistema host. Mas a execução de uma única cópia de 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 elétrica se forem persistidos em um armazenamento que possa tolerar a falta de eletricidade. Essas duas necessidades geram o requisito de fazer cópias de dados e armazená-las em vários hosts e unidades de armazenamento. Assim, os clusters são necessários para Partição tolerância em um banco de dados (o P no teorema CAP).
Portanto, se você precisa ter tolerância de partição, as compensações para bancos de dados distribuídos estã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, pois a integridade dos dados é o mais importante. O CockroachDB gosta de chamar a atenção para exemplos de dados importantes, como "os códigos nucleares".
A disponibilidade é o outro atributo do CAP que um banco de dados deve suportar para ter confiabilidade operacional - como a partição, o banco de dados é inútil se você não conseguir encontrá-lo. Em muitos casos, é importante estar sempre "ligado" e nunca perder uma solicitação para salvar ou recuperar os dados. Tanto para as pessoas quanto para inúmeros aplicativos, um banco de dados indisponível é um obstáculo. Portanto, para os sistemas AP, a experiência é o mais importante.
O CockroachDB é baseado em CP, o Couchbase é variável de CP para AP
O CockroachDB é um banco de dados baseado em CPCada gravação no CockroachDB é transacional e replicada de acordo com o consenso baseado em RAFT para armazenamentos em disco que contêm intervalos de dados de chave/valor. Portanto, o CockroachDB é um banco de dados extremamente consistente. Seu excelente blog explica que eles são "quase" capazes de suportar "Serializável estrito" de Jepsen nível de consistência em seu banco de dados.
O Couchbase também é, de fato, um banco de dados altamente consistente, mas oferece variáveis que permitem modificar os níveis de consistência para disponibilidade, transformando-o em um sistema AP. A consistência ainda pode ser obtida em milissegundos por meio de replicação assíncrona entre um cluster devido ao seu design na memória. No comércio, o Couchbase se concentra em fornecer desempenho, capacidade de ajuste e disponibilidade extremamente altos. O fornecimento de baixa latência aos aplicativos é um princípio de design primário.
O ponto forte do Cockroach é seu foco na transacionalidade por meio de um design de cluster escalável. O ponto forte do Couchbase é seu foco no desempenho e na flexibilidade em escala. A principal preocupação deles com um aplicativo é a integridade dos dados, enquanto a nossa é como os dados são usados (geralmente por pessoas). Os dados não informam quando têm o valor errado, mas as pessoas informam quando o aplicativo está lento 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 recebeu aprovação de patente para, multi-documentos Transações ACID para documentos JSON. Ao contrário do CockroachDB, esses recursos podem ser ajustados para níveis de durabilidade e isolamento. De acordo com Jepsen, as transações podem ser isoladas para apoiar Leituras atômicas monotônicasque é o nível mais alto de isolamento oferecido aos sistemas sempre disponíveis.
Dimensionamento de clusters por meio de mapas de localização de dados
Ambos os bancos de dados distribuídos são bem dimensionados. O CockroachDB dimensiona seus nós definindo clusters de balsas (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. Portanto, uma instância do EC2 pode hospedar muitos conjuntos de intervalos de dados de líder e duas réplicas.
A camada de distribuição de sua arquitetura é o que cada nó do CockroachDB usa para encontrar o local dos dados do aplicativo usando sua "estrutura de mapa classificado monolítico". A estrutura em árvore desse mapa é chamada recursivamente e armazena em cache os locais no nó. Em seguida, os RPCs enviam solicitações de consulta em lote para o nó que hospeda o líder do intervalo de balsas.
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 projeto de disponibilidade como "disponibilidade multiativa".
Projeto de cluster ativo-ativo
O Couchbase oferece suporte ao design de cluster ativo-ativo, em que qualquer membro do cluster pode fazer uma gravação ou uma leitura. Essa flexibilidade é possível graças a duas decisões de projeto. Primeiro, semelhante ao CockroachDB, o local dos dados do Couchbase é gerenciado pelo cluster. Mas, diferentemente do CockroachDB, que exige que cada nó para gerenciar, consultar e armazenar em cache o mapa, o Couchbase fornece o mapa do cluster para o aplicativo no SDK do Couchbase. Dessa forma, o aplicativo sempre sabe onde estão os dados, eliminando as consultas de localização que geralmente esgotam os recursos da infraestrutura. O Couchbase reduz o tráfego ruidoso no 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 com base na 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 replicação e armazenamento. O mapa do cluster do Couchbase informa ao aplicativo onde existe o nó ativo gravável para o vBucket e onde estão localizadas suas réplicas. No caso de falha de um vBucket ativo, uma réplica assume o controle e se torna o conjunto de documentos ativo e gravável. Em seguida, uma réplica substituta é construída e preenchida. Toda a replicação intra-cluster (e a replicação inter-cluster via XDCR) ocorre na memória e pode ser ajustada em termos de desempenho.
Cache na memória e ajuste de desempenho
Blog do CockroachDB Isso explica o consumo de memória, pois ela pode ser usada simultaneamente para muitos tipos de atividades de cache, como o cache do RocksDB (que contém os dados KV de um intervalo de dados), o mapa que localiza os nós onde os líderes do intervalo de dados estão hospedados, as conexões de sessão dos clientes, os canais de consulta para executar consultas SQL, as operações de consulta SQL e outras atividades de cada camada arquitetônica. Obviamente, quanto mais rápida for a CPU do host, mais rápidas serão algumas operações. Ainda assim, parece não haver uma maneira de combinar o desempenho dos recursos com operações específicas, como o dimensionamento multidimensional do Couchbase.
Como o CockroachDB, o núcleo do Couchbase é um armazenamento de dados de chave/valor de alto desempenho (chamado Magma), que oferece suporte ao acesso de alta velocidade aos dados. Além disso, o Couchbase se baseia em seu memcached oferecendo processamento na memória não apenas desse acesso a chave/valor, mas também de todas as operações internas, inclusive replicação intra-cluster para tolerância a falhas, replicação inter-cluster (XDCR) para localidade geográfica, bem como operações de consulta, pesquisa, análise e eventos. Mas, ao contrário do CockroachDB, o Couchbase é configurável em termos de desempenho, de modo que qualquer um desses serviços do Couchbase pode ser adaptado à sua infraestrutura de hospedagem e aos requisitos do aplicativo. Se o serviço de acesso a dados precisar de mais memória ou CPU, forneça a ele mais nós, RAM ou CPU. Você pode fazer o mesmo com todos os serviços independentes do Couchbase. Esse recurso é chamado de escalonamento multidimensionale é exclusivo do Couchbase.
Com o dimensionamento multidimensional do Couchbase, os serviços de acesso e replicação de dados podem ter seu próprio conjunto de alocações dedicadas de nó e memória, assim como cada um dos serviços de consulta, indexação, pesquisa, eventos e análise.
Suporte a consultas SQL
Ambos os bancos de dados oferecem suporte para SQL. No entanto, o CockroachDB é compatível com a API do PostgreSQL, estruturas de esquema e 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 forte de dados, nem oferece suporte a restrições de esquema específicas no banco de dados, deixando para o desenvolvedor do aplicativo a tarefa de implementá-las.
O Couchbase usa JSON como formato de acesso a dados flexível e facilmente modificável e o ampliou para oferecer suporte a estruturas de pesquisa de texto completo e séries temporais, entre outras. Essa extensibilidade dá ao Couchbase a vantagem de ser capaz de fazer o trabalho de até seis produtos diferentes. O Couchbase também oferece mecanismos de serviço para eventos JavaScript e Python, funções definidas pelo usuário, um otimizador de consulta baseado em custo para SQL++ (SQL para JSON, anteriormente chamado de N1QL), agregações analíticas em dados ativos e backups do banco de dados. As interfaces para esses serviços são intencionalmente intuitivas para ajudar na rápida integração, por exemplo, usando o SQL++, pois 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 datacenters, mas pode implantar nós de cluster em diferentes regiões geográficas. O Couchbase oferece suporte à consistência eventual para 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 com carimbo HCL (relógio local híbrido). Nesse caso, o documento acessado mais ativamente ou o mais recente pode ser especificado como vencedor. O CockroachDB também usa um HCL como seu registro de data e 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.
Leitura de dados obsoletos
Os recursos de replicação, incluindo aqueles para manter a consistência de gravação e leitura (Serialized para CockroachDB, Monotonic Atomic View para transações distribuídas do Couchbase) e todas as outras atividades no CockroachDB são tratadas como uma transação com garantias ACID. Para leituras, o CockroachDB oferece ambos:
-
- Fortemente consistente ("não-válido") leituras: O tipo padrão e mais comum de leitura, eles passam pelo arrendatário em que essas leituras veem todas as gravações realizadas por gravadores que foram confirmadas antes do início da transação de leitura. Elas sempre retornam dados corretos e atualizados.
- Leituras obsoletas: Útil em situações em que você pode se dar ao luxo de ler dados ligeiramente obsoletos em troca de leituras mais rápidas. Eles só podem ser usados em transações somente de leitura que usam a função A PARTIR DA HORA DO SISTEMA cláusula. Eles não precisam passar pelo leaseholder, pois garantem a consistência lendo de uma réplica local em um registro de data e hora que nunca é maior que o carimbo de data/hora de fechamento.
O Couchbase é um banco de dados altamente consistente, cujo nível de isolamento deve ser considerado Visão atômica monotônica para leituras transacionais. O Couchbase pode retornar dados obsoletos quando não estiver usando transações ACID, mas isso pode ser controlado pelo desenvolvedor.
Qual banco de dados escolher?
Se as transações duráveis para 100% de seus dados forem sua principal (ou única) preocupação, escolha o CockroachDB. Mas, devido à sua inflexibilidade, por ser um projeto relacional e uma instalação monolítica, ele não é facilmente ajustável às necessidades de desempenho e dimensionamento do seu aplicativo, exceto pelo dimensionamento de transações e armazenamento. Por esse motivo, o CockroachDB provavelmente apresentará problemas de desempenho imprevistos, cuja única solução é dimensionar verticalmente adicionando RAM ou CPU, além de dimensionar horizontalmente o armazenamento. Como ele usa um design baseado em esquema, será mais difícil evoluir e mudar depois que o banco de dados for implantado.
Se o desempenho, a flexibilidade, a adaptabilidade do aplicativo, a satisfação do usuário, a escala geográfica, a relação custo-benefício ou a mobilidade forem uma preocupação, use o Couchbase. O Couchbase oferece vários recursos de ajuste de desempenho e otimização de infraestrutura que podem maximizar a eficiência do seu ambiente. O Couchbase fornecerá tempos de latência impressionantemente baixos que não se deteriorarão sob carga ou em escala. Isso garante que o Couchbase possa fazer mais trabalho com menos recursos e também ser mais econômico em geral.
O design baseado em JSON do Couchbase permite que a equipe de desenvolvimento controle as estruturas de dados usadas pelo aplicativo, e as modificações nessas estruturas podem ser feitas continuamente, mesmo depois que o aplicativo estiver em produção. O Couchbase oferece transações ACID distribuídas e com vários documentos, mas não as exige. Essa escolha de projeto permite que os desenvolvedores equilibrem as garantias transacionais com as necessidades de desempenho e disponibilidade.
O Couchbase oferece XDCR e serviços de aplicativos móveis, incluindo um banco de dados incorporável, o Couchbase Lite. Em última análise, o Couchbase fornece dados mais próximos de onde um aplicativo os consumirá e oferece suporte a mais padrões de design de acesso a dados (chave/valor, JSON, pesquisa, relacional, séries temporais, analítica e eventos), oferecendo aos desenvolvedores mais liberdade de recursos sem introduzir mais complexidade arquitetônica. O Couchbase oferece às equipes de desenvolvimento mais opções e liberdade para criar o que elas precisam.
Ambos são ótimos bancos de dados, mas por motivos diferentes.