MongoDB Vs Cassandra

O Propósito deste artigo não é fazer uma comparação que tire o mérito de qualquer dos produtos envolvidos e é bom deixar bem claro que não trabalho para a MongoDB ou faço parte da DataStax e sim um profissional com anos de experiência em Bancos de Dados (Oracle - SQL Server - DB2 - Sybase - MySQL, etc..) que atua em projetos de BigData utilizando MongoDB.

Um dos motivos que me levaram a realizar esta avaliação foi pelo fato de participar de projetos e ter a oportunidade ou azar, dependendo do ponto de vista, de escutar vários comentários sobre o MongoDB e muita propaganda sobre o Cassandra e sendo assim decidi ir em busca de informações sobre o Cassandra, pois sobre o MongoDB já tenho uma certa experiência e conheço bem o que ele é capaz de fazer. Confesso que não foi fácil, pois a grande parte das informações são muito superficiais e então decidi montar um ambiente Cassandra para realização de testes.

Vamos inciar pelas características de cada um :

O MongoDB atua como um banco de dados relacional. Seu modelo de dados consiste em um banco de dados no nível mais alto, em seguida, as coleções que são como tabelas no MySQL (por exemplo) e  em seguida os documentos que estão contidos dentro da coleção, como linhas em MySQL. Cada documento tem um campo e um valor em que este é semelhante a colunas e valores em MySQL. Campos pode ser a chave / valor simples, por exemplo, {'Nome': 'David Mytton'}, mas eles também podem conter outros documentos, por exemplo {'Nome': {'primeiro': David, 'last': 'Mytton'}}.

[caption id="attachment_105" align="aligncenter" width="533"] Document Model[/caption]

No Cassandra os documentos são conhecidos como "colunas" que são realmente apenas uma única chave e valor. por exemplo {'Chave': 'nome', 'valor': 'David Mytton'}. Há também um campo de timestamp que é para replicação interna e consistência. O valor pode ser um valor único mas também podem conter um outro "coluna". Estas colunas, em seguida, existem no seio das famílias de colunas que ordenam dados com base em um valor específico nas colunas, referenciada por uma chave. No nível mais alto existe um keyspace, que é semelhante à base de dados MongoDB.

[caption id="attachment_106" align="aligncenter" width="450"] Cassandra’s data model[/caption]

Índices

MongoDB trabalhar com Índices de forma muito semelhante aos bancos de dados relacionais. Você cria índices simples ou compostos, em nível de conjunto e de cada documento inserido nessa coleção tem esses campos indexados. Consultando pelo índice é extremamente rápido, desde que você tenha todos os seus índices na memória.

Antes da versão 0.7, o Cassandra era essencialmente um depósito de chave/valor e por isso se você desejava consultar pelo conteúdo de uma chave (ou seja, o valor), então você precisava criar uma coluna separada, que faz referência a outras colunas ou seja, você tinha que criar seus próprios índices. Isso mudou em Cassandra 0.7 que permitiu índices secundários sobre os valores da coluna, mas apenas através do mecanismo de famílias de colunas.

O Cassandra requer uma grande quantidade de meta dados  para índices e requer índices secundários, se você quiser fazer consultas de intervalo. Por exemplo se definirmos uma nova família de colunas com um índice:

$ bin/cassandra-cli --host localhost

Connected to: "Test Cluster" on localhost/9160

Welcome to cassandra CLI.

Type 'help;' or '?' for help. Type 'quit;' or 'exit;' to quit.

[default@unknown] create keyspace demo;

[default@unknown] use demo;

[default@demo] create column family users with comparator=UTF8Type

... and column_metadata=[{column_name: full_name, validation_class: UTF8Type},

... {column_name: birth_date, validation_class: LongType, index_type: KEYS}];

Sendo assim, não podemos fazer consultas de intervalo:

[default@demo] get users where state = 'UT' and birth_date > 1970;

No indexed columns present in index clause with operator EQ

Para isso é preciso criar um índice secundário:

update column family users with comparator=UTF8Type

... and column_metadata=[{column_name: full_name, validation_class: UTF8Type},

... {column_name: birth_date, validation_class: LongType, index_type: KEYS},

... {column_name: state, validation_class: UTF8Type, index_type: KEYS}];

Desta forma então o Cassandra pode usar o state como o principal e filtro com base na birth_date:

get userswhere state = 'UT'and birth_date > 1970;

Desenvolvimento

O MongoDB é escrito em C + + e fornecido no formato binário para Linux, OS X, Windows e várias outras plataformas. É  fácil de "instalar" - baixar, extrair e executar mongod, quer dizer, em poucos minutos você já dispõe do seu ambiente.

