Apache Cassandra vs. MongoDB

Apache Cassandra e MongoDB são bancos de dados NoSQL amplamente adotados, projetados para armazenar e gerenciar grandes quantidades de dados.

A popularidade desses dois sistemas de banco de dados se deve, em parte, à sua alta escalabilidade e disponibilidade. Ambos também são usados há mais de uma década: o Cassandra foi lançado como um projeto de código aberto em 2008; o lançamento do MongoDB ocorreu no ano seguinte.

Apesar das semelhanças, Apache Cassandra e MongoDB diferem consideravelmente com relação a seus modelos de dados, arquitetura e outros componentes. Essas diferenças fundamentais afetam seu desempenho em relação às principais características e podem influenciar os casos de uso de gerenciamento de dados aos quais eles atendem melhor.

Antes de comparar Apache Cassandra e MongoDB, convém estabelecer uma compreensão dos bancos de dados NoSQL.

Os bancos de dados NoSQL, também conhecidos como bancos de dados "não somente SQL" ou "não SQL", são bancos de dados distribuídos. Isso significa que as informações dentro deles passam por replicação para vários nós (servidores individuais que armazenam dados). Essa arquitetura distribuída apoiam alta disponibilidade e durabilidade; se um ou mais nós ficarem offline, o restante do banco de dados permanecerá em execução.

Mais notavelmente, no entanto, os bancos de dados NoSQL são projetados para armazenar e consultar dados fora das estruturas tradicionais encontradas em sistemas de gerenciamento de banco de dados relacional (RDBMS). Em vez de aderir a uma estrutura tabular estrita inerente aos bancos de dados relacionais tradicionais, o design de banco de dados não relacional não requer um esquema rígido. Isso possibilita uma escalabilidade rápida para gerenciar grandes conjuntos de dados, incluindo conjuntos de dados estruturados, semiestruturados e dados não estruturados.

(É importante observar que a escalabilidade valorizada nos bancos de dados NoSQL, incluindo Cassandra e MongoDB, é a escalabilidade horizontal ou "scaling-out". Na escalabilidade horizontal, as cargas de trabalho podem ser divididas entre servidores, em contraste com a escalabilidade vertical ou "escalabilidade vertical" associado aos SQL Database, que exigem a adição de memória ao hardware existente.)

Devido ao seu desempenho, escalabilidade e flexibilidade, os bancos de dados NoSQL surgiram como a escolha ideal para dar suporte a aplicações de big data e cargas de trabalho em tempo real. Além de Apache Cassandra e MongoDB, outros bancos de dados NoSQL populares incluem DynamoDB (fornecido pela AWS), Redis e CouchDB.

Embora ambos tenham se originado apenas alguns anos após a virada do milênio, o Apache Cassandra e o MongoDB têm histórias distintas.

O Apache Cassandra remonta ao Facebook por volta de 2007, quando os engenheiros buscavam um sistema que pudesse armazenar dados para a crescente plataforma de mensagens da empresa. Combinando modelos de banco de dados NoSQL estabelecidos, criaram um sistema com estruturas de dados eficientes e consistência eventual, onde as atualizações se propagam até que todas as réplicas correspondam ao longo do tempo. Os engenheiros lançaram o Cassandra como um projeto de código aberto em 2008. Um ano depois, a Apache Software Foundation assumiu a administração. 

O MongoDB começou como parte de um projeto de plataforma como serviço da empresa 10Gen em 2007. A empresa voltou a se dedicar ao MongoDB (seu nome é um trocadilho com a palavra "enorme") e o desenvolveu como um banco de dados baseado em documentos que funcionava com rapidez e era fácil de usar. ¹

A 10Gen, que acabou mudando seu nome para MongoDB Inc., lançou o MongoDB como um projeto de código aberto em 2009. As versões mais recentes do MongoDB, no entanto, são publicadas sob a Server Side Public License v1.

As diferenças fundamentais entre Apache Cassandra e MongoDB afetam seu desempenho e casos de uso ideais. Os principais elementos são:

• Modelos de dados
• Arquitetura e armazenamento
• Consulta e outras linguagens

Bancos de dados NoSQL dependem de um dos quatro tipos de modelos de dados:

• Modelo de documento: os dados são armazenados como documentos estruturados, geralmente em JSON (JavaScript Object Notation) ou BSON (Binary JSON).
• Modelo de colunas amplas: os dados são armazenados em tabelas com colunas esparsas, o que significa que cada linha de uma tabela pode ter um número diferente de colunas.
• Modelo de valor-chave: Os dados são armazenados como pares chave-valor (identificadores ou rótulos emparelhados com valores específicos).
• Modelo de gráfico: os dados são armazenados como nós e bordas, representando entidades e relacionamentos.

