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

Question

Ofrecemos una plataforma para clips de video y audio, fotos y grafics 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 Exif La información, los videos pueden tener pistas de audio en las que también queremos almacenar la metainformación. Los videos y los gráficos vectoriales no comparten ninguna metainformación común, etc. Por lo tanto, sé que MongoDB es perfecto para almacenar estos datos no estructurados y mantenerlo en busca de búsqueda.

Sin embargo, continuamos desarrollando nuestra plataforma y agregando características. Ahora uno de los próximos pasos proporcionará un foro para nuestros usuarios. La pregunta que ahora surge es: usar la base de datos MySQL, ¿que sería una buena opción para almacenar foros y postales, 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 tuvieras la opción y por qué lo tomarías?

Answer 1

En Nosql: si tan solo fuera tan 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 construyendo una aplicación de prueba y es una pieza de kit muy genial. Parece ser muy desempeñado y lo ha hecho, o tendrá pronto, tolerancia a fallas y retraso automático (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á creado para sus cosas típicas de Crud. Almacenar lo que es esencialmente un hash enorme, y poder seleccionar en cualquiera de esas claves, es para lo que la mayoría de las personas usan 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 juntando todos los objetos, también conocido como lo que la mayoría de las personas hacen en una aplicación web), MongoDB probablemente le patearía el culo.

Entonces, en la conclusión:

Lo real de señalar es que si se le impide hacer algo súper increíble porque no puede elegir una base de datos, lo está haciendo mal. Si conoces MySQL, solo úsalo. Optimice cuando realmente lo necesite. Úselo como la tienda AK/V, úsela como un RDBMS, pero por el bien de Dios, ¡construya su aplicación asesina! Nada de esto será importante 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 va a calentar su aplicación 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? Quizás. También podría usar Hadoop y Hive. Podría mantener todo en archivos planos. Quizás comience a piratear Maglev. Usaré lo que sea mejor para el trabajo. Si necesito informar, no usaré ningún NoSQL. Si necesito almacenamiento en caché, probablemente usaré Tokyo Tyrant. Si necesito acidez, no usaré NoSQL. Si necesito un montón de contadores, usaré Redis. Si necesito transacciones, usaré Postgres. Si tengo un montón 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, me parece muy informativo, ofrece una buena visión general del paisaje y el bombo de NoSQL. Pero, y esa es la parte más importante, realmente ayuda a 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

Answer 2

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

1. Termina escribiendo trabajos para hacer cosas como unir datos de diferentes tablas/colecciones, algo que un RDBMS haría por usted automáticamente.
2. Sus capacidades de consulta con NoSQL están drásticamente paralizadas. MongoDB puede ser lo más cercano a SQL, pero todavía está muy lejos. Confía en mí. Las consultas SQL son súper intuitivas, flexibles y poderosas. Las consultas MongoDB no lo son.
3. Las consultas 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 redondos al servidor para encontrar registros relacionados. Y luego comienza a desasormalizar datos, lo que significa trabajos de fondo.
4. El hecho de que no sea una base de datos relacional significa que no tendrá limitaciones de clave extranjera (pensamiento por parte de 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 cheques para mantener su base de datos consistente, lo que probablemente no funcionará mejor que dejar que los RDBM lo hagan por usted.
5. Olvídate de marcos maduros como Hibernate.

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

Answer 3

Para almacenar estos datos no estructurados

Como dijo, MongoDB es mejor adecuado para almacenar datos no estructurados. Y esto puede organizar sus datos en formato de documento. Estos altenadores de RDBMS llamaron Coso almacenes de datos (Mongodb, Couchdb, Voldemort) son muy útiles para aplicaciones que escalan enormemente y requieren un acceso de datos más rápido desde estas tiendas Big Data.

Y la implementación de estas bases de datos es más simple que la RDBMS regular. Dado que estos son objetos binarios de estilo clave simples o de documento de estilo de documento directamente serializados en el disco. Estas tiendas de datos no hacen cumplir el Propiedades ácidas, y cualquier esquema. Esto no proporciona ninguna transacción habilidades. Por lo tanto, esto puede escalar en grande y podemos lograr un acceso más rápido (tanto leer y escribir).

Pero en contraste, RDBM hace cumplir el ácido y los esquemas en los datos. Si desea trabajar con datos estructurados, puede continuar con RDBM.

yo 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.

Answer 4

Tenga en cuenta que Mongo esencialmente almacena JSON. Si su aplicación está lidiando con muchos objetos JS (con anidación) y desea persistir estos objetos, entonces hay un argumento muy fuerte para usar Mongo. Hace que sus capas DAL y MVC sean muy finas, porque no están empaquetando todas las propiedades del objeto JS y tratando de forzarlas 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 todo muy, muy fácilmente. Nuestros objetos también son bastante amorfos y no estructurados, y Mongo absorbe esa complicación sin parpadear. Tenemos una capa de informes personalizadas que descifra los datos amorfos para el consumo humano, y eso no fue tan difícil de desarrollar.

Answer 5

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

Answer 6

¿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 sea más cómodo. Si quieres probar MongoDB, ok, pero no esperes que te haga magia. Tendrá sus peculiaridades y su maldad general, así como todo lo demás, como estoy seguro de que ya ha descubierto si realmente ya ha estado trabajando en ello.

Claro, MongoDB puede ser exagerado y parecer fácil en la superficie, pero tendrá problemas que los productos más maduros ya han superado. No se deje atraer 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 a ningún proyecto a largo plazo.

Lo único que puede guardar "nosql" en mi libro es si puede integrarse en idiomas rubí o similares sin problemas, y hacer que el idioma sea "persistente", casi sin ninguna sobrecarga en la codificación y el diseño. Eso puede pasar, pero esperaré hasta entonces, no ahora, y debe 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 que se ajusten a la mayoría de los requisitos, a menos que realmente esté creando la próxima generación de foros (que dudo).

Answer 7

He visto en muchas compañías utilizando MongoDB para análisis en tiempo real de los registros de aplicaciones. Su flujo de esquema realmente se ajusta a los registros de aplicaciones, donde el esquema de registros tiende a cambiar de vez en el tiempo. Además, es Colección limitada La característica es útil porque purga automáticamente los datos antiguos para mantener los datos ajustados en la memoria.

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

Answer 8

La razón principal por la que es posible que prefiera Mongo sea

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

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

Answer 9

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

Answer 10

Como dicho anteriormente, puede elegir entre muchas opciones, echar 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 excelente si necesita ácido y desea unirse a 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, luego empiezo a usar otros marco de base de datos. ¡En un solo proyecto, puede combinar MySQL y MongoDB, por ejemplo!