Se você é oriundo do mundo MySQL, o MongoDB "se sentirá" muito mais natural por causa de seu suporte à linguagem semelhante a consultas.
Eu acho que é o que o torna tão amigável para muitas pessoas.
O CouchDB é fantástico se você deseja utilizar o excelente suporte à replicação master-master com uma configuração de vários nós, possivelmente em diferentes data centers ou algo assim.
A replicação do MongoDB (conjuntos de réplicas) é uma configuração mestre-escravo-escravo-escravo *, você só pode gravar no mestre em um conjunto de réplicas e ler qualquer um deles.
Para uma configuração de site padrão, tudo bem. Ele mapeia muito bem o uso do MySQL.
Mas se você estiver tentando criar um serviço global como uma CDN que precise manter todos os nós globais sincronizados, mesmo que a leitura / gravação para todos eles, algo como a replicação no CouchDB será um grande benefício para você.
Embora o MongoDB tenha uma linguagem de consulta que você possa usar e pareça muito intuitiva, o CouchDB adota uma abordagem de "redução de mapa" e esse conceito de visualizações. Parece estranho no começo, mas quando você pega o jeito, realmente começa a parecer intuitivo.
Aqui está uma rápida visão geral, portanto faz algum sentido:
- O CouchDB armazena todos os seus dados em uma árvore b
- Você não pode "consultá-lo" dinamicamente com algo como "SELECT * FROM user WHERE ..."
- Em vez disso, você define "visões" discretas dos seus dados ... "aqui é uma visão de todos os meus usuários", "aqui é uma visão de todos os usuários com mais de 10 anos" "aqui é uma visão de todos os usuários com mais de 30 anos" e em breve.
- Essas visualizações são definidas usando a abordagem de redução de mapa e são definidas como funções JavaScript.
- Quando você define uma visualização, o banco de dados começa a alimentar todos os documentos do banco de dados aos quais você atribuiu a visualização, registrando os resultados de suas funções como o "índice" desses dados.
- Existem algumas consultas básicas que você pode fazer nas visualizações, como solicitar uma chave (ID) específica ou um intervalo de IDs, independentemente do que sua função de mapa / redução faça.
- Leia estes slides , é o melhor esclarecimento de mapa / redução no sofá que eu já vi.
Portanto, essas duas fontes usam documentos JSON, mas o CouchDB segue mais essa abordagem "todo servidor é mestre e pode sincronizar com o mundo", o que é fantástico se você precisar, enquanto o MongoDB é realmente o MySQL do mundo NoSQL.
Portanto, se isso soa mais como o que você precisa / deseja, faça isso.
Pequenas diferenças, como o protocolo binário do Mongo e a interface RESTful do CouchDB, são todos pequenos detalhes.
Se você deseja velocidade bruta e muita segurança na segurança dos dados, pode fazer com que o Mongo execute mais rápido que o CouchDB, pois ele pode operar com memória insuficiente e não comprometer coisas no disco, exceto por intervalos esparsos.
Você pode fazer o mesmo com o Couch, mas o protocolo de comunicação baseado em HTTP será 2-4x mais lento que a comunicação binária bruta com o Mongo nesta "velocidade sobre tudo!" cenário.
Lembre-se de que a velocidade insana louca é inútil se uma pane no servidor ou falha no disco corromper e colocar seu banco de dados no esquecimento, para que o ponto de dados não seja tão incrível quanto possa parecer (a menos que você esteja realizando sistemas de negociação em tempo real no Wall Street, nesse caso, veja Redis).
Espero que tudo ajude!