Cuándo usar CouchDB sobre MongoDB y viceversa

638

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.

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

— Lucas101
fuente

19

Deseo que modifiquen el sistema para facilitar la creación de la pregunta sobre el tema que están buscando y para dirigir mejor a los usuarios a esa pregunta. No tengo idea si alguna vez se abordó esta pregunta y no hay una manera conveniente de localizarla.

— doub1ejack

45

Deseo que agreguen la funcionalidad en este sitio web donde podríamos "votar" o "votar" la razón dada a esta pregunta como "fuera de tema", lo que podría ayudar a volver este tipo de preguntas a "tema".

— Sanjay

99

++ No me queda claro por qué esto está fuera de tema. La pregunta hace tener respuestas objetivas claras - el PO no está pidiendo opinión, pero para obtener información objetiva sobre estos dos sistemas. user799188 proporcionó una gran respuesta objetiva.

— user48956

3

Supongo que los administradores solo miran la pregunta si contiene algún código y no el tipo de información que se busca. Por cierto, siempre puedes votar para volver a abrir la pregunta.

— Tarun

11

La pregunta se volvió a abrir. Bienvenidos de nuevo a todos ...

— Alexis Dufrenoy

523

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

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

Una publicación de blog, Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase vs Membase vs Neo4j, la comparación tiene escenarios ' Mejor utilizados ' para cada base de datos NoSQL comparada. 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 datos que cambian ocasionalmente, en los que se ejecutarán consultas predefinidas. Lugares donde las versiones son importantes.

Una comparación reciente (febrero de 2012) y más completa de Riyad Kalla,

MongoDB: replicación maestro-esclavo SOLAMENTE
CouchDB: replicación maestro-maestro

Una publicación de blog (octubre de 2011) de alguien que probó ambas cosas, A MongoDB Guy Learns CouchDB comentó que la paginación de CouchDB no es tan útil.

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

Yo iría por MongoDB.

Espero eso ayude.

— usuario799188
fuente

8

Por lo que entiendo, MongoDB no es consistente de ninguna manera: ivoras.sharanet.org/blog/tree/…

— sheerun

2

Buena información para la época, pero esto es muy antiguo ... muchas cosas han cambiado (incluidas las interfaces REST para Mongo).

— rICh

44

Creo que puede ser un poco engañoso, pero versionar en couchdb no es un argumento. El esquema de control de versiones utilizado por couchdb no debe usarse como control de versiones por ejemplo. Se utiliza para manejar particiones. Durante una compactación de la base de datos, las revisiones se eliminarán como realmente borradas. Y solo las cadenas de revoluciones deben permanecer en la base de datos. Si desea manejar versiones en couchdb, debe hacerlo tal como se podría hacer en mongodb.

— Loïc Faure-Lacroix

2

Agregaría a la lista que couchdb puede tener aplicaciones web independientes. Como en couchdb es, de hecho, un servidor web.

— Loïc Faure-Lacroix

41

Me sorprenden 332 votos por una respuesta incorrecta. MongoDB es CP por defecto y CouchDB es AP stackoverflow.com/questions/11292215/…

— adnan kamili

219

Las respuestas sobre todo complican la historia.

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

Eso es. A menos que necesite la capacidad (increíble) de CouchDB para replicarse en dispositivos móviles y de escritorio, MongoDB tiene la ventaja de rendimiento, comunidad y herramientas en la actualidad.

— Ewan Makepeace
fuente

18

Conciso, como a mí me gusta.

— Ely

Me encantan las respuestas simples, no demasiado técnicas, como esta. ¡Gracias!

¡Esta respuesta es perfecta para aquellos que buscan dispositivos móviles, sin conexión y sincronizados! gracias

— Erik Kaplun

Me reí cuando leí "replicar a dispositivo móvil" lol ¿qué tan pocos son tus datos?

— Daniel

3

"jaja, ¿qué tan pocos son tus datos?" - ¿Es eso realmente una cosa? Podría elegir CDB porque mis datos son grandes, o podría elegirlo porque tiene una mejor replicación que las alternativas. En este caso, filtramos los conjuntos de datos a aproximadamente 100Mb-200Mb por dispositivo. ¿Es eso algo malo?

— Ewan Makepeace

62

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.

Couchdb es mucho más que la capacidad de desarrollar CouchApps. La mayoría de las personas usan 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 SQL, mientras que CouchDb no (debe crear un mapa / reducir vistas que apaga a algunas personas a pesar de crear estas vistas) es rápido para el desarrollo de aplicaciones: no tienen nada que ver con los procedimientos almacenados).

Para abordar los puntos planteados en la respuesta aceptada: CouchDb tiene un excelente sistema de versiones, pero eso no significa que solo sea adecuado (o más adecuado) para los lugares donde las versiones son importantes. Además, couchdb es fácil de escribir gracias a su naturaleza de solo agregar (las operaciones de escritura regresan en muy poco tiempo al tiempo que garantiza que nunca se perderán datos).

Una cosa muy importante que nadie menciona es el hecho de que CouchDb se basa en índices de b-tree. Esto significa que si tiene 1 "fila" o 20 mil millones, el tiempo de consulta siempre será inferior a 10 ms. Este es un cambio de juego que hace que CouchDb sea 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 herramental y el marketing. Tienen herramientas ciudadanas de primera clase para todos los principales idiomas y plataformas que facilitan la incorporación y esto, sumado a sus consultas ad hoc, hace que la transición de SQL sea aún más fácil.

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 desea (principio de segregación de interfaz).

