MongoDB vs. Cassandra [fechado]

Estou avaliando qual pode ser a melhor opção de migração.

Atualmente, estou em um MySQL fragmentado (partição horizontal), com a maioria dos meus dados armazenados em blobs JSON. Eu não tenho nenhuma consulta SQL complexa (já migrada depois que particionei meu banco de dados).

No momento, parece que tanto o MongoDB quanto o Cassandra seriam opções prováveis. Minha situação:

• Muitas leituras em todas as consultas, gravações menos regulares
• Não está preocupado com escalabilidade "maciça"
• Mais preocupado com a configuração, manutenção e código simples
• Minimize o custo de hardware / servidor

Muitas leituras em todas as consultas, menos gravações regulares

Ambos os bancos de dados têm um bom desempenho nas leituras onde o conjunto de dados quentes se encaixa na memória. Ambos também enfatizam modelos de dados sem junção (e incentivam a desnormalização) e fornecem índices em documentos ou linhas , embora os índices do MongoDB sejam atualmente mais flexíveis.

O mecanismo de armazenamento do Cassandra fornece gravações em tempo constante, independentemente do tamanho do seu conjunto de dados. As gravações são mais problemáticas no MongoDB, em parte por causa do mecanismo de armazenamento baseado em árvore b, mas mais por causa do bloqueio de granularidade múltipla .

Para análises, o MongoDB fornece um mapa personalizado / reduz a implementação; Cassandra fornece suporte nativo ao Hadoop, inclusive para o Hive (um data warehouse SQL construído no mapa / redução do Hadoop) e o Pig (uma linguagem de análise específica do Hadoop que muitos consideram mais adequada para mapear / reduzir as cargas de trabalho do que o SQL). Cassandra também suporta o uso do Spark .

Não está preocupado com escalabilidade "maciça"

Se você está procurando um único servidor, o MongoDB provavelmente é o mais adequado. Para os mais preocupados com o dimensionamento, a arquitetura sem ponto único de falha do Cassandra será mais fácil de configurar e mais confiável. (O bloqueio de gravação global do MongoDB também tende a se tornar mais doloroso.) Cassandra também oferece muito mais controle sobre como sua replicação funciona, incluindo suporte para vários data centers.

Mais preocupado com a configuração, manutenção e código simples

Ambos são triviais de configurar, com padrões prontos para uso razoáveis ​​para um único servidor. O Cassandra é mais simples de configurar em uma configuração de vários servidores, pois não há nós de função especial para se preocupar.

Se atualmente você está usando blobs JSON, o MongoDB é uma combinação incrivelmente boa para o seu caso de uso, já que ele usa o BSON para armazenar os dados. Você poderá ter dados mais ricos e questionáveis ​​do que em seu banco de dados atual. Esta seria a vitória mais significativa para Mongo.

Eu usei o MongoDB extensivamente (nos últimos 6 meses), construindo um sistema hierárquico de gerenciamento de dados e posso garantir a facilidade da instalação (instale, execute, use!) E a velocidade. Contanto que você pense nos índices com cuidado, ele pode gritar com toda a velocidade.

Entendo que o Cassandra, devido ao seu uso em projetos de grande escala como o Twitter, possui uma melhor funcionalidade de dimensionamento, embora a equipe do MongoDB esteja trabalhando em paridade lá. Devo salientar que não usei Cassandra além do estágio de teste, por isso não posso falar pelos detalhes.

A verdadeira vantagem para mim, quando estávamos avaliando os bancos de dados NoSQL, era a consulta - Cassandra é basicamente apenas um armazenamento de chave / valor gigante, e a consulta é um pouco complicada (pelo menos em comparação com o MongoDB). duplicar muitos dados como uma espécie de índice manual. O MongoDB, por outro lado, usa um modelo "consulta por exemplo".

Por exemplo, digamos que você tenha uma coleção (linguagem do MongoDB para o equivalente a uma tabela RDMS) contendo usuários. O MongoDB armazena registros como Documentos, que são basicamente objetos JSON binários. por exemplo:

{
   FirstName: "John",
   LastName: "Smith",
   Email: "[email protected]",
   Groups: ["Admin", "User", "SuperUser"]
}

Se você deseja encontrar todos os usuários chamados Smith que têm direitos de administrador, basta criar um novo documento (no console administrativo usando Javascript ou em produção usando o idioma de sua escolha):

{
   LastName: "Smith",
   Groups: "Admin"
}

... e, em seguida, execute a consulta. É isso aí. Existem operadores adicionados para comparações, filtragem RegEx, etc., mas tudo é bastante simples, e a documentação baseada em Wiki é muito boa.

Por que escolher entre um banco de dados tradicional e um repositório de dados NoSQL? Use ambos! O problema com as soluções NoSQL (além da curva de aprendizado inicial) é a falta de transações - você faz todas as atualizações no MySQL e o MySQL preenche um repositório de dados NoSQL para leituras - e então se beneficia dos pontos fortes de cada tecnologia. Isso adiciona mais complexidade, mas você já tem o lado MySQL - basta adicionar MongoDB, Cassandra, etc à mistura.

Os datastores NoSQL geralmente têm uma escala melhor do que um banco de dados tradicional para as mesmas especificações - existe uma razão pela qual o Facebook, Twitter, Google e a maioria das empresas iniciantes estão usando as soluções NoSQL. Não são apenas os nerds que estão no topo das novas tecnologias.

Provavelmente vou ser um homem estranho, mas acho que você precisa ficar com o MySQL. Você não descreveu um problema real que precisa resolver, e o MySQL / InnoDB é um excelente back-end de armazenamento, mesmo para dados blob / json.

Existe um truque comum entre os engenheiros da Web para tentar usar mais NoSQL, assim que a realização ocorre, que nem todos os recursos de um RDBMS são usados. Isso por si só não é um bom motivo, já que os bancos de dados NoSQL costumam ter mecanismos de dados bastante ruins (o que o MySQL chama de mecanismo de armazenamento).

Agora, se você não é desse tipo, especifique o que está faltando no MySQL e procurará em um banco de dados diferente (como compartilhamento automático, failover automático, replicação multimestre, garantia de consistência de dados mais fraca no cluster pagando com maior taxa de transferência de gravação, etc).

Eu não usei Cassandra, mas usei o MongoDB e acho incrível.

Se você deseja uma configuração simples, é isso: você simplesmente descompacta o MongoDB e executa o daemon mongod e é isso ... está em execução.

Obviamente, isso é apenas um começo, mas para você começar, é fácil.

Vi uma apresentação no mongodb ontem. Definitivamente, posso dizer que a instalação foi "simples", tão simples quanto descompactar e inicializar. Feito.

Eu acredito que o mongodb e o cassandra rodarão em praticamente qualquer hardware Linux normal, então você não deve encontrar muita barreira nessa área.

Penso que, neste caso, no final das contas, tudo se resume a quem você se sente mais à vontade e qual o conjunto de ferramentas que você prefere. Quanto à apresentação no mongodb, o apresentador indicou que o conjunto de ferramentas para o mongodb era bastante leve e que não havia muitas (disseram realmente) ferramentas semelhantes às disponíveis para o MySQL. Esta foi, obviamente, a experiência deles, então YMMV. Uma coisa que gostei no mongodb foi que parecia haver muito suporte à linguagem para ele (Python e .NET são os dois que eu mais uso).

A lista de sites usando o mongodb é bastante impressionante , e eu sei que o twitter acabou de usar o cassandra.