MongoDB vs. Cassandra [fechado]

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

Atualmente, estou em um MySQL barbudo (partição horizontal), com a maioria dos meus dados armazenados em blobs JSON. Não tenho quaisquer consultas SQL complexas (já migraram para longe depois de ter particionado o meu db).

Neste momento, parece que tanto o MongoDB como a Cassandra seriam opções prováveis. A minha situação:
  • muitas leituras em cada consulta, escritas menos regulares
  • Não estou preocupado com"massivo" escalabilidade
  • mais preocupado com a configuração simples, manutenção e Código
  • minimizar o custo do hardware / servidor
Author: Community, 2010-05-23

6 answers

Muitas leituras em cada consulta, menos escritas regulares

Ambas as bases de dados funcionam bem ao ler onde o conjunto de dados Quente Se encaixa na memória. Ambos também enfatizam os modelos de dados "join-less" (e incentivam a desnormalização), e ambos fornecem índices em documentos ou linhas , embora os índices do MongoDB sejam atualmente mais flexíveis.

O motor de armazenamento da Cassandra fornece escrita em tempo constante, independentemente do tamanho do seu conjunto de dados. As escritas são mais problemático em MongoDB, em parte por causa do motor de armazenamento baseado em B-tree,mas mais por causa do bloqueio multi-granularidade {[7] } faz.

