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

Ofrecemos una plataforma para videos y clips de audio, fotos y gráficos vectoriales. Comenzamos con MySQL como back-end de 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 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 la búsqueda.

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 el foro, etc. o usar MongoDB para esto también?

Entonces la pregunta es: cuándo usar MongoDB y cuándo usar un RDBMS. ¿Qué tomarías, mongoDB o MySQL, si pudieras elegir y por qué lo tomarías?

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

MongoDB no es una tienda 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 construir una aplicación de prueba y es una pieza genial. Parece ser muy eficiente y tiene, o tendrá pronto, tolerancia a fallas y fragmentación automática (también se escalará). 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 las cosas típicas de CRUD. Almacenar lo que es esencialmente un gran hash, y poder seleccionar cualquiera de esas teclas, es para lo que la mayoría de las personas usa una base de datos relacional. Si tu DB es 3NF y no haces ningún join (solo estás seleccionando un montón de tablas y juntando todos los objetos, también conocido como la mayoría de las personas en una aplicación web), MongoDB probablemente te patearía el culo.

Entonces, en la conclusión:

Lo que hay que señalar es que si no puedes hacer algo realmente increíble porque no puedes elegir una base de datos, lo estás haciendo mal. Si conoce mysql, simplemente úselo. Optimizar cuando realmente lo necesite. Úselo como una tienda de ak / v, úselo como un rdbms, ¡pero por el amor de Dios, construya su aplicación asesina! Nada de esto importará en 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 se caliente 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 mantener todo en archivos planos. Quizás empiece a piratear a Maglev. Usaré lo que sea mejor para el trabajo. Si necesito informes, no usaré ningún NoSQL. Si necesito almacenamiento en caché, probablemente use Tokyo Tyrant. Si necesito ACIDity, no usaré NoSQL. Si necesito una tonelada 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 por 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, me parece muy informativo, ofrece una buena visión general del paisaje NoSQL y la exageración. 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 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 rezagado. 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 solo un í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 encontrar registros relacionados. Y luego comienzas a desnormalizar los datos, lo que significa trabajos en segundo plano.
  4. El hecho de que no se trate de una base de datos relacional significa que no tendrá (cree que algunos tienen un mal rendimiento) restricciones de clave externa para garantizar que sus datos sean coherentes. Te aseguro que esto eventualmente creará inconsistencias de datos en tu base de datos. Estar preparado. Lo más probable es que empiece a escribir procesos o comprobaciones para mantener la coherencia de su base de datos, que probablemente no tendrá un rendimiento mejor que dejar que el RDBMS lo haga por usted.
  5. Olvídate de marcos 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 esta información no estructurada

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 escalan de forma masiva y requieren un acceso de datos más rápido desde estas grandes tiendas de datos.

Y la implementación de estas bases de datos es más simple que el RDBMS regular. Dado que se trata de objetos binarios simples de valor clave o estilo de documento directamente serializados en el disco. Estos almacenes de datos no hacen cumplir las propiedades de ACID ni ningún esquema . Esto no proporciona ninguna capacidad de transacción . Así que esto puede escalar a gran escala y podemos lograr un acceso más rápido (tanto de lectura como de escritura).

Pero, por el contrario, RDBM impone ACID y esquemas en los datos. Si desea trabajar con datos estructurados, puede continuar con RDBM.

Escogería MySQL para crear foros para este tipo de cosas. Porque esto no va a escalar a lo 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 trata con muchos Objetos JS (con anidamiento) y desea conservar estos objetos, existe un argumento muy fuerte para usar Mongo. Hace que sus capas DAL y MVC sean muy delgadas, porque no están desempaquetando todas las propiedades del objeto JS e intentando forzarlas en una estructura (esquema) en la que no encajan de forma natural.

Tenemos un sistema que tiene varios objetos JS complejos en su corazón, y amamos a Mongo porque podemos persistir en todo muy, muy fácilmente. Nuestros objetos también son bastante amorfos y desestructurados, y Mongo absorbe esa complicación sin parpadear. Tenemos una capa de informes personalizados 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, iría con MongoDB: más flexible para trabajar y sabes que puede escalar cuando lo necesites. (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, simplemente use Mysql, Postgres o lo que sea 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 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 ser publicitado y parecer fácil en la superficie, pero te encontrarás con problemas que ya han superado los productos más maduros. No te dejes atrapar tan fácilmente, sino más bien espera hasta que “nosql” madure o muera.

Personalmente, creo que “nosql” se marchitará y morirá a causa de la fragmentación, ya que no existen estándares establecidos (casi por definición). Por lo tanto, no apostaría personalmente por ningún proyecto a largo plazo.

Lo único que puede salvar a “nosql” en mi libro es si puede integrarse sin problemas en Ruby o en idiomas similares, y hacer que el lenguaje sea “persistente”, casi sin gastos adicionales en encoding y 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 muchos foros de código abierto que pueden ajustarse para ajustarse a la mayoría de los requisitos, a menos que realmente esté creando La próxima generación de foros (lo cual dudo).

Después de asistir a Devoxx 2011 y asistir a una presentación de 10Gen, he escrito un pequeño blog que compara las bases de datos de MongoDB con RDBMS. MongoDB es uno de los dbs populares de Nosql. Por favor ver más abajo:

http://blog.iprofs.nl/2011/11/25/is-mongodb-a-good-alternative-to-rdbms-databases-like-oracle-and-mysql/

He visto en muchas empresas que están usando MongoDB para analizar en tiempo real desde los registros de las aplicaciones. Su esquema libre realmente se adapta a los registros de la aplicación, donde el esquema de registro tiende a cambiar de vez en cuando. Además, su característica de colección limitada es útil porque purga automáticamente datos viejos para mantener los datos viejos 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 una gran cantidad de documentación y recursos de desarrolladores en la web, así como también su funcionalidad y robustez.

Los 2 motivos principales por los que quizás prefieras preferir a Mongo son

  • Flexibilidad en el diseño de esquema (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 COMPROMISO / ROLLBACK, diciendo que “todo lo que se hace en las clases de lógica” (y no la base de datos) de todos modos ‘, así que es lo mismo una vez más. 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 encontrar su mejor combinación: MySQL + Memcache es realmente genial si necesita ACID y desea unir algunas tablas MongoDB + Redis es perfecto para la tienda de documentos Neo4J es perfecto para la base de datos de gráficos

Lo que hago: empiezo con MySQl + Memcache porque estoy acostumbrado a hacerlo, luego empiezo a usar otros framework de bases de datos. ¡En un solo proyecto, puedes combinar MySQL y MongoDB por ejemplo!