O modelo de dados do Cassandra é um modelo de colunas amplas, também conhecido como armazenar colunas amplas. Cada linha em uma tabela do Cassandra tem uma coleção de colunas e uma chave de partição exclusiva que é usada para distribuir dados entre os nós e um data center. As linhas são identificadas por chaves primárias, que podem ser compostas por chaves de partição e, opcionalmente, chaves de cluster (colunas que podem identificar de maneira exclusiva as linhas em uma partição ou grupo relacionado).

Essa abordagem é mais flexível do que a dos bancos de dados relacionais, que têm espaço alocado para um conjunto número de colunas. Através do modelo de dados do Cassandra, usando colunas apenas conforme necessário, resulta em um armazenamento mais eficiente e consultas mais rápidas²

Por outro lado, o MongoDB utiliza um modelo de documento. Os dados são armazenados principalmente como BSON, uma representação binária do JSON desenvolvida pelo MongoDB.

O BSON ajuda a lidar com os obstáculos que o JSON padrão apresentou para os bancos de dados: suportar tipos de dados limitados, a falta de um comprimento fixo para os objetos (o que diminui a velocidade de travessia) e a falta de metadados (o que retarda a recuperação do documento). O BSON foi projetado para otimizar a velocidade e a eficiência codificando informações de formato e comprimento. Ele também é compatível com alguns tipos de dados JSON não nativos, como datas e dados binários. ³

Como bancos de dados NoSQL, tanto o Apache Cassandra quanto o MongoDB são compatíveis com sistemas distribuídos com armazenamento de dados em vários recursos de computação para mitigar o tempo de inatividade. Porém, assim como acontece com seus modelos de dados, a arquitetura subjacente a essa distribuição é fundamentalmente diferente.

O Apache Cassandra depende de uma arquitetura ponto a ponto. Todos os nós de um cluster do Cassandra são iguais, sem depender de um nó mestre. Quando os dados são colocados em um cluster, uma função de hash é aplicada à chave de partição da linha e a produção é usada para atribuir dados a nós específicos. Os dados também são copiados para outros nós.

O fator de replicação de um banco de dados Cassandra descreve o número de cópias dos dados armazenados no banco de dados. O mecanismo de armazenamento do Cassandra usa um fluxo passo a passo (ou caminho de gravação) que consiste em um log de confirmação, uma tabela na memória (memtable) e arquivos de tabela de string classificada (SSTable).

Ao contrário do Cassandra, o MongoDB utiliza um modelo primário/secundário para sua arquitetura distribuída. No MongoDB, um conjunto de réplicas (um grupo de instâncias) consiste em um nó primário que lida com todas as operações de escrita (adições ou modificações de dados) e nós secundários que refletem os dados no nó primário.

Grandes conjuntos de dados no MongoDB também podem ser distribuídos para várias máquinas por meio de um processo conhecido como fragmentação. As informações são divididas em clusters fragmentados, vários conjuntos de réplicas e um roteador que transmite consultas de aplicações para os conjuntos de réplicas, para melhorar a capacidade do sistema de lidar com solicitações de dados.

Os bancos de dados também empregam diferentes métodos de indexação. No Apache Cassandra, o índice primário é a chave de partição, embora a documentação do Cassandra cite a indexação anexa ao armazenamento (que apresenta índices para colunas não particionadas) como apropriada para a maioria dos casos de uso. ⁴ O Cassandra também tem índices secundários, que são índices locais armazenados em tabelas separadas dos valores que estão sendo indexados. O MongoDB suporta vários tipos de índices diferentes para casos de uso diferentes, incluindo índices geoespaciais, índices multikey e índices de texto.

Por definição, os bancos de dados NoSQL não usam a linguagem de consulta estruturada (SQL), a linguagem de programação padronizada de bancos de dados relacionais. No entanto, tanto o Apache Cassandra quanto o MongoDB têm suas próprias linguagens de consulta.

O Cassandra usa uma versão personalizada do SQL chamada Cassandra Query Language (CQL). Embora o CQL se assemelhe ao SQL em grande parte, há diferenças fundamentais entre os dois. Por exemplo, o SQL opera em tabelas normalizadas, enquanto o CQL é projetado para dados desnormalizados do Cassandra alinhados com chaves de partição. Além disso, o SQL é otimizado para transações, enquanto o CQL é projetado para consultas em tempo real e operações de gravação de alto volume.

O MongoDB usa a linguagem de consulta MongoDB (MQL). Desenvolvido para consultar modelos de documentos, o MQL compartilha a mesma sintaxe dos documentos, marcando uma mudança maior em relação ao SQL do que o Cassandra Query Language. O MQL é usado por possibilitar uma variedade de consultas e recursos de manipulação de dados, incluindo consultas complexas, pipelines de agregação e consultas de dados geoespaciais ⁵

