Quando usar o CouchDB sobre o MongoDB e vice-versa

638

Estou preso entre esses dois bancos de dados NoSQL.

No meu projeto, vou criar um banco de dados dentro de um banco de dados. Por exemplo, preciso de uma solução para criar tabelas dinâmicas.

Assim, os usuários podem criar tabelas com colunas e linhas. Acho que o MongoDB ou o CouchDB será bom para isso, mas não tenho certeza de qual deles. Também precisarei de paginação eficiente.

— Luke101
fonte

19

Eu gostaria que eles modificassem o sistema para facilitar melhor a criação da pergunta no tópico que estão procurando e direcionar melhor os usuários para essa pergunta. Não tenho idéia se essa questão já foi abordada e não há uma maneira conveniente de localizá-la.

— doub1ejack

45

Eu gostaria que eles adicionassem a funcionalidade deste site onde poderíamos "votar" ou "votar abaixo" o motivo em si dado a esta pergunta como "fora do tópico", o que pode ajudar a transformar esse tipo de pergunta novamente em "no tópico".

— Sanjay

9

++ Não está claro para mim por que isso está fora de tópico. A questão não ter respostas objetivas claras - o OP não está pedindo opinião, mas para uma informação objectiva sobre estes dois sistemas. user799188 forneceu uma ótima resposta objetiva.

— User48956

3

Eu acho que os administradores apenas olham para a pergunta se ela contém algum código e não para o tipo de informação que está sendo procurada. Mas você sempre pode votar para reabrir a pergunta.

— Tarun 15/05

11

A questão foi reaberta. Bem-vindos, pessoal ... #

— Alexis Dufrenoy

523

De C, A e P (tolerância de consistência, disponibilidade e partição), quais 2 são mais importantes para você? Referência rápida, o Visual Guide To NoSQL Systems

MongodB: Consistência e tolerância de partição
CouchDB: disponibilidade e tolerância de partição

Em uma postagem no blog, a comparação Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase vs Membase vs Neo4j apresenta os cenários ' Melhor usado ' para cada banco de dados NoSQL comparado. Citando o link,

MongoDB: se você precisar de consultas dinâmicas. Se você preferir definir índices, não mapeie / reduza funções. Se você precisar de um bom desempenho em um grande banco de dados. Se você queria o CouchDB, mas seus dados mudam muito, preencha discos.
CouchDB: Para acumular, alterar ocasionalmente dados, nos quais consultas predefinidas devem ser executadas. Locais onde a versão é importante.

Uma comparação recente (fevereiro de 2012) e mais abrangente de Riyad Kalla,

MongoDB: SOMENTE Replicação Mestre-Escravo
CouchDB: Replicação Master-Master

Uma postagem do blog (outubro de 2011) por alguém que tentou as duas coisas, Um cara do MongoDB aprende o CouchDB comentou que a paginação do CouchDB não é tão útil.

A datada (Jun 2009) de referência por Kristina Chodorow ( parte da equipe por trás MongoDB ),

Eu iria para o MongoDB.

Espero que ajude.

— user799188
fonte

8

Pelo que eu entendo MongoDB não é consistente em toda a maneira: ivoras.sharanet.org/blog/tree/...

— sheerun

2

Boas informações para a época, mas isso é realmente antigo ... muitos foram alterados (incluindo interfaces REST para Mongo).

— rich

4

Eu acho que pode ser um pouco enganador, mas a versão no couchdb não é um argumento. O esquema de versão usado pelo couchdb não deve ser usado como versão por exemplo. É usado para lidar com partições. Durante uma compactação de banco de dados, as revisões serão excluídas como realmente excluídas. E apenas as cadeias de rotações devem permanecer no banco de dados. Se você deseja manipular versões no couchdb, isso deve ser feito da mesma forma que no mongodb.

— Loïc Faure-Lacroix

2

Eu acrescentaria à lista que o couchdb pode ter aplicativos da web independentes. Como no couchdb, é de fato um servidor da web.

— Loïc Faure-Lacroix

41

Estou surpreso com 332 votos por uma resposta errada. MongoDB é CP por padrão e CouchDB é AP stackoverflow.com/questions/11292215/...

— Adnan Kamili

219

As respostas acima de tudo complicam a história.

Se você planeja ter um componente móvel ou precisa que os usuários de desktop trabalhem offline e sincronize o trabalho deles com um servidor, você precisa do CouchDB.
Se o seu código for executado apenas no servidor, vá com o MongoDB

É isso aí. A menos que você precise da capacidade (impressionante) do CouchDB de se replicar em dispositivos móveis e de desktop, o MongoDB tem atualmente a vantagem de desempenho, comunidade e ferramentas.

— Ewan Makepeace
fonte

18

Conciso, do jeito que eu gosto.

— Ely