Para a análise, o MongoDB fornece um mapa personalizado / reduz a implementação; a Cassandra fornece suporte Hadoop nativo, incluindo para Colmeia (um armazém de dados SQL construído sobre o mapa/reduce do Hadoop) e {[[18]} Pig

(uma linguagem de análise específica do Hadoop que muitos pensam ser mais adequada para o mapa/reduzir cargas de trabalho do que o SQL). Cassandra também suporta o uso de faísca .

Não estou preocupado com a escalabilidade "massiva".

Se você está olhando para um único servidor, MongoDB é provavelmente um ajuste melhor. Para aqueles mais preocupados com a escala, a arquitetura sem-ponto-de-falha de Cassandra será mais fácil de configurar e mais confiável. (MongoDB global write lock tende a se tornar mais doloroso, também. Cassandra também dá muito mais controle sobre como sua replicação funciona, incluindo suporte para múltiplos dados centro.

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

Ambos são triviais de configurar, com valores razoáveis fora-da-caixa por omissão para um único servidor. Cassandra é mais simples de configurar em uma configuração multi-servidor, uma vez que não existem nós de papel especial com que se preocupar; aqui está um screencast demonstrando configurar um conjunto de Cassandra de 4 nós em dois minutos.

Se está actualmente a usar blobs JSON, o MongoDB é um excelente par para o seu uso. case, dado que usa a BSON para armazenar os dados. Você será capaz de ter dados mais ricos e mais questionáveis do que você teria na sua atual base de dados. Esta seria a vitória mais significativa para Mongo.
 538
Author: Michael, 2018-09-28 20:52:08

Usei o MongoDB extensivamente (nos últimos 6 meses), construindo um sistema hierárquico de gestão de dados, e posso garantir tanto a facilidade de configuração (instalá-lo, executá-lo, usá-lo!) and the speed. Desde que você pense em índices cuidadosamente, ele pode absolutamente gritar junto, em relação à velocidade.

Acho que Cassandra, devido ao seu uso em projetos de grande escala como o Twitter, tem melhor funcionalidade de escala, embora a equipe MongoDB esteja trabalhando em paridade. Devo salientar que Não usei a Cassandra para além da fase experimental, por isso não posso falar pelos detalhes. O verdadeiro swinger para mim, quando estávamos avaliando as bases de dados NoSQL, era a querying - Cassandra é basicamente apenas uma loja de chave/valor gigante, e querying é um pouco instável (pelo menos em comparação com MongoDB), então para o desempenho você teria que duplicar um monte de dados como uma espécie de índice manual. MongoDB, por outro lado, usa um modelo de "consulta por exemplo". Por exemplo, diz que tens uma colecção. (Linguagem MongoDB para o equivalente a uma tabela RDMS) contendo usuários. MongoDB armazena registros como documentos, que são basicamente objetos JSON binários. e. g:
{
   FirstName: "John",
   LastName: "Smith",
   Email: "[email protected]",
   Groups: ["Admin", "User", "SuperUser"]
}

Se você quisesse encontrar todos os usuários chamados Smith que têm direitos de Administração, você simplesmente criaria um novo documento (na consola de administração usando Javascript, ou em produção usando a linguagem de sua escolha):

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

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

 140
Author: Richard K., 2010-07-01 22:29:02
Por que escolher entre uma base de dados tradicional e uma loja de dados NoSQL? Usa os dois! O problema com as soluções NoSQL (além da curva de aprendizagem inicial) é a falta de transações -- você faz todas as atualizações para o MySQL e tem o MySQL populando uma loja de dados NoSQL para ler -- você então se beneficia dos pontos fortes de cada tecnologia. Isto adiciona mais complexidade, mas você já tem o lado MySQL -- basta adicionar MongoDB, Cassandra, etc à mistura.

Os dados do NoSQL são geralmente muito melhores do que um DB tradicional para as mesmas especificações -- há uma razão pela qual Facebook, Twitter, Google, e a maioria das start-ups estão usando soluções NoSQL. Não são só cromos a ficar pedrados com nova tecnologia.

 100
Author: Jason Grant Taylor, 2012-04-17 00:45:52
Provavelmente vou ser um homem estranho, mas acho que precisas de ficar com o MySQL. Você não descreveu um problema real que você precisa resolver, e MySQL/InnoDB é um excelente back-end de armazenamento, mesmo para dados blob/json. Há um truque comum entre os engenheiros de Web para tentar usar mais NoSQL assim que se percebe que nem todas as características de um RDBMS são usadas. Isso por si só não é uma boa razão, Uma vez que na maioria das vezes bases de dados NoSQL têm motores de dados bastante pobres (o que MySQL chama de um motor de armazenamento).

Agora, se você não é desse tipo, então, por favor, especifique o que está faltando em MySQL e você está procurando em um banco de dados diferente (como, auto-sharding, falha automática, replicação multi-master, uma garantia de consistência de dados mais fraca no cluster pagando em alta taxa de escrita, etc).

 55
Author: Kostja, 2012-02-23 20:50:13
Não usei a Cassandra, mas usei o MongoDB e acho que é fantástico.

Se a sua configuração após simples, é isto. Tu simplesmente destróis o MongoDB e geres o daemon mongod e isso é ... it..it está a correr.

Obviamente, é só um arranque, mas para começar é fácil.
 18
Author: dalton, 2010-05-23 17:57:05
Vi uma apresentação sobre mongodb ontem. Eu posso definitivamente dizer que a configuração foi "simples", tão simples quanto desempacotar e acendê-lo. Terminar.

Acredito que tanto o mongodb como a cassandra irão rodar em praticamente qualquer hardware linux normal, por isso não deve encontrar muita barreira nessa área.

Acho que, neste caso, no final do dia, será o que lhe fará sentir-se mais à vontade e que tem um conjunto de ferramentas que prefere. Na medida em que o apresentação sobre mongodb, o apresentador indicou que o conjunto de ferramentas para mongodb era muito leve e que não havia muitas (eles disseram que realmente) ferramentas semelhantes ao que está disponível para MySQL. Esta foi, naturalmente, a sua experiência tão YMMV. Uma coisa que eu gostei sobre mongodb foi que parecia haver muito Suporte de linguagem para ele (Python, e.NET sendo os dois que eu uso principalmente).

A lista de sites que usam mongodb é bastante impressionante {[[9]}, e eu sei que o twitter apenas mudou para usar a cassandra.

 12
Author: GrayWizardx, 2010-05-23 17:57:33