Além de suas respectivas linguagens de consulta, os bancos de dados diferem no suporte de programação. O MongoDB disponibiliza drivers oficiais para mais de uma dúzia de linguagens de programação, como Java, Python, Ruby e Node.js. Esses e outros idiomas também são compatíveis com o Cassandra, mas as motivações são em grande parte oferecidas por fornecedores terceirizados.

As diferenças fundamentais entre Apache Cassandra e MongoDB dão origem a algumas variações nas características associadas ao seu desempenho. Essas variações também podem ser explicadas pelo teorema CAP.

CAP é uma abreviação que representa três características desejadas de sistemas distribuídos: consistência (todos os clientes veem os mesmos dados ao mesmo tempo), disponibilidade (qualquer cliente que faça uma solicitação de dados recebe uma resposta, mesmo que um ou mais nós estejam inativos) e tolerância de partição (um cluster de nós Continuar a funcionar mesmo em meio a falhas de comunicação entre dois ou mais nós).

O teorema CAP determina que um sistema distribuído pode oferecer apenas duas das três características desejadas. O Apache Cassandra é geralmente categorizado como um banco de dados "AP", que oferece alto desempenho principalmente em disponibilidade e tolerância a partições.

Enquanto isso, o MongoDB é conhecido como um banco de dados "CP", destacando-se nas frentes de tolerância e consistência de partição. Mas, para ambos os bancos de dados, também há medidas para melhorar o desempenho em características supostamente comprometidas, ou seja, consistência paro Cassandra e disponibilidade para MongoDB.

Vamos dar uma olhada mais de perto nas três características desejadas.

O Cassandra oferece suporte à alta disponibilidade porque, como um sistema descentralizado com dados replicados em vários nós, ele apresenta alta tolerância a falhas e nenhum ponto único de falha. Se um nó passar por downtime, outros com cópias dos mesmos dados poderão atender a uma solicitação de dados. Além disso, a replicação de dados para data centers em todo o mundo possibilita uma baixa latência para os usuários locais.

Como a arquitetura do MongoDB se baseia em um modelo primário/secundário, pode ocorrer um único ponto de falha quando um nó primário fica inoperante. No entanto, o failover do MongoDB é considerado robusto: Durante o que é conhecido como eleições de conjunto de réplicas, os nós pertencentes a um conjunto de réplicas selecionam um novo nó primário para substituir o nó primário indisponível. Esse processo possibilita que o MongoDB também ofereça alta disponibilidade, embora com um breve atraso - o desempenho é retomado somente depois que o novo nó primário é escolhido.

O MongoDB oferece inerentemente alta consistência porque todos os clientes estão gravando em uma fonte única da verdade — cada conjunto de réplicas pode ter apenas um nó primário que recebe todas as operações. Em contraste, o Apache Cassandra apresenta consistência eventual: os clientes podem gravar em qualquer nó a qualquer momento e, em seguida, as inconsistências são reconciliadas o mais rápido possível.

O Cassandra também possibilita que os usuários otimizem a consistência (ao mesmo tempo em que despriorizam a disponibilidade) por meio do que é conhecido como consistência ajustável. Os usuários podem selecionar um nível de consistência, que define quantas réplicas devem reconhecer uma leitura ou gravação antes de confirmá-la na aplicação cliente. Níveis mais altos de consistência exigem que mais réplicas respondam com confirmações, mas isso também aumenta a latência e diminui a disponibilidade.

Tanto o Apache Cassandra quanto o MongoDB oferecem tolerância a partições porque cada um foi projetado para continuar funcionando mesmo quando ocorre uma falha de comunicação em uma parte do sistema.

No Apache Cassandra, os nós permanecem disponíveis no caso de um problema de comunicação, mas alguns nós podem não disponibilizar as versões mais atualizadas dos dados (em resposta às solicitações de dados) até que a partição seja resolvida. No MongoDB, a disponibilidade é limitada para garantir a consistência dos dados enquanto a partição é endereçada.

O Apache Cassandra é frequentemente recomendado para cargas de trabalho de alta taxa de transferência, distribuídas globalmente e de gravação intensa, em que a disponibilidade e a escalabilidade são críticas, como nas atividades de streaming e entretenimento. Por exemplo, serviços de streaming como a Netflix usam o Cassandra para lidar com a atividade global dos usuários.

MongoDB é ideal para casos de uso de esquema flexível e centrados em documentos que se beneficiam da agilidade do desenvolvedor e da forte consistência. As empresas geralmente contam com o MongoDB para dar suporte a seus sistemas de gerenciamento de conteúdo, pois o MongoDB armazena e disponibiliza uma variedade de ativos de conteúdo.

Apesar das diferenças entre os dois bancos de dados, os casos de uso do Apache Cassandra e os casos de uso do MongoDB podem se sobrepor. Os estudos de caso de cada banco de dados demonstram sua eficácia para aplicações da Internet das coisas (IOT), e-commerce e outros.