Pregunta Cuándo usar CouchDB en MongoDB y viceversa


Estoy atrapado entre estas dos bases de datos NoSQL.

En mi proyecto, crearé una base de datos dentro de una base de datos. Por ejemplo, necesito una solución para crear tablas dinámicas.

Entonces los usuarios pueden crear tablas con columnas y filas. Creo que tanto MongoDB como CouchDB serán buenos para esto, pero no estoy seguro de cuál. También necesitaré una paginación eficiente también.


580
2017-09-15 13:32


origen


Respuestas:


De C, A y P (consistencia, disponibilidad y tolerancia de partición), ¿cuáles 2 son más importantes para usted? Referencia rápida, el Guía visual a los sistemas NoSQL

  • MongodB: consistencia y tolerancia de partición
  • CouchDB: disponibilidad y tolerancia de partición

Una publicación de blog, Comparación entre Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase vs Membase vs Neo4j tiene 'Mejor usado'escenarios comparados para cada base de datos NoSQL. Citando el enlace,

  • MongoDB: si necesita consultas dinámicas. Si prefiere definir índices, no asignar / reducir funciones. Si necesita un buen rendimiento en una gran base de datos. Si quería CouchDB, pero sus datos cambian demasiado, llenando los discos.
  • CouchDB: para acumular, de vez en cuando, datos cambiantes, en los que se deben ejecutar consultas predefinidas. Lugares donde el control de versiones es importante.

Un reciente (feb 2012) y más comparación completa por Riyad Kalla,

  • MongoDB: Replicación maestro-esclavo SOLAMENTE
  • CouchDB: Replicación Master-Master

Una publicación de blog (octubre de 2011) escrita por alguien que intentó ambos, Un MongoDB Guy Learns CouchDB comentó que la búsqueda de CouchDB no era tan útil.

A fechado (junio de 2009) punto de referencia por Kristina Chodorow (parte del equipo detrás de MongoDB),

Yo iría por MongoDB.

Espero eso ayude.


483
2017-09-16 05:37



Las respuestas sobre todo complican la historia.

  1. Si planea tener un componente móvil, o necesita usuarios de escritorio para trabajar sin conexión y luego sincronizar su trabajo con un servidor, necesita CouchDB.
  2. Si su código se ejecutará solo en el servidor, entonces vaya con MongoDB

Eso es. A menos que necesite la increíble capacidad de CouchDB para replicarse en dispositivos móviles y de escritorio, MongoDB tiene actualmente la ventaja en desempeño, comunidad y herramientas.


178
2018-02-18 03:29



Es una pregunta muy antigua, pero está en la parte superior de Google y no me gustan las respuestas que veo, así que aquí está la mía.

Hay mucho más para Couchdb que la capacidad de desarrollar CouchApps. La mayoría de las personas usa CouchDb en una arquitectura web clásica de 3 niveles.

En la práctica, el factor decisivo para la mayoría de las personas será el hecho de que MongoDb permite consultas ad-hoc con una sintaxis similar a la de SQL, mientras que CouchDb no (tiene que crear vistas de mapa / reducir que algunas personas se desconecten aunque creen estas vistas el desarrollo rápido de aplicaciones es amigable, no tienen nada que ver con los procedimientos almacenados).

Para abordar los puntos planteados en la respuesta aceptada: CouchDb tiene un excelente sistema de versión, pero no significa que solo es adecuado (o más adecuado) para lugares donde la versión es importante. Además, couchdb es amigable para escritura pesada gracias a su naturaleza de solo agregar (las operaciones de escritura se vuelven en poco tiempo, al tiempo que garantiza que nunca se perderán datos).

Una cosa muy importante que no menciona nadie es el hecho de que CouchDb se basa en índices b-tree. Esto significa que ya sea que tenga 1 "fila" o 20 mil millones, el tiempo de consulta siempre permanecerá por debajo de 10 ms. Este es un cambio de juego que hace de CouchDb una base de datos de baja latencia y fácil de leer, y esto realmente no debe pasarse por alto.

Para ser justos y exhaustivos, la ventaja que MongoDb tiene sobre CouchDb es el uso de herramientas y el marketing. Disponen de herramientas ciudadanas de primera clase para todos los principales lenguajes y plataformas que facilitan la incorporación y esto, sumado a su consulta adhoc, facilita aún más la transición desde SQL.

CouchDb no tiene este nivel de herramientas, a pesar de que hay muchas bibliotecas disponibles en la actualidad, pero CouchDb está expuesto como una API HTTP y, por lo tanto, es bastante fácil crear un contenedor en su idioma favorito para hablar con él. Personalmente me gusta este enfoque, ya que evita la hinchazón y le permite tomar solo lo que quiera (principio de segregación de la interfaz).

