¿Cuándo usar MongoDB u otros sistemas de bases de datos orientados a documentos? [cerrado]


516

Ofrecemos una plataforma para videoclips y clips de audio, fotos y gráficos vectoriales. Comenzamos con MySQL como el backend de la base de datos y recientemente incluimos MongoDB para almacenar toda la metainformación de los archivos, porque MongoDB se ajusta mejor a los requisitos. Por ejemplo: las fotos pueden tener información Exif , los videos pueden tener pistas de audio donde también queremos almacenar la metainformación. Los videos y los gráficos vectoriales no comparten ninguna metainformación común, etc., así que sé que MongoDB es perfecto para almacenar estos datos no estructurados y mantenerlos disponibles para búsquedas.

Sin embargo, continuamos desarrollando nuestra plataforma y agregando características. Ahora, uno de los próximos pasos será proporcionar un foro para nuestros usuarios. La pregunta que surge ahora es: ¿usar la base de datos MySQL, que sería una buena opción para almacenar foros y publicaciones en foros, etc. o también usar MongoDB para esto?

Entonces la pregunta es: cuándo usar MongoDB y cuándo usar un RDBMS. ¿Qué tomaría, mongoDB o MySQL, si tuviera la opción y por qué la tomaría?


12
No estoy seguro de por qué esto está marcado como basado en opiniones cuando claramente no lo está. Hay una clara respuesta correcta o incorrecta aquí.
Spencer

Respuestas:


659

En NoSQL: si solo fuera así de fácil , el autor escribe sobre MongoDB:

MongoDB no es una tienda de clave / valor, es bastante más. Definitivamente tampoco es un RDBMS. No he usado MongoDB en producción, pero lo he usado un poco para crear una aplicación de prueba y es un kit muy bueno. Parece ser muy eficaz y tiene, o tendrá pronto, tolerancia a fallas y auto-fragmentación (también conocido como escala). Creo que Mongo podría ser lo más parecido a un reemplazo de RDBMS que he visto hasta ahora. No funcionará para todos los conjuntos de datos y patrones de acceso, pero está diseñado para su material CRUD típico. Almacenar lo que es esencialmente un gran hash, y poder seleccionar cualquiera de esas claves, es para lo que la mayoría de las personas usa una base de datos relacional.Si su DB es 3NF y no hace ninguna unión (solo está seleccionando un montón de tablas y colocando todos los objetos juntos, también conocido como lo que la mayoría de la gente hace en una aplicación web), MongoDB probablemente lo pateará por usted.

Luego, en la conclusión:

Lo real a señalar es que si no puedes hacer algo súper increíble porque no puedes elegir una base de datos, lo estás haciendo mal. Si conoce mysql, simplemente utilícelo. Optimice cuando realmente lo necesite. Úselo como una tienda ak / v, úselo como un rdbms, pero por el amor de Dios, ¡cree su aplicación asesina! Nada de esto importará para la mayoría de las aplicaciones. Facebook todavía usa MySQL, mucho. Wikipedia usa MySQL, mucho. FriendFeed usa MySQL, mucho. NoSQL es una gran herramienta, pero ciertamente no será su ventaja competitiva, no hará que su aplicación sea atractiva y, sobre todo, a sus usuarios no les importará nada de esto.

¿En qué voy a construir mi próxima aplicación? Probablemente Postgres. ¿Usaré NoSQL? Tal vez. También podría usar Hadoop y Hive. Podría guardar todo en archivos planos. Quizás empiece a hackear a Maglev. Usaré lo que sea mejor para el trabajo. Si necesito informes, no usaré ningún NoSQL. Si necesito almacenamiento en caché, probablemente usaré Tokyo Tyrant. Si necesito ACIDity, no usaré NoSQL. Si necesito un montón de contadores, usaré Redis. Si necesito transacciones, usaré Postgres. Si tengo una tonelada de un solo tipo de documentos, probablemente usaré Mongo. Si necesito escribir mil millones de objetos al día, probablemente usaría Voldemort. Si necesito una búsqueda de texto completo, probablemente usaría Solr. Si necesito una búsqueda de texto completo de datos volátiles, probablemente usaría Sphinx.

Me gusta este artículo, lo encuentro muy informativo, da una buena visión general del panorama NoSQL y el bombo publicitario. Pero, y esa es la parte más importante, realmente ayuda hacerse las preguntas correctas cuando se trata de elegir entre RDBMS y NoSQL. Vale la pena leer en mi humilde opinión.