Entonces, diría que usar uno u otro es en gran medida una cuestión de comodidad y preferencia con sus paradigmas. El enfoque de CouchDb "simplemente encaja", para ciertas personas, pero si después de conocer las características de la base de datos (en la exhaustiva guía oficial ) no tiene su momento de "demonios, sí", probablemente debería seguir adelante.

Desalentaría el uso de CouchDb si solo desea usar "la herramienta adecuada para el trabajo correcto". porque descubrirás que no puedes usarlo de esa manera y terminarás enojado 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 abordar los problemas para que realmente brille (y realmente funcione).

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

— tobiak777
fuente

12

Actualización 2016: desde la versión 2.0 lanzada en septiembre de 2016, CouchDb admite consultas ad-hoc

— listas para usar

1

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.

¿No es esto cierto en casi todas las bases de datos? De esta manera, esto está redactado implica lo contrario.

— Shelvacu

38

Haga estas preguntas usted mismo? Y usted decidirá su selección de base de datos.

¿Necesitas maestro-maestro ? Entonces CouchDB. Principalmente CouchDB admite la replicación maestro-maestro que anticipa que los nodos se desconecten durante largos períodos de tiempo. MongoDB no lo haría bien en ese entorno.
¿Necesita un rendimiento MÁXIMO R / W ? Entonces MongoDB
¿Necesita la máxima durabilidad de un solo servidor porque solo va a tener un único servidor de base de datos? Entonces CouchDB.
¿Está almacenando un conjunto de datos MASIVO que necesita fragmentación mientras se mantiene un rendimiento loco? Entonces MongoDB.
¿Necesita una fuerte consistencia de datos? Entonces MongoDB.
¿Necesita alta disponibilidad de base de datos? Entonces CouchDB.
¿Espera múltiples bases de datos y múltiples tablas / colecciones? Entonces MongoDB
¿Tiene usuarios de una aplicación móvil sin conexión y desea sincronizar sus datos de actividad con un servidor? Entonces necesitas CouchDB.
¿Necesita una gran variedad de motor de consulta ? Entonces MongoDB
¿Necesita una gran comunidad para usar DB? Entonces MongoDB

— Somnath Muluk
fuente

# 9 es un empate virtual entre CouchDB y MongoDB a partir de CouchDB 2.x.

— Flimzy

27

Resumo 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 de maestro a maestro y resolución de conflictos, almacenamiento de datos en JSON (legible para humanos, mejor acceso a través de servicios REST), consultas a través de map-reduce.

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

— Alexis Dufrenoy
fuente

77

Respuesta útil, pero la conclusión es difícil de gustar.

— Erik Kaplun

¿Qué quieres decir con "difícil de gustar"?

— Alexis Dufrenoy

23

Tenga en cuenta un problema con índices únicos dispersos en MongoDB. Lo he golpeado y es extremadamente engorroso solucionarlo.

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 índices únicos dispersos en Mongo es que los objetos en los que falta ese campo no se encuentran en el índice, no pueden ser recuperados por una consulta en ese campo, {$exists: false}simplemente no funcionan.

La única solución que he encontrado es tener una familia especial de valores nulos, donde un valor vacío se traduce a un prefijo especial (como nulo :) concatenado a un uuid. Esto es un verdadero dolor de cabeza, porque uno tiene que cuidar la transformación hacia / desde los valores vacíos al escribir / consultar / leer. Una gran molestia.

Nunca he usado la ejecución de JavaScript del lado del servidor en MongoDB (de todos modos no se recomienda) 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 ajuste más a mi escenario particular.

Por cierto, si alguien conoce el enlace al problema respectivo de Mongo que describe el escaso problema del índice único, por favor comparta.

— marca
fuente

3

Lo siento, pero tengo la persistente sensación de que no es una buena idea y es una sensación que he aprendido a no ignorar

— Eaglestorm

8

Bueno, no puedo discutir con un sentimiento. Todo lo que sé es que necesitaba índices únicos dispersos, debido a los campos opcionales, que son únicos si están presentes.

— marca el

37

Entiendo que tiene un caso de uso real que describe el problema, pero ¿qué pasa con mi instinto?

— Chev

14

Yo no sé. ¿Qué hay de eso?

— marca el

2

ROTFL. +1 Alex Ford y marca por tus divertidos comentarios. :-)) @mark, no estoy seguro de que los problemas que enumeres realmente justifiquen el cambio de MongoDB a CouchDB. No he trabajado ni con MongoDB ni con CouchDB, pero mi instinto me dice que te encontrarás con otras limitaciones complejas con CouchDB y perderás más tiempo trabajando en ellas. Si ahora ha dominado MongoDB, entonces probablemente debería quedarse con él. Pero, de nuevo, nunca he estado en Nosql-land, esto es solo mi instinto de hablar.

— MiniQuark

6

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

Ambos están orientados a documentos (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 sobre los que puede usar: otras características que le interesan, popularidad, etc. Las ideas de Google, las publicaciones de trabajo de Indeed.com serían formas de ver la popularidad.

Podrías probarlo, creo que deberías poder ejecutar a mongo en 5 minutos.

— dm.
fuente