Quando utilizar CouchDB sobre MongoDB e vice-versa

As respostas acima de tudo complicam a história.

1. se planeia ter um componente móvel, ou se precisa que os utilizadores do ambiente de trabalho trabalhem offline e depois sincronizem o seu trabalho com um servidor, precisa do CouchDB.
2. Se o seu código for executado apenas no servidor, então vá com o MongoDB

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

É uma pergunta muito antiga, mas está em cima do Google e não gosto das respostas que vejo, por isso aqui está a minha. Há muito mais para Couchdb do que a capacidade de desenvolver CouchApps. A maioria das pessoas usa CouchDb em uma arquitetura clássica de três níveis.

Na prática, o factor decisivo para a maioria das pessoas será o facto de o MongoDb permitir uma consulta ad-hoc com uma sintaxe SQL como a do CouchDb (tem de criar mapas / reduzir vistas que desliguem algumas pessoas, mesmo que criar estes pontos de vista é rápido desenvolvimento de Aplicação amigável - eles não têm nada a ver com procedimentos armazenados).

Para abordar os pontos levantados na resposta aceite: o CouchDb tem um grande sistema de versionamento, mas não significa que seja apenas adequado (ou mais adequado) para lugares onde o versionning é importante. Além disso, couchdb é muito amigável graças à sua natureza apend-only (escreve operações retornam em nenhum momento, garantindo que nenhum dado jamais será perdido).

Um muito o importante que não é mencionado por ninguém é o fato de que CouchDb baseia-se em índices b-tree. Isto significa que quer você tenha 1 "linha" ou 20 bilhões, o tempo de perguntas sempre permanecerá abaixo de 10ms. esta é uma mudança de jogo que faz CouchDb um banco de dados de baixa latência e leitura amigável, e isso realmente não deve ser negligenciado.

Para ser justo e exaustivo, a vantagem que o MongoDb tem sobre a CouchDb é o equipamento e o marketing. Eles têm ferramentas cidadãs de primeira classe para todas as principais línguas e plataformas que facilitam o embarque e isso adicionado à sua consulta adhoc torna a transição do SQL ainda mais fácil.

O CouchDb não tem este nível de ferramentas - apesar de existirem muitas bibliotecas disponíveis hoje -, mas o CouchDb é exposto como uma API HTTP e, portanto, é muito fácil criar um invólucro na sua língua favorita para falar com ele. Eu pessoalmente gosto desta abordagem, uma vez que evita inchaço e permite que você só leve o que você quer (segregação de interface principio).

Então eu diria que usar um ou outro é em grande parte uma questão de conforto e preferência com seus paradigmas. Abordagem CouchDb" just fits", para certas pessoas, mas se depois de aprender sobre as características da base de dados (no exaustivo guia oficial) Você não tem o seu momento "hell yeah", você provavelmente deve seguir em frente. Eu desencorajaria o uso do CouchDb se você quisesse usar "a ferramenta certa para o trabalho certo". porque vais descobrir que não podes usá-lo assim. way e você vai acabar ficando chateado e escrevendo posts no blog como " Where are joins in CouchDb ?"e" Where is transaction management ?". Na verdade Couchdb é - paradoxalmente-muito transparente, mas ao mesmo tempo requer uma mudança de paradigma e uma mudança na maneira como você aborda os problemas para realmente brilhar (e realmente trabalhar). Mas uma vez feito isso, compensa. Eu, pessoalmente, precisaria de razões muito fortes ou uma grande quebra de negócio em um projeto para escolher outra base de dados, mas até agora eu não conheci nenhum.

Faz estas perguntas sozinho? E você vai decidir a sua seleção de DB.

Precisas do Mestre-Mestre? Depois CouchDB. Principalmente CouchDB suporta replicação master-master que prevê que os nós sejam desconectados por longos períodos de tempo. MongoDB não faria bem nesse ambiente.
1. precisa deCapacidade máxima de R/W ? Então MongoDB
2. você precisa de durabilidade final de servidor único porque você só vai ter um único DB servidor? Depois CouchDB.
Está a guardar um conjunto de dados massivos que precisa de ser afiado, mantendo um rendimento insano? Depois MongoDB.
3. precisa de uma forte consistência de dados? Depois MongoDB.
4. você precisa de alta disponibilidade da base de dados? Depois CouchDB.
5. está à espera de várias bases de dados e várias tabelas/ colecções? Então MongoDB
6. Você tem um app móvel utilizadores offline e quer sincronizar os seus dados de actividade para um servidor? Então precisas do CouchDB.
Precisas de uma grande variedade de motores? Então MongoDB
7. precisas de uma comunidade grande para usar DB? Então MongoDB

Resumindo 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 pesquisa, armazenamento de dados em BSON (acesso mais rápido), melhor consistência de dados, múltiplas recolhas

CouchDB: melhor replicação, com mestre para mestre replicação e resolução de conflitos, armazenamento de dados em JSON( legível pelo homem, melhor acesso através de serviços de repouso), questionamento através do mapa-reduzir.

Para concluir, o MongoDB é mais rápido, o CouchDB é mais seguro.

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

Esteja ciente de um problema com índices únicos esparsos em MongoDB. Bati - lhe e é extremamente complicado trabalhar.

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

A a única solução que encontrei é ter uma família de valores nula especial, onde um valor vazio é traduzido para um prefixo especial (como null:) concatenado para um uuid. Esta é uma dor de cabeça real, porque é preciso ter cuidado para transformar a / dos valores vazios ao escrever/questionar / ler. Um grande incómodo.

Nunca usei a execução javascript do lado do servidor em MongoDB (não é aconselhável de qualquer forma) e o seu mapa / redução tem um desempenho horrível quando há apenas um Mongo no. Por todas estas razões, estou agora a considerar verificar o CouchDB, talvez se encaixe mais no meu cenário particular.

BTW, se alguém souber o link para a respectiva edição Mongo descrevendo o problema do índice único esparso-por favor, partilhe.

Tenho a certeza que consegues com o Mongo (mais familiarizado com ele), e com o sofá também.

Ambos são documentados orientados (baseados em JSON) de modo que não haveria "colunas", mas sim campos em documentos -- mas eles podem ser totalmente dinâmicos.

Ambos o fazem você pode querer olhar para outros fatores sobre os quais usar: outras características que você se preocupa, popularidade, etc. Google insights, indeed.com postos de trabalho seriam maneiras de olhar para a popularidade.

Podes tentar. acho que deves conseguir pôr o mongo a funcionar dentro de 5 minutos.