Si viene del mundo de MySQL, MongoDB se "sentirá" mucho más natural para usted debido a su soporte de lenguaje similar a la consulta.
Creo que eso es lo que lo hace tan amigable para mucha gente.
CouchDB es fantástico si desea utilizar el excelente soporte de replicación maestro-maestro con una configuración de múltiples nodos, posiblemente en diferentes centros de datos o algo así.
La replicación de MongoDB (conjuntos de réplica) es una configuración maestro-esclavo-esclavo-esclavo- *, solo puede escribir al maestro en un conjunto de réplica y leer desde cualquiera de ellos.
Para una configuración de sitio estándar, está bien. Se asigna al uso de MySQL realmente bien.
Pero si está tratando de crear un servicio global como un CDN que necesita mantener todos los nodos globales sincronizados a pesar de leer / escribir en todos ellos, algo como la replicación en CouchDB será de gran ayuda para usted.
Si bien MongoDB tiene un lenguaje de consulta que puede usar y se siente muy intuitivo, CouchDB adopta un enfoque de "reducción de mapas" y estos conceptos de vistas. Al principio se siente extraño, pero a medida que se acostumbra, realmente comienza a sentirse intuitivo.
Aquí hay una descripción rápida, por lo que tiene sentido:
- CouchDB almacena todos sus datos en un árbol b
- No puede "consultarlo" dinámicamente con algo como "SELECCIONAR * DESDE el usuario DONDE ..."
- En su lugar, define "vistas" discretas de sus datos ... "aquí está una vista de todos mis usuarios", "aquí está una vista de todos los usuarios mayores de 10" "aquí está una vista de todos los usuarios mayores de 30" y pronto.
- Estas vistas se definen mediante el enfoque de reducción de mapas y se definen como funciones de JavaScript.
- Cuando define una vista, la base de datos comienza a alimentar todos los documentos de la base de datos a la que asignó la vista, a través de ella y registra los resultados de sus funciones como el "índice" en esos datos.
- Hay algunas consultas básicas que puede hacer en las vistas, como solicitar una clave específica (ID) o un rango de ID, independientemente de lo que haga su función de mapa / reducción.
- Lea estas diapositivas , es la mejor aclaración de mapa / reducción en Couch que he visto.
Entonces, ambas fuentes usan documentos JSON, pero CouchDB sigue este enfoque más "cada servidor es un maestro y puede sincronizarse con el mundo", lo cual es fantástico si lo necesita, mientras que MongoDB es realmente el MySQL del mundo NoSQL.
Entonces, si eso suena más como lo que necesitas / quieres, ve por eso.
Pequeñas diferencias como el protocolo binario de Mongo frente a la interfaz RESTful de CouchDB son detalles menores.
Si desea una velocidad sin procesar y al infierno con la seguridad de los datos, puede hacer que Mongo funcione más rápido que CouchDB, ya que puede decir que funcione sin memoria y que no envíe cosas al disco, excepto por intervalos escasos.
Puede hacer lo mismo con Couch, pero su protocolo de comunicación basado en HTTP va a ser 2-4 veces más lento que la comunicación binaria sin procesar con Mongo en esta "velocidad sobre todo". guión.
Tenga en cuenta que la velocidad loca loca es inútil si un bloqueo del servidor o una falla del disco corrompe y brinda por descuido a su DB, por lo que ese punto de datos no es tan sorprendente como podría parecer (a menos que esté haciendo sistemas de comercio en tiempo real en Wall Street, en cuyo caso mira Redis).
Espero que todo ayude!