Enlace alternativo al artículo


44
gracias, de hecho es un artículo muy interesante.
aurora


48
@iddqd ROFL! Hombre, esto fue muy gracioso. "Si eres lo suficientemente estúpido como para ignorar totalmente la fiabilidad solo para obtener puntos de referencia, te sugiero que canalices tus datos /dev/null, será muy rápido" : D
Pascal Thivent

3
Gracias por la respuesta exagerada.
Deamon

2
Esperemos que BJ Clark no elija usar todas esas tecnologías en el mismo proyecto. Eso sería una pequeña curva de aprendizaje.
Adam Monsen

186

Después de dos años usando MongoDb para una aplicación social, he sido testigo de lo que realmente significa vivir sin un RDBMS de SQL.

  1. Terminas escribiendo trabajos para hacer cosas como unir datos de diferentes tablas / colecciones, algo que un RDBMS haría por ti automáticamente.
  2. Sus capacidades de consulta con NoSQL están drásticamente paralizadas. MongoDb puede ser lo más parecido a SQL, pero aún está muy lejos. Créeme. Las consultas SQL son súper intuitivas, flexibles y potentes. Las consultas de MongoDb no lo son.
  3. Las consultas de MongoDb pueden recuperar datos de una sola colección y aprovechar un solo índice. Y MongoDb es probablemente una de las bases de datos NoSQL más flexibles. En muchos escenarios, esto significa más viajes de ida y vuelta al servidor para buscar registros relacionados. Y luego comienza a desnormalizar los datos, lo que significa trabajos en segundo plano.
  4. El hecho de que no sea una base de datos relacional significa que no tendrá restricciones de clave externa (que algunos piensan que tienen un mal desempeño) para garantizar que sus datos sean consistentes. Le aseguro que esto eventualmente creará inconsistencias de datos en su base de datos. Estar preparado. Lo más probable es que comience a escribir procesos o comprobaciones para mantener su base de datos coherente, lo que probablemente no funcionará mejor que dejar que el RDBMS lo haga por usted.
  5. Olvídate de frameworks maduros como hibernate.

Creo que el 98% de todos los proyectos probablemente sean mucho mejores con un RDBMS SQL típico que con NoSQL.


10
pensamientos interesantes ...
luigi7up

3
Por otro lado, las capacidades de consulta y las uniones que describa no deberían ser un problema: si usa MongoDB, entonces todavía tiene que hacer un trabajo para diseñar sus colecciones y qué datos ingresará para que no necesite complejos Se une y así sucesivamente. De todos modos, las bases de datos no son un cuello de botella y existen soluciones alternativas como Memcache para algunos casos de uso. Sin embargo, si comienza desde cero, es posible que diseñar y usar MongoDB sea más simple y rápido (como desarrollador que trabaja con código de objeto, no necesito un ORM). Seguro que tiene que escribir unas cuantas secuencias de comandos, pero en realidad no es tan difícil y reutilizar código
Aki

1
La mayoría de las personas no usarán las bases de datos NoSQL para el caso de uso específico para el que fueron creadas, reinventando tantas ruedas después. El debate NoSQL vs. SQL muestra que muchas personas experimentan el uso de NoSQL como si estuvieran retrocediendo 20-30 años en el tiempo, a tiempos previos a Codd, pre-relacionales y pre-SQL . O, como dice Michael Stonebraker: "Lo que pasa viene alrededor"
Lukas Eder

1
¿El ítem n. ° 3 "y aprovechar un solo índice" sigue siendo válido hoy? Ahora estoy entrando en MongoDB y parece que, según lo que he leído / visto hasta ahora, ¿puede admitir múltiples índices?
Jeach

1
@Jeach: No, el # 3 ya no es cierto. MongoDB 2.6 introdujo la intersección del índice .
Rob Garrison

26

para almacenar estos datos no estructurados

Como dijiste, MongoDB es el más adecuado para almacenar datos no estructurados. Y esto puede organizar sus datos en formato de documento. Estas altenativas RDBMS llamadas almacenes de datos NoSQL ( MongoDB , CouchDB , Voldemort ) son muy útiles para aplicaciones que se escalan masivamente y requieren un acceso a datos más rápido desde estos grandes almacenes de datos.

Y la implementación de estas bases de datos es más simple que el RDBMS normal. Dado que estos son objetos binarios simples con valor de clave o estilo de documento directamente serializados en el disco. Estos almacenes de datos no imponen las propiedades ACID ni ningún esquema . Esto no proporciona ninguna capacidad de transacción . Entonces, esto puede escalar en grande y podemos lograr un acceso más rápido (tanto de lectura como de escritura).

