Comparação entre o Couchbase e o CosmosDB

A Microsoft tem gerado muito burburinho desde o lançamento do CosmosDB. Ele é basicamente uma reformulação da marca Amazon DocumentDB com alguns novos recursos interessantes. Vamos nos aprofundar um pouco mais nele e explorar sua estratégia, documentação, o que os desenvolvedores têm falado sobre ele e como ele se compara ao Couchbase Server.

Um banco de dados para governar todos eles?

Em palavras simples, a Microsoft afirma que o CosmosDB é um banco de dados NoSQL capaz de fazer literalmente tudo: É um banco de dados de documentos, armazenamento colunar, um armazenamento de valores-chave e um banco de dados de gráficos. Tudo isso graças a uma abstração do formato de dados chamada ARS (atom-record-sequence).

Um bom sinal do trabalho da Microsoft é como os dados são organizados de forma diferente de acordo com cada modelo. Primeiro, você precisa escolher a API que gostaria de usar (SQL, API do MongoDB, Microsoft Azure Table, Cassandra ou Gremlin) e mantê-la, pois ela não pode ser alterada posteriormente. Atualmente, você ainda pode tentar acessar alguns modelos por meio da API do DocumentDB. O CosmosDB usa internamente um formato JSON decorado para armazenar seus dados.

Parece que a Microsoft quer competir com a maioria dos bancos de dados NoSQL existentes, o que é uma estratégia realmente arriscada, pois podemos ter ultrapassado a era de ouro de um único banco de dados solução de banco de dados para tudo. Há grandes benefícios em escolher armazenamentos especializados, e esse é o caminho que a maioria dos aplicativos tem seguido atualmente com o surgimento do persistências poliglotas. E tudo em um Uma solução como o CosmosDB pode ser boa para aplicativos de baixa demanda, mas todas essas abstrações têm um custo e, em última análise, afetarão a simplicidade, o desempenho e serão limitadas em termos de recursos.

Couchbase vs CosmosDB - Comparando maçãs com "maçãs"

Tentarei limitar minha comparação com o CosmosDB, concentrando-me principalmente nos cenários que fazem sentido para comparar as duas tecnologias. A tabela abaixo tenta mostrar algumas das diferenças lado a lado:

Conclusão

Acho que este é o primeiro artigo comparando o CosmosDB com outro banco de dados. Levei um bom tempo para examinar uma grande quantidade de documentação, feedbacks de desenvolvedores e alguns webinars.

Meu sentimento, em geral, é que o CosmosDB tem uma ótima visão, mas atualmente ainda é imaturo em alguns aspectos. A documentação e os backups, por exemplo, não são um de seus pontos fortes, o que é uma consequência natural da criação de algo que se concentra em vários campos ao mesmo tempo. O banco de dados da Microsoft também traz muitas inovações, sendo uma das mais proeminentes os novos níveis múltiplos de consistência eventual: Estabilidade limitada, Sessão, Prefixo consistente e Eventualmente consistente.

O fato de que Sessão é definido como a consistência padrão diz muito sobre a maneira recomendada de usar o CosmosDB. Também nos dá dicas de que essa pode não ser a melhor solução se você precisar de uma consistência de dados forte.

Não consegui encontrar nenhuma menção a mecanismos de armazenamento em cache no CosmosDB, portanto, presumo que ele não seja uma parte importante do banco de dados. O problema é que o armazenamento em cache é crucial para o bom desempenho em bancos de dados altamente consistentes, e o fato de a memória ser a primeira é um dos motivos pelos quais o Couchbase Server é extremamente rápido.

O CosmosDB não fornece índices otimizados para memória e, por padrão, todos os campos são indexados em seus índices secundários globais (GSI). Isso me parece um exagero, pois ainda acho que é mais fácil especificar quais campos quero indexar do que especificar quais campos não quero. É claro que você não precisa necessariamente remover esses campos do índice, mas não se esqueça de que será cobrado por isso.

A fragmentação parece ser, no momento, uma das coisas mais complicadas no CosmosDB. As partições são movidas automaticamente entre os nós, mas você ainda precisa especificar uma chave de partição. A desvantagem dessa abordagem é que cada partição é indivisível com um tamanho máximo de 10 Gb. Se você escolher uma chave de partição ruim, muitos documentos acessados com frequência podem acabar na mesma partição, o que limita a taxa de transferência de suas leituras/gravações pela capacidade do nó em que a partição está armazenada.

