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.
mongodb
performance
comparison
couchdb
nosql
Luke101
fonte
fonte
Respostas:
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
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,
Uma comparação recente (fevereiro de 2012) e mais abrangente de Riyad Kalla,
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.
fonte
As respostas acima de tudo complicam a história.
É 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.
fonte
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.
fonte
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.Faça você mesmo essas perguntas? E você decidirá sua seleção de banco de dados.
fonte
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
fonte
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.
fonte
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.
fonte