Pero, en contraste, RDBM aplica ACID y esquemas en los datos. Si desea trabajar con datos estructurados, puede continuar con RDBM.

Elegiría MySQL para crear foros para este tipo de cosas. Porque esto no va a escalar en grande. Y esta es una aplicación muy simple (común) que tiene relaciones estructuradas entre los datos.


10
"Elegiría mysql para crear foros de ese tipo de cosas". De Verdad? Creo que cosas como los foros serían mucho más fáciles de escribir utilizando una base de datos orientada a documentos que una relacional (si la escribiera desde cero). Si no necesita específicamente las características de un RDBMS, diría que vaya con MongoDB o una base de datos similar para facilitar su uso y escalado.
Sasha Chedygov el

2
CouchDB tiene soporte ACID. couchdb.apache.org/docs/overview.html
Sonia

2018: MongoDB también tiene soporte ACID
Nepoxx

10

Tenga en cuenta que Mongo esencialmente almacena JSON. Si su aplicación maneja muchos objetos JS (con anidamiento) y desea persistir en estos objetos, entonces hay un argumento muy fuerte para usar Mongo. Hace que sus capas DAL y MVC sean extremadamente delgadas, ya que no están desempaquetando todas las propiedades de los objetos JS e intentan ajustarlas a la fuerza en una estructura (esquema) en la que no encajan naturalmente.

Tenemos un sistema que tiene varios objetos JS complejos en su corazón, y amamos a Mongo porque podemos persistir en todo, muy fácilmente. Nuestros objetos también son bastante amorfos y desestructurados, y Mongo absorbe esa complicación sin pestañear. Tenemos una capa de informes personalizada que descifra los datos amorfos para el consumo humano, y eso no fue tan difícil de desarrollar.


7

Yo diría que use un RDBMS si necesita transacciones complejas. De lo contrario, optaría por MongoDB, más flexible para trabajar y usted sabe que puede escalar cuando lo necesite. (Aunque soy parcial, trabajo en el proyecto MongoDB)


77
Las transacciones complejas no funcionan en MongoDB, pero funcionan en otras bases de datos NoSQL, como MarkLogic (también soy parcial ya que ejecuto la comunidad de desarrolladores de MarkLogic).
Eric Bloch

Gracias por la pista a MarkLogic, no lo sabía.
aurora el

Me gustaría saber de mdirolf sobre eso. ¿Por qué MongoDB decidió no implementar transacciones?
Aki

7

¿Quién necesita foros distribuidos y fragmentados? Tal vez Facebook, pero a menos que esté creando un competidor de Facebook, solo use Mysql, Postgres o lo que le resulte más cómodo. Si quieres probar MongoDB, está bien, pero no esperes que haga magia por ti. Tendrá sus peculiaridades y su maldad general, como todo lo demás, como estoy seguro de que ya has descubierto si realmente has estado trabajando en eso.

Claro, MongoDB puede exagerarse y parecer fácil en la superficie, pero se encontrará con problemas que los productos más maduros ya han superado. No se deje engañar tan fácilmente, sino que espere hasta que "nosql" madure o muera.

Personalmente, creo que "nosql" se marchitará y morirá por fragmentación, ya que no hay estándares establecidos (casi por definición). Por lo tanto, no apostaré personalmente por ningún proyecto a largo plazo.

Lo único que puede guardar "nosql" en mi libro es si puede integrarse sin problemas en Ruby o en lenguajes similares, y hacer que el lenguaje sea "persistente", casi sin sobrecarga en la codificación y el diseño. Eso puede suceder, pero esperaré hasta entonces, no ahora, y tiene que ser más maduro, por supuesto.

Por cierto, ¿por qué estás creando un foro desde cero? Hay toneladas de foros de código abierto que se pueden ajustar para adaptarse a la mayoría de los requisitos, a menos que realmente esté creando The Next Generation of Forums (que dudo).


55
gracias por tu respuesta. integrar un foro es un desastre: ya lo hemos hecho y decidimos no volver a hacerlo: no necesitamos miles de funciones, sino una integración total en nuestro software.
aurora

4

He visto que muchas compañías están usando MongoDB para análisis en tiempo real desde registros de aplicaciones. Su ausencia de esquemas realmente se ajusta a los registros de aplicaciones, donde el esquema de registros tiende a cambiar de vez en cuando. Además, su función Capped Collection es útil porque purga automáticamente los datos antiguos para mantener los datos en la memoria.