Eu amo respostas simples e não muito técnicas como essa. Obrigado!

Esta resposta indica para quem procura móvel, offline e sincronização! graças

— Erik Kaplun

Eu ri quando li "replicar para dispositivo móvel" lol, quão pouco são os seus dados?

— Daniel W.

3

"lol, quão pouco são seus dados?" - isso é realmente uma coisa? Posso escolher o CDB porque meus dados são grandes - ou posso escolher porque tem uma replicação melhor do que as alternativas. Nesse caso, filtramos os conjuntos de dados para cerca de 100Mb-200Mb por dispositivo. Isso é uma coisa ruim?

— Ewan Makepeace

62

Pergunta muito antiga, mas está no topo do Google e eu não gosto das respostas que vejo, então aqui está a minha.

O Couchdb tem muito mais do que a capacidade de desenvolver o CouchApps. A maioria das pessoas usa o CouchDb em uma arquitetura da web clássica de três camadas.

Na prática, o fator decisivo para a maioria das pessoas será o fato de o MongoDb permitir consultas ad-hoc com uma sintaxe do tipo SQL, enquanto o CouchDb não (você precisa criar mapa / reduzir visualizações que desativa algumas pessoas, mesmo que essas visualizações sejam criadas). é rápido para o desenvolvimento rápido de aplicativos - eles não têm nada a ver com procedimentos armazenados).

Para abordar os pontos levantados na resposta aceita: O CouchDb possui um ótimo sistema de controle de versão, mas isso não significa que é adequado apenas (ou mais adequado) para locais onde o controle de versão é importante. Além disso, o couchdb é compatível com gravação pesada, graças à sua natureza apenas de acréscimo (as operações de gravação retornam em pouco tempo, garantindo que nenhum dado será perdido).

Uma coisa muito importante que não é mencionada por ninguém é o fato de o CouchDb confiar em índices de árvore b. Isso significa que, se você possui 1 "linha" ou 20 bilhões, o tempo de consulta sempre permanecerá abaixo de 10 ms. Este é um divisor de águas que faz do CouchDb um banco de dados de baixa latência e fácil de ler, e isso realmente não deve ser esquecido.

Para ser justo e exaustivo, a vantagem que o MongoDb tem sobre o CouchDb é o ferramental e o marketing. Eles possuem ferramentas cidadãs de primeira classe para todos os principais idiomas e plataformas, facilitando a integração e isso adicionado às consultas adhoc facilita ainda mais a transição do SQL.

O CouchDb não possui esse nível de ferramentas - mesmo que haja muitas bibliotecas disponíveis hoje -, mas o CouchDb é exposto como uma API HTTP e, portanto, é muito fácil criar um invólucro no seu idioma favorito para conversar com ele. Pessoalmente, gosto dessa abordagem, pois evita inchaço e permite que você tome apenas o que deseja (princípio de segregação de interface).

Então, eu diria que usar um ou outro é em grande parte uma questão de conforto e preferência com seus paradigmas. A abordagem do CouchDb "apenas se encaixa", para certas pessoas, mas se depois de aprender sobre os recursos do banco de dados (no exaustivo guia oficial ) você não tiver o seu momento "inferno sim", provavelmente deverá seguir em frente.

Eu desencorajaria o uso do CouchDb se você quiser usar "a ferramenta certa para o trabalho certo". porque você descobrirá que não pode usá-lo dessa maneira e acabará ficando chateado e escrevendo posts do blog como "Onde estão as associações no CouchDb?" e "Onde está o gerenciamento de transações?". Na verdade, Couchdb é - paradoxalmente - muito transparente, mas ao mesmo tempo exige uma mudança de paradigma e uma mudança na maneira como você aborda os problemas para realmente brilhar (e realmente funcionar).

Mas uma vez que você fez isso, realmente compensa. Eu, pessoalmente, precisaria de razões muito fortes ou de um grande rompimento de um projeto para escolher outro banco de dados, mas até agora não encontrei nenhum.

— tobiak777
fonte

12

Atualização 2016: Desde a versão 2.0 lançada em setembro de 2016, o CouchDB está apoiando ad-hoc consultas out-of-the-box :)

— tobiak777

1

CouchDb relies on b-tree indexes. This means that whether you have 1 "row" or 20 billions, the querying time will always remain below 10ms.

Isso não acontece com quase todos os bancos de dados? Desta forma, isso é expresso implica o contrário.

— Shelvacu 14/05/19

38

Faça você mesmo essas perguntas? E você decidirá sua seleção de banco de dados.

