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.
mongodb
performance
comparison
couchdb
nosql
Lucas101
fuente
fuente
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, la guía visual de sistemas NoSQL
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,
Una comparación reciente (febrero de 2012) y más completa de Riyad Kalla,
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.
fuente
Las respuestas sobre todo complican la historia.
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.
fuente
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.
fuente
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.Haga estas preguntas usted mismo? Y usted decidirá su selección de base de datos.
fuente
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
fuente
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.
fuente
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.
fuente