Esa es un área en la que realmente creo que MongoDB se ajusta, pero MySQL / PostgreSQL es más recomendable en general. Hay muchas documentaciones y recursos para desarrolladores en la web, así como su funcionalidad y solidez.


4

Las 2 razones principales por las que quizás prefieras Mongo son

  • Flexibilidad en el diseño de esquemas (almacén de documentos tipo JSON).
  • Escalabilidad: simplemente agregue nodos y puede escalar horizontalmente bastante bien.

Es adecuado para aplicaciones de big data. RDBMS no es bueno para big data.


3

Ya sabes, todo esto sobre las uniones y las 'transacciones complejas', pero fue el propio Monty quien, hace muchos años, explicó la "necesidad" de COMMIT / ROLLBACK, diciendo que "todo eso se hace en las clases de lógica". (y no la base de datos) de todos modos ', así que es lo mismo de nuevo. Lo que se necesita es un motor de almacenamiento / recuperación de datos tonto pero increíblemente ordenado y rápido, para el 99% de lo que hacen las aplicaciones web.


Gracias, estás planteando un punto interesante aquí. Realmente me interesaría la explicación de Monty, porque no estoy seguro de cuán complejas son las reversiones de actualizaciones en múltiples tablas en lógica de aplicación pura. No estoy seguro, si esto es realmente posible.
aurora el

Tampoco estoy seguro de la "mejor" manera. Siempre hemos seguido todo lo que se ha hecho en la base de datos, y luego lo permitimos o lo deshacemos a nivel de aplicación, en código. Nunca nos hemos basado en transacciones, en ningún lugar, nunca. Los documentos de Mongo sugieren usar metadatos para rastrear qué partes de la transacción retrotraíble se han producido, en qué estado se encuentra la transacción, en caso de que se rompa y deba revertirse. Lo curioso es que ya lo habíamos estado haciendo junto con MySQL y otros. No es mucho más trabajo y mantiene el foco en lo que está sucediendo, cuándo, dónde y por qué, en lugar de enmarcarlo en negro.
FYA

Hay una nota sobre esto en el sitio web de 10gen en alguna parte ... que menciona cómo los campos 'enclavamiento' o 'trinquetes' se usan manualmente para indicar el estado de un proceso de varios pasos. Me parece que si te acercas al motor MySQL, la "transacción de bloque" todavía se expande a una serie de pasos, sin importar qué; es solo que los enclavamientos o trinquetes se realizan de una manera mucho más pequeña y rápida que el seguimiento manual en los campos de la base de datos.
FYA

Todavía no hemos encontrado una buena manera de limitar el demonio MongoDB: engulle casi toda la RAM disponible para su índice y almacenamiento de datos en la memoria, aunque produce memoria rápidamente cuando otros proc. La necesitan. Aún así, sería bueno tener un 'use_max_memory' u otros límites fácilmente definibles para asegurarse de que MongoDB no se escape y envíe el servidor a intercambio de palabras (lo hemos visto varias veces, incluso en la versión más reciente). Al menos MySQL acepta todo tipo de límites definibles y sugerencias de operación.
FYA

No directamente relacionado, pero más o menos: estábamos usando memcached pero abandonamos debido al fiasco del controlador PHP Memcache / Memcached aún sin resolver. Utilizamos MongoDB como una clave rápida y temporal: val store (¡por lo que funcionó muy bien!) Hasta descubrir lo rápido y fácil que es apc_store (). Si descubrimos que APC se está llenando con errores temporales (en comparación con PHP precompilado almacenado) que solíamos almacenar en Memcached, volveremos a MongoDB para obtener el almacenamiento clave: val.
FYA

1

Como se dijo anteriormente, puede elegir entre muchas opciones, eche un vistazo a todas esas opciones: http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

Lo que sugiero es que encuentre su mejor combinación: MySQL + Memcache es realmente genial si necesita ACID y desea unirse a algunas tablas. MongoDB + Redis es perfecto para almacenar documentos. Neo4J es perfecto para la base de datos de gráficos.

Lo que hago: empiezo con MySQl + Memcache porque estoy acostumbrado, luego empiezo a usar el marco de la base de datos de otros. ¡En un solo proyecto, puede combinar MySQL y MongoDB, por ejemplo!


MySQL + memcached le dará coherencia eventual. Que no considero ACID en un contexto RDMB.
R. van Twisk
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.