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

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 cercano a SQL, pero todavía está muy lejos. Confía en mí. Las consultas SQL son súper intuitivas, flexibles y poderoso. 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 de ida y vuelta al servidor para encontrar registros relacionados. Y luego empiezas a des-normalizar 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á (algunos piensan que tiene un mal rendimiento) clave externa restricciones para garantizar que sus datos sean consistentes. Le aseguro que esto eventualmente va a crear inconsistencias de datos en su base de datos. Prepárate. Lo más probable es que comience a escribir procesos o comprobaciones para mantener su base de datos consistente, lo que probablemente no funcionará mejor que dejar que los RDBMS lo hagan por usted.
5. Olvídate de frameworks maduros como hibernate.

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

Para almacenar estos datos no estructurados

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

Y la implementación de estas bases de datos son más simples que RDBMS regulares. Dado que estos son simples objetos binarios con valor de clave o estilo de documento serializados directamente en el disco. Estos almacenes de datos no hacer cumplir la propiedades ÁCIDO, y cualquier esquemas. Esto no proporciona ninguna habilidad transaction. Así que esto puede escalar a lo grande y podemos lograr un acceso más rápido (tanto de lectura como de escritura).

Pero en contraste, RDBM impone ACID y schemas en los datos. Si quieres trabajar con datos estructurados puedes seguir adelante con RDBM.

Me gustaría elija 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 está tratando con una gran cantidad de objetos JS (con anidamiento) y desea persistir estos objetos, entonces hay un argumento muy fuerte para usar Mongo. Hace que sus capas DAL y MVC sean ultra delgadas, porque no están deshaciendo todas las propiedades del objeto JS y tratando de forzarlas a encajarlas en una estructura (esquema) en la que no encajan naturalmente.

Tenemos un sistema que tiene varios objetos JS complejos en su corazón, y nos encanta Mongo porque podemos persistir 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 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, iría con MongoDB, más flexible para trabajar y sabes que puede escalar cuando lo necesites. (Aunque estoy sesgado - trabajo en el proyecto MongoDB)

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

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

Personalmente, creo que "nosql" se marchitará y morirá de fragmentación, ya que no hay estándares establecidos (casi por definición). Así que no voy a apostar personalmente en él para ningún proyecto a largo plazo.

Lo único que puede guardar "nosql" en mi libro, es si puede integrarse en Ruby o lenguajes similares sin problemas, y hacer que el lenguaje sea "persistente", casi sin ningún tipo de 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 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 comparando MongoDB con bases de datos RDBMS. MongoDB es uno de los populares dbs Nosql. Véase a continuación:

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

He visto que muchas empresas están usando MongoDB para análisis en tiempo real a partir de registros de aplicaciones. Su esquema libre realmente se adapta a los registros de aplicaciones, donde el esquema de registro tiende a cambiar de vez en cuando. Además, su característica Capped Collection es útil porque purga automáticamente los datos antiguos para mantener los datos en la memoria.

Esa es una área en la que realmente creo que MongoDB encaja, pero MySQL/PostgreSQL es más recomendable en general. Hay un montón de documentaciones y recursos del desarrollador en la web, así como su funcionalidad y robustez.

Las 2 razones principales por las que podrías preferir Mongo son

• Flexibilidad en el diseño de esquemas (almacén de documentos de tipo JSON).
• Escalabilidad - Solo suma 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' but pero fue el propio Monty quien, hace muchos años, explicó la "necesidad" de COMMIT / ROLLBACK, diciendo que 'todo lo que se hace en las clases de lógica (y no en la base de datos) de todos modos' so 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, usted puede elegir entre un montón de opciones, echar un vistazo a todas esas opciones: http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

Lo que sugiero es encontrar tu mejor combinación: MySQL + Memcache es realmente genial si necesitas ACID y quieres unirte a algunas tablas MongoDB + Redis es perfecto para almacenar documentos Neo4J es perfecto para graph database

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 !