Cassandra é escrito em Java e tem a sobrecarga que traz, mas por outro lado a capacidade fácil de integrar em projetos Java existentes. Demora um pouco mais para se começar, mas não é uma demonstração de criação de um cluster de 4 nós em menos de 2 minutos, o que você iria lutar para vencer com MongoDB.

Não tenho em mãos os numeros exatos, porém parece que uma grande parte dos usuários de MongoDB executam no Windows, mas seria interessante saber se o mesmo ocorre com o Cassandra, acredita-se que seja mais no Linux.

Consistência / Replicação

A replicação no MongoDB  é conseguida através de conjuntos de réplicas. Este é um modelo de master/slave reforçado onde você tem um conjunto de nós, onde um é o mestre. Os dados são replicados para todos os nós de modo que se o mestre falhar, outro membro assumirá. Há opções de configuração para determinar quais nós temos prioridade e você pode definir opções como o atraso da sincronização para ter nós com dados atrasados para o caso de uma recuperação de desastre, por exemplo.

[caption id="attachment_109" align="aligncenter" width="361"] Conjunto de Replicas com 3 nós[/caption]

 

Os processos de escritas no MongoDB são "inseguros" por padrão, pois os dados não são gravados imediatamente por padrão, então é possível que uma operação de gravação que normalmente retornaria sucesso seja perdida devido a uma falha no servidor antes dos dados serem liberados para o disco. Esta é forma como o Mongo alcança alto desempenho. Se você precisar de maior durabilidade, então você pode especificar uma gravação segura, que vai garantir que os dados sejam gravados no disco antes de retornar. Além disso, você pode exigir que os dados também sejam escritos com sucesso para n Slaves de replicação.

Os Drivers do MongoDB também suportam a capacidade de ler a partir de Slaves. Isso pode ser feito em uma conexão onde o banco de dados coleta ou mesmo a nível de consulta e os Drivers irão lidar com o envio de requisições certas para os Slaves certos, mas não há garantia de consistência, a menos que você estiver usando a opção de escrever em todos os Slaves antes de retornar) . Em contraste , as consultas no Cassandra vão a cada um dos nós e a coluna mais atualizada é devolvida, com base no valor timestamp.

Neste quesito o Cassandra tem um suporte muito mais avançado para a replicação por estar ciente da topologia da rede. O servidor pode ser configurado para usar um nível de consistência específica para garantir que as consultas sejam replicadas localmente ou para os centros de dados remotos. Isto significa que você pode deixar Cassandra lidar com redundância através dos nós quando tiver conhecimento de qual rack e data center esses nós estão. O Cassandra também pode monitorar os nós e através de consultas de rotas qual nó está mais lento nas respostas.

A desvantagem do Cassandra é que essas configurações são feitas em um nível de nó com arquivos de configuração enquanto o MongoDB permite o controle ad-hoc muito granular para consultas de baixo nível por meio de opções de drivers que podem ser chamados no código em tempo real de execução.

Quem são os Responsáveis?Ambos Cassandra (Apache licença 2.0) e MongoDB (AGPL) são de código aberto (Open Source). Significa que você pode baixar livremente o código, escrever patches e submetê-los. No entanto, o Cassandra é puramente um projeto open source enquanto MongoDB é "propriedade" de uma empresa comercial, 10gen. Os autores originais do MongoDB são contribuintes fundamentais para o código e trabalham para 10gen (na verdade, 10gen foi fundada especificamente para apoiar MongoDB e o CEO e CTO são os criadores originais), em bom português, os pais da criança.

Em contraste, o Cassandra foi criado por dois engenheiros do Facebook e é incubado pela Fundação Apache. Esta não é uma desvantagem (na verdade, o servidor Web Apache utilizado pela maioria dos sites tem raízes semelhantes e faz parte da Fundação Apache), mas é importante entender bem isso quando se trata de suporte, desenvolvimento contínuo e da comunidade (abaixo).

Suporte

Embora haja consultores independentes para MongoDB, o melhor lugar para obter suporte é direto da 10gen porque ela escreveu o banco de dados e não precisa muito para deduzir que eles saibam o que é melhor. Eles são podem inclusive oferecer contratos SLAs de suporte com telefone e e-mail. Por experiência própria posso dizer e garantir que funciona perfeito.

Em contraste, o Cassandra possui várias empresas que oferecem suporte comercial e enquanto eles têm acesso ao código Cassandra core, neste caso eu diria que não é o mesmo que ter acesso a toda a equipe de engenharia e os autores originais em um único ponto de contato, como é o caso com MongoDB.