A chave de partição também é imutável, portanto, para alterá-la, será necessário copiar todos os seus dados para outra coleção. No Couchbase, nós distribuir seus documentos uniformemente entre os vBuckets para evitar esse problema e também para aumentar o desempenho de suas leituras/gravações.

Atualmente, a limitação é feita apenas pelo aumento das unidades de solicitação (RUs), que é um padrão comum para bancos de dados totalmente gerenciados (no DynamoDB, por exemplo, a limitação é feita pelo aumento das unidades de capacidade de leitura/gravação). O desafio dessa abordagem é que ela não é um preditor muito bom do desempenho da consulta e torna ainda mais difícil impulsionar apenas um comportamento específico, como aumentar apenas a capacidade de gravação.

A Microsoft se esforçou muito para tentar tornar o provisionamento de RUs fácil de entender, mas encontrei muitos comentários de desenvolvedores subestimando suas RUs (como aqui ou aqui ) e acabar com uma conta muito mais alta do que o esperado. Em geral, o padrão que eu vi de provisionamento no CosmosDB é baseado principalmente em tentativa e erro. No Couchbase, a limitação é muito flexível e pode ser feita por meio de escalonamento vertical/horizontal, executando serviços específicos de acordo com o hardware do nó, mantendo os índices na memória etc.

A Microsoft também está claramente tentando convencer os usuários do MongoDB a migrar para o CosmosDB. Eles até fornecem um conector bastante compatível para facilitar a migração. O problema é que a causa principal do motivo pelo qual alguns usuários estão dispostos a migrar para outros bancos de dados se deve aos problemas de escalabilidade e desempenho do MongoDB. Sabemos muito bem disso porque muitos desses usuários acabam migrando para o Couchbase Servere o desempenho do CosmosDB não parece ser uma grande vantagem, pelo menos não por um custo razoável.

A Microsoft fornece uma versão local limitada para desenvolvimento, mas até o momento ela é executada somente em máquinas Windows.

O CosmosDB também oferece uma distribuição de dados global com botão de pressão que simplifica muito a replicação de dados em vários locais do mundo. No entanto, esse é um recurso que não é usado diariamente para exigir tamanha simplicidade; ele também poderia ser facilmente obtido em questão de minutos no Couchbase Server, sem a limitação de ser executado em uma única nuvem.

Em resumo, concordo com o ponto de vista do CosmosDB de que a consistência eventual é uma definição muito ampla. Seus novos modelos de consistência permitem que o desenvolvedor escolha o nível de consistência que seu aplicativo tolera.

Os motivos para usá-lo são praticamente os mesmos mencionados em meu artigo sobre o DynamoDB. A principal diferença, é claro, é que o CosmosDB é muito mais flexível do que o DynamoDB. No momento, ele é um banco de dados multiuso médio para aplicativos que exigem desempenho médio com consistência forte. Ele também é facilmente se integra a alguns recursos do Azure Functions.

O CosmosDB ainda carece de casos de uso/clientes famosos, mas tem o potencial de se destacar em aplicativos com consistência eventual, já que esse parece ser seu foco principal. Porém, quando se trata de aplicativos de média/alta exigência com consistência forte, o Couchbase Server é, de longe, a melhor opção, tanto do ponto de vista do preço quanto do desempenho.

É difícil chegar a uma referência justa entre esses dois bancos de dados, pois não está claro, por exemplo, quantos servidores estão em execução quando você provisiona 30.000 RUs no CosmosDB, portanto, a maneira mais fácil de prever o desempenho esperado é por meio de sua arquitetura/características.

Assim como o DynamoDB, o preço do CosmosDB é atraente se você tiver um banco de dados pequeno com poucas leituras/gravações por segundo. Mas o qualquer coisa acima disso com um bom custo: 200.000 documentos de 45kb, com 4 gravações/segundo e 40 leituras/segundo custarão pelo menos US$ 2.500.

A calculadora deles não considera o modelo de consistência que você vai usar, portanto, é necessário adicionar alguns dólares a mais a esse número para a consistência forte. Nessa configuração, o custo do CosmosDB é pelo menos o dobro do preço que você gastaria para executar o Couchbase EE no Amazon Web Services com nossa arquitetura recomendada (que é capaz de lidar com mais do que isso)

Como mencionei no início do artigo, há muitas vantagens em escolher armazenamentos especializados para cada finalidade específica, e o Couchbase Server realmente se destaca por oferecer alto desempenho com forte consistência.

Se você tiver alguma dúvida, sinta-se à vontade para me enviar um tweet para @deniswsrosa