Cassandra x MongoDB
Você está considerando Cassandra ou MongoDB como o armazenamento de dados para seu próximo projeto? Você gostaria de comparar os dois bancos de dados? Cassandra e MongoDB são bancos de dados “NoSQL”, mas a realidade é que eles são muito diferentes. Eles têm pontos fortes e propostas de valor muito diferentes – portanto, qualquer comparação deve ser diferenciada. Vamos começar com os requisitos iniciais… Nenhum desses bancos de dados substitui o RDBMS, nem são bancos de dados “ACID”. Portanto, se você tiver uma carga de trabalho transacional em que a normalização e a consistência sejam os principais requisitos, nenhum desses bancos de dados funcionará para você. É melhor ficar com bancos de dados relacionais tradicionais como MySQL, PostgreSQL, Oracle, etc. Agora que temos bancos de dados relacionais fora do caminho, vamos considerar as principais diferenças entre Cassandra e MongoDB que o ajudarão a tomar a decisão. Nesta postagem, não discutirei recursos específicos, mas indicarei algumas diferenças estratégicas de alto nível para ajudar você a fazer sua escolha.
1. Modelo de objeto expressivo
O MongoDB suporta um modelo de objeto rico e expressivo. Os objetos podem ter propriedades e os objetos podem ser aninhados uns nos outros (para vários níveis). Este modelo é muito “orientado a objetos” e pode representar facilmente qualquer estrutura de objeto em seu domínio. Você também pode indexar a propriedade de qualquer objeto em qualquer nível da hierarquia – isso é incrivelmente poderoso! O Cassandra, por outro lado, oferece uma estrutura de tabela bastante tradicional com linhas e colunas. Os dados são mais estruturados e cada coluna tem um tipo específico que pode ser especificado durante a criação.
Veredicto:se o domínio do seu problema precisa de um modelo de dados rico, a hospedagem MongoDB é mais adequada para você.
2. Índices secundários
Índices secundários são uma construção de primeira classe no MongoDB. Isso facilita a indexação de qualquer propriedade de um objeto armazenado no MongoDB, mesmo que esteja aninhado. Isso facilita muito a consulta com base nesses índices secundários. Cassandra tem apenas suporte superficial para índices secundários. Os índices secundários também são limitados a colunas únicas e comparações de igualdade. Se você estiver consultando principalmente pela chave primária, o Cassandra funcionará bem para você.
Veredicto: se seu aplicativo precisar de índices secundários e precisar de flexibilidade no modelo de consulta, o MongoDB é mais adequado para você.
3. Alta disponibilidade
O MongoDB suporta um modelo “single master”. Isso significa que você tem um nó mestre e vários nós escravos. Caso o mestre caia, um dos escravos é eleito como mestre. Esse processo acontece automaticamente, mas leva tempo, geralmente de 10 a 40 segundos. Durante esse período de eleição de novo líder, seu conjunto de réplicas está inativo e não pode receber gravações. Isso funciona para a maioria dos aplicativos, mas, em última análise, depende de suas necessidades. Cassandra suporta um modelo “múltiplo mestre”. A perda de um único nó não afeta a capacidade do cluster de realizar gravações – portanto, você pode obter 100% de tempo de atividade para gravações.
Veredicto:se você precisa de 100% de tempo de atividade, o Cassandra é mais adequado para você.
4. Escalabilidade de gravação
O MongoDB com seu modelo “single master” pode receber gravações apenas no primário. Os servidores secundários só podem ser usados para leituras. Então, essencialmente, se você tiver três conjuntos de réplicas de nós, apenas o mestre está recebendo gravações e os outros dois nós são usados apenas para leituras. Isso limita muito a escalabilidade de gravação. Você pode implantar vários shards, mas essencialmente apenas 1/3 de seus nós de dados podem receber gravações. O Cassandra com seu modelo “múltiplo mestre” pode receber gravações em qualquer servidor. Essencialmente, sua escalabilidade de gravação é limitada pelo número de servidores que você possui no cluster. Quanto mais servidores você tiver no cluster, melhor ele será dimensionado.
Veredicto:se você gosta de escalabilidade de gravação, o Cassandra é mais adequado para você.
5. Suporte à linguagem de consulta
O Cassandra suporta a linguagem de consulta CQL, que é muito semelhante ao SQL. Se você já possui uma equipe de analistas de dados, eles poderão transferir a maioria de suas habilidades em SQL, o que é muito importante para grandes organizações. No entanto, o CQL não é um ANSI SQL completo – ele tem várias limitações (sem suporte de junção, sem cláusulas OR) etc. O MongoDB neste momento não tem suporte para uma linguagem de consulta. As consultas são estruturadas como fragmentos JSON.
Veredicto:se você precisar de suporte ao idioma de consulta, Cassandra é a melhor opção para você.
6. Referências de desempenho
Vamos falar de desempenho. Neste ponto, você provavelmente está esperando uma comparação de benchmark de desempenho dos bancos de dados. Eu deliberadamente não incluí benchmarks de desempenho na comparação. Em qualquer comparação, temos que ter certeza de que estamos fazendo uma comparação de maçãs com maçãs.
1. Modelo de banco de dados - O modelo/esquema do banco de dados do aplicativo que está sendo testado faz uma grande diferença. Alguns esquemas são adequados para o MongoDB e alguns são adequados para o Cassandra. Portanto, ao comparar bancos de dados, é importante usar um modelo que funcione razoavelmente bem para ambos os bancos de dados.
2. Características de carregamento – As características da carga de referência são muito importantes. Por exemplo. Em benchmarks pesados de gravação, eu esperaria que Cassandra fumasse MongoDB. No entanto, em benchmarks de leitura pesada, MongoDB e Cassandra devem ser semelhantes em desempenho.
3. Requisitos de consistência - Isso é complicado. Você precisa certificar-se de que os requisitos de consistência de leitura/gravação especificados sejam idênticos em ambos os bancos de dados e não enviesados para um participante. Muitas vezes, em vários benchmarks de 'Marketing', os botões são ajustados para prejudicar o outro lado. Portanto, preste muita atenção às configurações de consistência.
Uma última coisa a ter em mente é que a carga de referência pode ou não refletir o desempenho do seu aplicativo. Portanto, para que os benchmarks sejam úteis, é muito importante encontrar uma carga de benchmark que reflita as características de desempenho do seu aplicativo. Aqui estão alguns benchmarks que você pode querer analisar:
- NoSQL Performance Benchmarks
- Cassandra vs. MongoDB vs. Couchbase vs. HBase
7. Facilidade de uso
Se você tivesse feito essa pergunta alguns anos atrás, o MongoDB seria o vencedor. É uma tarefa bastante simples colocar o MongoDB em funcionamento. Nos últimos dois anos, no entanto, Cassandra fez grandes avanços nesse aspecto do produto. Com a adoção do CQL como a interface principal do Cassandra, isso deu um passo adiante – eles tornaram muito simples para legiões de programadores SQL usarem o Cassandra com muita facilidade.
Veredicto:ambos são bastante fáceis de usar e aumentam.
8. Agregação nativa
O MongoDB possui uma estrutura de agregação integrada para executar um pipeline ETL para transformar os dados armazenados no banco de dados. Isso é ótimo para trabalhos pequenos e médios, mas à medida que suas necessidades de processamento de dados se tornam mais complicadas, a estrutura de agregação se torna difícil de depurar. O Cassandra não possui uma estrutura de agregação integrada. Ferramentas externas como Hadoop, Spark são usadas para isso.
9. Modelos sem esquema
No MongoDB, você pode optar por não aplicar nenhum esquema em seus documentos. Embora esse fosse o padrão nas versões anteriores, na versão mais recente, você tem a opção de aplicar um esquema para seus documentos. Cada documento no MongoDB pode ser uma estrutura diferente e cabe ao seu aplicativo interpretar os dados. Embora isso não seja relevante para a maioria dos aplicativos, em alguns casos a flexibilidade extra é importante. Cassandra nas versões mais recentes (com CQL como idioma padrão) fornece digitação estática. Você precisa definir o tipo de coluna com antecedência.
Para resumir, aqui estão as diferenças importantes no formato da tabela:
Se você quiser ver o infográfico completo, visite nossa página de comparação Cassandra vs MongoDB.