Esta é a vantagem do MongoDB, pois interagindo diretamente com a empresa que controla o projeto principal, especialmente para fins de suporte, significa que você pode ter correções de bugs e mudanças implementadas para a base de código.

Em teoria, deveria ser o mesmo com o Cassandra , pois quem não gostaria de ter bugs corrigidos e funcionalidades implementadas, mas as coisas não acontecem da mesma forma por causa da natureza dos projetos de código aberto que por sua vez são executados por voluntários e isto se torna mais complexo quando as empresas estão pagando desenvolvedores para trabalhar sobre o projeto, sem esquecer que há um risco de que a empresa por trás do projeto desapareça, seja comprada, incorporada, etc.. e todos os engenheiros irem parar em outro lugar, mas não podemos esquecer que o o projeto ainda é open source e isto é o mesmo que como qualquer peça de software que você pode usar, em teoria.

Você também pode argumentar que há mais direção e foco de uma empresa comercial que trabalha exclusivamente sobre o produto e mais engenheiros dedicados a ele, mas eu não quero ir mais longe com este ponto como este artigo não é sobre open source vs comercial. Este é apenas um ponto que deve ser levado em conta.

Documentação

A documentação oficial Cassandra é pobre. Pesquisando por isso eu tinha que visitar vários sites e assistir a vídeos até mesmo para obter explicações sobre conceitos de chave como índices. Não há melhor documentação do que já existe no site da DataStax mas ainda é muito falho na explicação de conceitos em qualquer profundidade.

A documentação MongoDB é mais completa e mais abrangente. É  mantido atualizado até a data da ultima versão e abrange todos os recursos, com exemplos. Ninguém gosta de documentação escrita e mostra como muitos projetos de código aberto; esta é outra vantagem de ter uma empresa por trás do projeto, forçando os desenvolvedores a escrever os documentos! Aliás, uma das maiores vantagens da linguagem PHP é a extensa documentação, exemplos e notas submetidos por usuários.

No meu caso, quando conheci o MongoDB e comecei a trabalhar com outros bancos NoSQL ,após anos trabalhando com bancos de dados relacionais, uma documentação completa e um suporte ativo é muito importante e crucial no caso de estar estar evolvido em um projeto.

Comunidades

MongoDB é digno de ser estudado no quesito "Como construir uma comunidade em torno de um produto". Há diversas conferências sobre MongoDB todos os anos, uma lista de discussão muito ativa, e grupos de usuários em todo o mundo. Novamente, isso tudo porque há uma empresa por trás do produto, promovendo ativamente,incentivando e gerenciando esses eventos.

No caso do Cassandra, conferências são muito raras e por enquanto há grupos de usuários mas certamente não na mesma escala do MongoDB.

Será que isso importa? Nada disso existia quando nós da geração que viveu um mundo sem internet, e aprendemos tudo sozinhos. Mas para os novos usuários de hoje, há uma grande fórum de pessoas que estão usando MongoDB e estão compartilhando seus conhecimentos de forma livre e de fácil acesso.

Drivers

A outra razão principal da minha preferência de escolha pelo MongoDB foi o suporte de drivers. Todos os principais drivers para MongoDB estão disponíveis e mais importante, mantidos pelo próprio 10gen. O MongoDB tem drivers oficiais para C, C #, C + +, Erlang, Javascript, Java, Perl, PHP, Python, Ruby e Scala. Tudo totalmente suportado.

O Cassandra só tem drivers oficiais Java e Python, com alguns outros escritos por terceiros. Descobri que Python geralmente é melhor quando se trata de bibliotecas que funcionam bem. PHP é uma outra história , problemas foram relatados com RabbitMQ e ZeroMQ no passado, especificamente não funciona bem sob carga pesada, todos eles funcionam bem para brincar. Boas bibliotecas PHP são difíceis de encontrar.

Conclusão

Não há nenhuma conclusão. Este artigo não é sobre o que é melhor e sim apenas uma comparação dos dois. Ambos têm vantagens e desvantagens e para comparar realmente você precisa executá-los no ambiente de produção sob carga significativa por um longo período de tempo. MongoDB tem funcionado bem e mostrou ao que veio em escala e por ter flexibilidade para fazer coisas como a construção de um sistema de filas, bem como ser o principal armazenamento de dados.

Outras Referências

• Mongodb vs. Cassandra on Stackoverflow


• Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase vs Membase vs Neo4j comparison