utilidad - resumen de la historia de mongodb
Cuándo usar CouchDB sobre MongoDB y viceversa (7)
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.
Así los usuarios pueden 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é una paginación eficiente también.
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 para sistemas NoSQL.
- MongodB: Consistencia y Tolerancia de Partición
- CouchDB: Disponibilidad y tolerancia de partición
Una comparación en el blog, Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase vs Membase vs Neo4j tiene los escenarios de " Mejor uso " para cada base de datos NoSQL comparada. Citando el enlace,
- MongoDB: Si necesita consultas dinámicas. Si prefiere definir índices, no mapear / reducir funciones. Si necesitas un buen rendimiento en una gran base de datos. Si quería CouchDB, pero sus datos cambian demasiado, llenando los discos.
- CouchDB: para la acumulación, ocasionalmente, de datos, en los que se ejecutan consultas predefinidas. Lugares donde el versionado es importante.
Una comparación reciente (febrero de 2012) y más completa por Riyad Kalla,
- MongoDB: SOLO replicación maestro-esclavo
- CouchDB: Master-Master Replication
Una publicación en el blog (octubre de 2011) de alguien que probó ambos, A MongoDB Guy Learns CouchDB comentó que la búsqueda del CouchDB no es tan útil.
Una fecha de benchmark (junio de 2009) por Kristina Chodorow ( parte del equipo detrás de MongoDB ),
Yo iría por MongoDB.
Espero eso ayude.
Estoy seguro de que puedes con Mongo (más familiarizado con él), y bastante seguro de que puedes con el sofá también.
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 cuales usar: otras características que le interesan, la popularidad, etc.
Puedes probarlo, creo que deberías tener Mongo funcionando en 5 minutos.
Haga estas preguntas usted mismo? Y usted decidirá su selección de DB.
- ¿Necesitas maestro-maestro ? Entonces CouchDB. Principalmente, CouchDB admite la replicación maestro-maestro, lo que anticipa que los nodos se desconectarán durante largos períodos de tiempo. A MongoDB no le iría bien en ese entorno.
- ¿Necesita un rendimiento MAXIMO 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 mantiene un rendimiento insano? Entonces MongoDB.
- ¿Necesita una fuerte consistencia de los datos? Entonces MongoDB.
- ¿Necesita alta disponibilidad de base de datos? Entonces CouchDB.
- ¿Esperas múltiples bases de datos y múltiples tablas / colecciones? Entonces MongoDB
- ¿Tiene una aplicación móvil para usuarios sin conexión y desea sincronizar sus datos de actividad con un servidor? Entonces necesitas CouchDB.
- ¿Necesita gran variedad de motor de consulta ? Entonces MongoDB
- ¿Necesitas una gran comunidad para usar DB? Entonces MongoDB
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 con 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 (impresionante) de CouchDB para replicarse en dispositivos móviles y de escritorio, MongoDB tiene la ventaja de rendimiento, comunidad y herramientas en la actualidad.
Muy antigua pregunta pero está encima de Google y no me gustan las respuestas que veo, así que aquí está la mía.
Couchdb tiene mucho más que la capacidad de desarrollar CouchApps. La mayoría de la gente 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 lo hace (tiene que crear mapas / reducir vistas, lo que hace que algunas personas desactiven aunque creen estas vistas). es amigable con el desarrollo rápido 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 no significa que solo sea adecuado (o más adecuado) para lugares donde la versión es importante. Además, couchdb es fácil de escribir gracias a su naturaleza de solo apéndice (las operaciones de escritura se devuelven en un momento garantizando que nunca se perderán datos).
Una cosa muy importante que nadie menciona es el hecho de que CouchDb se basa en índices b-tree. Esto significa que si tiene 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 no debe pasarse por alto.
Para ser justos y exhaustivos, la ventaja que tiene MongoDb sobre CouchDb es el herramental y el marketing. Tienen herramientas ciudadanas de primera clase para todos los principales idiomas y plataformas, lo que facilita la integración y esto, sumado a sus consultas ad hoc, facilita aún más la transición de SQL.
CouchDb no tiene este nivel de herramientas, aunque hay muchas bibliotecas disponibles en la actualidad, pero CouchDb se expone como una API HTTP y, por lo tanto, es muy 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 quiere (principio de segregación de interfaz).
Así que yo 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 "solo se ajusta", para ciertas personas, pero si después de conocer las características de la base de datos (en la guía oficial exhaustiva) no tiene su momento "infierno sí", probablemente debería seguir adelante.
No me gustaría usar CouchDb si solo quieres 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 en que aborda los problemas para que realmente brille (y realmente funcione).
Pero una vez que has hecho eso 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 encontrado ninguna.
Resumo las respuestas encontradas en ese artículo:
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 a maestra y resolución de conflictos, almacenamiento de datos en JSON (legible para las personas, mejor acceso a través de los servicios REST), consulta a través de reducción de mapa.
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
Tenga en cuenta un problema con los í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 los índices únicos dispersos en Mongo es que los objetos en los que falta ese campo no están en absoluto en el índice; no se pueden recuperar mediante una consulta en ese campo: {$exists: false} simplemente no funciona.
La única solución que he encontrado es tener una familia de valores nula especial, donde un valor vacío se traduce a un prefijo especial (como null :) concatenado a un uuid. Este es un verdadero dolor de cabeza, porque uno tiene que cuidar de transformar a / desde los valores vacíos al escribir / leer / leer. Una gran molestia.
Nunca he usado la ejecución de javascript del lado del 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 la posibilidad de revisar CouchDB, tal vez se ajuste más a mi situación particular.
Por cierto, si alguien conoce el enlace al respectivo problema de Mongo que describe el problema del índice único disperso, por favor, comparta.