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

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?

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

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.

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.

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.

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)

¿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).

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.

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.

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.

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!