Así que diría que usar uno u otro es en gran medida una cuestión de comodidad y preferencia con sus paradigmas. El enfoque CouchDb "simplemente se ajusta", para ciertas personas, pero si después de conocer las características de la base de datos (en el guía oficial) no tienes tu momento de "infierno, sí", probablemente deberías seguir adelante.

Disuadiría usar CouchDb si solo quiere usar "la herramienta correcta para el trabajo correcto". porque descubrirás que no puedes usarlo de esa manera y acabarás enfadado y escribiendo publicaciones de blog como "¿Dónde están las uniones en CouchDb?" y "¿Dónde está la gestión de transacciones?". De hecho, Couchdb es, paradójicamente, muy transparente, pero al mismo tiempo requiere un cambio de paradigma y un cambio en la forma de enfocar los problemas para realmente brillar (y realmente funcionar).

Pero una vez que lo has hecho, realmente vale la pena. Personalmente, necesito razones muy importantes o un factor decisivo en un proyecto para elegir otra base de datos, pero hasta ahora no he encontrado ninguna.


38
2018-06-04 16:38



Haz estas preguntas tú mismo? Y usted decidirá su selección de DB.

  1. Necesitas maestro maestro? Entonces CouchDB. Principalmente, CouchDB es compatible con la replicación maestra maestra, que anticipa que los nodos se desconecten por largos períodos de tiempo. MongoDB no haría bien en ese entorno.
  2. Necesitas MÁXIMO rendimiento R / W? Entonces MongoDB
  3. Necesitas ultimo durabilidad de un solo servidor porque solo vas a tener un solo servidor de base de datos? Entonces CouchDB.
  4. ¿Estás almacenando un Datos MASIVOS conjunto que necesita fragmentación mientras se mantiene el rendimiento loco Entonces MongoDB.
  5. Necesitas fuerte consistencia ¿de datos? Entonces MongoDB.
  6. Necesitas alto disponibilidad de la base de datos? Entonces CouchDB.
  7. ¿Estás esperando? múltiples bases de datos y multi mesas / colecciones? Entonces MongoDB
  8. Usted tiene un aplicación móvil usuarios fuera de línea y desea sincronizar sus datos de actividad a un servidor? Entonces necesitas CouchDB.
  9. ¿Necesita una gran variedad de preguntando ¿motor? Entonces MongoDB
  10. ¿Necesitas grandes comunidad estar usando DB? Entonces MongoDB

26
2017-08-11 17:04



Resumiré las respuestas encontradas en ese artículo:

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

MongoDB: Mejor consulta, almacenamiento de datos en BSON (acceso más rápido), mejor consistencia de datos, múltiples colecciones

CouchDB: Mejor replicación, con replicación maestra para dominar y resolución de conflictos, almacenamiento de datos en JSON (legible para los humanos, mejor acceso a través de servicios REST), consultas a través de map-reduce.

Entonces, en conclusión, MongoDB es más rápido, CouchDB es más seguro.

También: http://nosql.mypopescu.com/post/298557551/couchdb-vs-mongodb


23
2018-05-28 14:11



Tenga en cuenta un problema con índices únicos dispersos en MongoDB. Lo he golpeado y es extremadamente engorroso para la solución.

El problema es este: tiene un campo, que es único si está presente y desea encontrar todos los objetos donde el campo está ausente. La forma en que se implementan los índices únicos dispersos en Mongo es que los objetos donde ese campo falta no están en absoluto en el índice, no pueden ser recuperados por una consulta en ese campo, {$exists: false} simplemente no funciona.

La única solución que he encontrado es tener una familia nula de valores especial, donde un valor vacío se traduce a un prefijo especial (como nulo:) concatenado a un uuid. Este es un verdadero dolor de cabeza, porque uno tiene que encargarse de transformar los valores vacíos al escribir / buscar / leer. Una gran molestia.

Nunca he usado la ejecución javascript en el servidor en MongoDB (no se recomienda de todos modos) y su mapa / reducción tiene un rendimiento horrible cuando solo hay un nodo Mongo. Debido a todas estas razones, ahora estoy considerando echar un vistazo a CouchDB, tal vez se ajusta más a mi situación particular.

Por cierto, si alguien conoce el enlace al problema de Mongo correspondiente que describe el problema del índice único disperso, por favor compártelo.


19
2018-02-03 22:05



Estoy seguro de que puedes con Mongo (más familiarizado con él), y bastante seguro de que también puedes hacerlo con el sofá.

Ambos están documentados (basados ​​en JSON) por lo que no habría "columnas" sino campos en los documentos, pero pueden ser completamente dinámicos.

Ambos lo hacen, es posible que desee ver otros factores que utilizar: otras características que le interesan, la popularidad, etc. Las estadísticas de Google, las publicaciones de trabajo de Indeed.com serían formas de ver la popularidad.

Podrías intentarlo, creo que deberías poder correr mongo en 5 minutos.


3
2017-09-15 15:49