Você precisa de mestre-mestre ? Em seguida, o CouchDB. Principalmente, o CouchDB suporta replicação mestre-mestre, o que antecipa que os nós sejam desconectados por longos períodos de tempo. O MongoDB não se sairia bem nesse ambiente.
Você precisa de um rendimento máximo de R / W ? Então o MongoDB
Você precisa da máxima durabilidade de servidor único porque só terá um único servidor de banco de dados? Em seguida, o CouchDB.
Você está armazenando um conjunto de dados MASSIVO que precisa de fragmentação, mantendo uma taxa de transferência insana? Então MongoDB.
Você precisa de uma consistência forte dos dados? Então MongoDB.
Você precisa de alta disponibilidade do banco de dados? Em seguida, o CouchDB.
Você espera vários bancos de dados e várias tabelas / coleções? Então o MongoDB
Você tem usuários offline de um aplicativo móvel e deseja sincronizar os dados de atividades deles com um servidor? Então você precisa do CouchDB.
Você precisa de uma grande variedade de mecanismos de consulta ? Então o MongoDB
Você precisa de uma comunidade grande para usar o DB? Então o MongoDB

— Somnath Muluk
fonte

# 9 é um empate virtual entre o CouchDB e o MongoDB a partir do CouchDB 2.x.

— Flimzy

27

Resumo as respostas encontradas nesse artigo:

http://www.quora.com/How-does-MongoDB-compare-to-CouchDB-What-are-the-advantages-and-disadvantages-of-each

MongoDB: Melhor consulta, armazenamento de dados em BSON (acesso mais rápido), melhor consistência de dados, várias coleções

CouchDB: Melhor replicação, com replicação master a master e resolução de conflitos, armazenamento de dados em JSON (legível por humanos, melhor acesso por meio de serviços REST), consulta por meio de redução de mapa.

Portanto, em conclusão, o MongoDB é mais rápido, o CouchDB é mais seguro.

Também: http://nosql.mypopescu.com/post/298557551/couchdb-vs-mongodb

— Alexis Dufrenoy
fonte

7

Resposta útil, mas é difícil gostar da conclusão.

— precisa

O que você quer dizer com "difícil de gostar"?

— Alexis Dufrenoy #

23

Esteja ciente de um problema com índices únicos esparsos no MongoDB. Eu bati nele e é extremamente complicado de contornar.

O problema é este: você tem um campo que é único, se presente, e deseja encontrar todos os objetos em que o campo está ausente. A maneira como índices únicos esparsos são implementados no Mongo é que os objetos em que esse campo está ausente não estão no índice - eles não podem ser recuperados por uma consulta nesse campo - {$exists: false}simplesmente não funcionam.

A única solução alternativa que encontrei é ter uma família de valores nulos especiais, em que um valor vazio é convertido em um prefixo especial (como null :) concatenado em um uuid. É uma verdadeira dor de cabeça, porque é preciso cuidar da transformação de / para os valores vazios ao escrever / consultar / ler. Um grande incômodo.

Eu nunca usei a execução de javascript no servidor no MongoDB (não é recomendado de qualquer maneira) e seu mapa / redução apresenta um desempenho terrível quando há apenas um nó Mongo. Por todos esses motivos, agora estou pensando em conferir o CouchDB, talvez ele se encaixe mais no meu cenário específico.

BTW, se alguém souber o link para o respectivo problema do Mongo que descreve o escasso problema de índice exclusivo - compartilhe.

— marca
fonte

3

Sinto muito, mas eu tenho essa sensação incômoda de que não é uma boa idéia e é um sentimento que eu tenho aprendido a não ignorar

— eaglestorm

8

Bem, não posso discutir com um sentimento. Tudo o que sei é que eu precisava de índices únicos esparsos, por causa dos campos opcionais, que são únicos se presentes.

— marca de

37

Entendo que você tem um caso de uso real que descreve o problema, mas e o meu intestino?

— Chev 22/03

14

Eu não sei. Que tal isso?

— marca de

2

ROTFL. +1 Alex Ford e marque seus comentários hilariantes. :-)) @mark, não tenho certeza se os problemas listados realmente justificam a mudança do MongoDB para o CouchDB. Não trabalhei com o MongoDB nem com o CouchDB, mas meu instinto me diz que você encontrará outras limitações complexas com o CouchDB e perderá mais tempo trabalhando com elas. Se você já dominou o MongoDB, provavelmente deve ficar com ele. Mas, novamente, eu nunca estive na terra do Nosql, este é apenas o meu intestino.

— MiniQuark

6

Tenho certeza que você pode com o Mongo (mais familiarizado com ele) e com o sofá também.

Ambos são orientados a documentos (baseados em JSON), portanto não haveria "colunas", mas campos nos documentos - mas eles podem ser totalmente dinâmicos.

Ambos fazem isso, você pode querer considerar outros fatores sobre os quais usar: outros recursos importantes, popularidade, etc. Insights do Google e, certamente, as vagas de emprego.com seriam maneiras de analisar a popularidade.

Você pode tentar, acho que você deve ter o mongo rodando em 5 minutos.

— dm.
fonte