¿Cuándo debemos usar MongoDB?

MongoDB es una base de datos NoSQL que he encontrado bastante fácil de usar. Recientemente tuve que desarrollar una aplicación simple que necesitaba recopilar algunos datos usando solicitudes HTTP y almacenar algunos resultados después de procesar los datos, e intenté usar MongoDB.

A partir de esta experiencia, encontré que era mucho más agradable de usar que las bases de datos relacionales tradicionales y, dado que soy desarrollador y no un DBA, mi trabajo se simplificó enormemente.

Aún así, a veces no estoy seguro de cuándo debería usar MongoDB en lugar de una base de datos relacional tradicional, como SQL Server o MySQL.

En ese caso, ¿cuándo podemos usar MongoDB en lugar de bases de datos relacionales? ¿Hay alguna advertencia realmente grande sobre MongoDB que lo hace inadecuado para algunas situaciones?

Básicamente:

• Si puede representar sus datos en forma de un grupo de documentos, MongoDB podría ser una buena opción.

• Si prefiere imaginar sus datos como un montón de tablas interconectadas, MongoDB puede no ser una buena opción.

Aquí hay dos ejemplos que encuentro ilustrativos:

• Hace unos años, creé un motor de blog. Su propósito es alojar artículos de blog y, para cada artículo, almacenar las diferentes versiones, algunos metadatos, estadísticas de visitas, etc.

  Esto podría almacenarse como un montón de tablas, pero cuando se trata de construir un modelo, crece muy rápido a una docena de tablas, si no más. Algunas consultas SQL podrían ponerse feas con muchos joins, y ... bueno, te haces una idea.

  El problema aquí es que hay una cosa central, un artículo de blog, y hay todo esto alrededor del artículo, lo que lo hace muy adecuado para una base de datos basada en documentos. Con MongoDB, modelar la base de datos fue extremadamente fácil: una colección contiene los artículos del blog, y una segunda colección pequeña contiene la lista de usuarios autorizados para escribir artículos. Cada documento dentro de la primera colección contendría toda la información que necesito al mostrar un artículo, ya sea el nombre del autor o las etiquetas.

• Ahora imagine un proyecto muy diferente. Hay algunos usuarios que pueden escribir cosas y compartir las cosas escritas por otros usuarios. En una página de un usuario, esperaría encontrar tanto las cosas que este usuario escribió como las que compartió. Hay una restricción: cuando alguien edita lo que escribió en el pasado, el cambio aparece en todas partes donde se compartió el texto original.

  Con un enfoque basado en documentos, es difícil encontrar cuál sería el documento. ¿Un usuario tal vez? Bueno, ese es un buen comienzo. Un documento de usuario contendría todas las cosas que escribió este usuario. ¿Pero qué hay de las cosas que compartió?

  Una forma posible es poner esas cosas en el mismo documento. El problema con este enfoque es que si alguien edita una entrada, la aplicación debe recorrer cada documento del usuario en la base de datos para editar cada aparición de la entrada anterior. Sin contar la duplicación de datos.

  Una alternativa sería mantener dentro del documento del usuario solo la lista de entradas que este usuario compartió (con la ID del usuario referido y la entrada). Pero ahora, ocurriría un problema diferente: si un usuario compartiera miles de entradas de miles de usuarios, requeriría abrir miles de documentos para obtener esas entradas.

  O podemos modelar nuestra colección en torno a las entradas mismas, cada entrada se refiere a su autor y tiene una lista de usuarios que la compartieron. Una vez más, los problemas de rendimiento pueden volverse notorios cuando necesite revisar todos los documentos para mostrar los publicados por un usuario determinado.

  Ahora, ¿cuántas tablas necesitarías si estuvieras usando una base de datos relacional? Correcto, tres. Sería sencillo modelar, y también sencillo de usar.

Cada tecnología tiene sus ventajas.

Las ventajas de las bases de datos relacionales es que el RDBMS hace algunas cosas por usted, como:

• Hacer cumplir la integridad referencial (no permitir la inserción de un detalle de factura si la factura a la que pertenece no existe)
• Evite la redundancia: las cosas se almacenan solo una vez.
• Las consultas complejas se pueden hacer con un lenguaje declarativo (SQL) maduro, probado en el tiempo y ampliamente difundido.

Todo eso se reduce al hecho de que tiene que escribir menos código porque el RDBMS hace cumplir las cosas por usted.

Además, la independencia de los datos: a menudo, si usa estructuras SQL estándar y no específicas del proveedor, puede migrar sus datos de un RDBMS a otro con una molestia mínima, mientras que las bases de datos NOSQL no están estandarizadas en absoluto.

Por otro lado, una de las ventajas de las bases de datos NOSQL es que escalan mejor manteniendo el rendimiento de millones de filas. Son más adecuados para el almacenamiento basado en documentos, es decir, datos no estructurados. Pero la mayoría de las aplicaciones no necesitan estas características.

Para su caso particular, MongoDB suena como una buena opción, pero hay muchos escenarios (probablemente la mayoría de ellos) donde no sería la mejor opción.

MongoDB es más adecuado en escenarios que requieren leer / escribir una gran cantidad de datos, sin mucho énfasis en la seguridad de las transacciones (si algunos datos se pierden ocasionalmente en un bloqueo del servidor, no es un gran problema), espere escalar en grande y no lo haga ' Realmente tengo un esquema estable.

MongoDB no es adecuado para escenarios que requieren:

1. Garantías sólidas de ACID: MongoDB permite almacenar datos duplicados, lecturas inconsistentes e incluso la pérdida de datos. Estas cosas están bien en algunas aplicaciones, pero no en la mayoría.
2. Transacciones de objetos múltiples: MongoDB admite transacciones ACID, pero solo para un único objeto / documento. Esto simplemente no será suficiente para operaciones más complejas como transferencias bancarias, hacer una reserva, etc.
3. BI tradicional: existen muchas herramientas de BI que solo funcionan bien con SQL tradicional.
4. SQL: MongoDB tiene un lenguaje de consulta muy específico, mientras que SQL es muy conocido por mucha gente (puede ser un aspecto importante a considerar), puede hacer muchas cosas complejas (mientras que con MongoDB tendría problemas para realizar un simple unirse) y es transferible a través de muchas implementaciones.

MongoDB es más rápido y le permitirá obtener un mayor rendimiento del sistema al eliminar muchas cosas que RDBMS aplica de forma predeterminada, como las comprobaciones de integridad (tenga en cuenta que de todos modos también puede ajustar RDBMS para tales fines), pero la verdad es que En la mayoría de los escenarios, simplemente no es necesario. Además, la compensación es fiabilidad y flexibilidad (tendrá problemas si, más adelante, decide que necesita realizar operaciones más complejas con los datos existentes).

Todo depende de las necesidades de la aplicación que está creando. ¿Es velocidad y disponibilidad, o seguridad, fiabilidad y flexibilidad? Debe saber en qué lugar de sus datos (y en las conexiones de sus datos) se encuentra más valor. Si aún no lo sabe, probablemente sea mejor si elige algo que no lo pintará en una esquina en el futuro, y le permitirá agregar las funciones y realizar las operaciones que su aplicación necesita.

MongoDB es excelente cuando puede representar sus datos como "paquetes" independientes de información. Tiene códigos postales de Google Maps, incrustado en el código postal son empresas y dentro de las empresas son empleados. Todos los códigos postales son independientes entre sí y puede obtener toda la información de una manera simple, bonita y rápida. Ese es un buen escenario para una solución no SQL.

Una vez dicho eso, estoy totalmente en desacuerdo con la tendencia actual que estoy buscando, lo que implica que MongoDB es una especie de solución posterior y superior a RDBMS y noSQL debe ser su solución por defecto. Todo eso es absurdo. MongoDB es una base de datos de nicho y el 90% de los proyectos son relacionales y necesitan una opción RDBMS porque desea una solución de consulta potente como SQL para generar sus informes y buscar datos dispersos: las "uniones" son un profesional, no una estafa. Además, los RDBMS modernos admiten colecciones BSON e integración geoespacial, por lo que quizás el nicho para noSQL sea aún más estrecho ahora.

MongoDB es útil para almacenar todos los datos estructurados necesarios para construir una instancia determinada de una página web. Puede recuperar los datos de una página determinada, pasarlos a su aplicación cliente que luego puede procesarlos.

En tal contexto, MongoDB es muy rápido y confiable. Pero nunca olvides que no tienes información relacional en tu base de datos. Lo que significa que si cambia algo en la estructura de su página web, es posible que no pueda llenar los huecos en sus páginas ya almacenadas porque no tiene los datos necesarios para hacerlo. Más sobre esto aquí: http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/