¿Cuándo alguien usaría MongoDB (o similar) sobre un DBMS relacional?

Estoy un poco confundido acerca de todo el asunto NoSQL y tal. ¿Cuándo elegirías usar algo como MongoDB sobre algo como Oracle o MySQL? Realmente no entiendo la "diferencia" en lo que respecta al uso entre ellos.

Según tengo entendido, las bases de datos de tipo NoSQL no están destinadas a reemplazar RDBMS, pero ¿qué es exactamente lo que deben hacer?

He usado CouchDB antes para tres proyectos de mascotas.

• Un sistema de micro blogging.
• Para guardar información para una pequeña aplicación de toma de notas que hice.
• Una aplicación de lluvia de ideas de uso general.

La razón principal por la que elegí esto sobre algo como MSSQL o MySQL es la flexibilidad que obtienes al usarlo. Sin esquema rígido. Si dentro de tres meses necesita una determinada tabla para tener un campo adicional, y esto y aquello, simplemente cámbielo y se ondula de allí en adelante.

Solía partir CouchDB por Apress para aprender a usarlo.

Por ejemplo, CouchDB usa json para comunicarse con / desde la base de datos. Si su idioma puede enviar datos, puede usarlos para comunicarse con la base de datos.

Lea también: ¿Por qué debería usar una base de datos basada en documentos en lugar de una base de datos relacional? en StackOverflow

Lamento agregar otra respuesta, pero ninguna de las respuestas aquí es muy satisfactoria. Esta respuesta es específica de MongoDB (a diferencia de la gran variedad de otras opciones de almacenamiento de datos que no son bases de datos relacionales).

Pros:

• MongoDB tiene una latencia más baja por consulta y gasta menos tiempo de CPU por consulta porque está haciendo mucho menos trabajo (por ejemplo, sin uniones, transacciones). Como resultado, puede manejar una carga mayor en términos de consultas por segundo y, por lo tanto, se usa a menudo si tiene un número masivo de usuarios.
• MongoDB es más fácil de fragmentar (usar en un clúster) porque no tiene que preocuparse por las transacciones y la coherencia.
• MongoDB tiene una velocidad de escritura más rápida porque no tiene que preocuparse por transacciones o reversiones (y, por lo tanto, no tiene que preocuparse por el bloqueo).
• MongoDB no tiene un esquema en caso de que tenga un caso de uso especial que pueda aprovecharlo.

Contras:

• MongoDB no admite transacciones . Así es como obtiene la mayoría de sus beneficios.
• En general, MongoDB crea más trabajo (por ejemplo, más costo de CPU) para el servidor del cliente . Por ejemplo, para unir datos uno tiene que emitir múltiples consultas y unir en el cliente.
• Incluso aquí en 2017 hay menos soporte de herramientas para MongoDB que para las bases de datos relacionales simplemente porque es más nuevo. También hay menos expertos en MongoDB que sus contrapartes relacionales.

Puntos a menudo mal entendidos:

• Tanto MongoDB como las bases de datos relacionales admiten la indexación. Su rendimiento de consulta es similar en términos de ejecución de consultas grandes .
• MongoDB no elimina la necesidad de migraciones o más específicamente, actualizando sus datos existentes a medida que su esquema evoluciona. Por ejemplo: si tiene una aplicación que se basa en una tabla de usuarios para contener ciertos datos, y modifica esa tabla para que contenga datos diferentes (supongamos que agrega un campo de imagen de perfil), aún necesitará:
  • Escriba su aplicación para manejar objetos para los que esta propiedad no está definida O
  • Escriba una migración única para poner un valor predeterminado para esta propiedad O
  • Escriba código para proporcionar un valor predeterminado en el momento de la consulta si este campo no está presente O
  • Manejar el campo faltante de alguna otra manera

Para robar descaradamente de Renesis (en realidad estoy haciendo esta respuesta CW):

Usando RDBMS en lugar de otros tipos:

• Lea sobre la idea de "NoSQL" y otros tipos de bases de datos:
  • NoSQL: si solo fuera así de fácil
  • (arriba está vinculado desde) ¿ Cuándo usar MongoDB u otros sistemas de bases de datos orientados a documentos? ^{actualmente eliminado en SO} ( más )
  • https://softwareengineering.stackexchange.com/questions/5354/are-nosql-databases-going-to-take-the-place-of-relational-databases-is-sql-going
  • Cuándo usar CouchDB vs RDBMS
• Los RDBMS hacen un uso intensivo de la indexación para el rendimiento. En bases de datos muy grandes, esto puede tener un efecto adverso en el rendimiento o incluso reducir el número óptimo de filas por DB / Shard que requiere más hardware
• No es lo ideal si está almacenando una gran cantidad de datos pero leyendo con menos frecuencia
• Si no tiene muchas relaciones extranjeras, las bases de datos relacionales podrían no ser ideales (almacenamiento de documentos)

Cuando sus datos no son relacionales, puede haber grandes beneficios al usar bases de datos NoSQL como el rendimiento y la escalabilidad (dependiendo de las circunstancias, por supuesto). Algunos patrones de diseño como CQRS hacen que sea mucho más fácil aprovechar los datos no relacionales en áreas que convencionalmente exigirían el uso exclusivo de una base de datos SQL.

Es común usar bases de datos como mongo para datos en caché. Por ejemplo, si necesita generar un informe, puede hacer una consulta SQL complicada que une y agrega un montón de datos sobre la marcha, o simplemente puede obtener un solo documento json de su base de datos mongo que ya tiene todo lo que necesita para generar el informe. Esto hace que la lectura de datos sea realmente fácil (¡y rápida!), Pero puede hacer que la escritura de datos sea bastante complicada (aquí es donde entra CQRS).

Las bases de datos como MongoDB son excelentes cuando generalmente sabe dónde están sus datos (en lugar de tener que escribir varias consultas complicadas). Con Mongo, los datos "relacionados" se anidan en los datos primarios o tienen claves primarias / externas. Esto es genial si, por ejemplo, tiene publicaciones y comentarios; en general, no va a mostrar comentarios fuera del contexto de una publicación, por lo que tiene sentido que los comentarios estén contenidos dentro de una publicación (de esa manera obtendrá todos los comentarios para la publicación sin necesidad de consultar una tabla separada).

MongoDB no tiene esquemas. Esto significa que tomará cualquier estructura de datos que le arrojes, en su mayor parte.

Por otro lado, si necesita usar funciones agregadas y siente la necesidad de consultar datos de formas complejas que no se pueden lograr mediante incrustaciones o relaciones simples en Mongo, es cuando sabe que es hora de usar un RDBMS como MySQL o PostgreSQL.

MongoDB no está destinado a reemplazar SQL. Simplemente satisface diferentes necesidades, y MongoDB y un RDBMS se pueden usar en conjunto. En mi opinión, MongoDB no es tan necesario si no necesita que sus datos sean flexibles o incrustados en un documento principal. El desarrollo con MongoDB es muy divertido porque hay muchos menos pasos involucrados para poner en marcha un proyecto (digamos en Rails). Necesitas hacer un cambio? No hay problema. Simplemente agregue un atributo a su modelo. Hecho.

No puedo hablar por muchas otras bases de datos NoSQL, aunque sé que generalmente están diseñadas de manera similar para satisfacer una necesidad específica que un RDBMS no puede satisfacer. Algunos residen completamente en la memoria o pueden ser fragmentados o escalados muy fácilmente. Estoy bastante seguro de que Cassandra está diseñada para continuar operando sin pérdida de datos si un nodo se cae. Redis es básicamente un almacén de valores clave que reside en la memoria (con escrituras periódicas de disco para persistencia), pero también tiene la capacidad de almacenar tipos de datos como conjuntos y ordenarlos.

La mayor victoria es cuando desea fragmentar datos o tener bases de datos maestras múltiples. Puede fragmentar datos en MySQL pero se convierte en un gran problema. Si está haciendo muchas escrituras, a menudo es útil compartir los datos en varios servidores, el problema es que si desea tener una fuerte consistencia referencial mientras lo hace, puede ser muy difícil, si no imposible, buscar el teorema CAP.

Las bases de datos SQL tienen una consistencia muy buena pero un soporte de particionamiento realmente malo, las bases de datos NoSQL tienden a ir a la inversa. Fácil de dividir pero a menudo lo que se llama consistencia eventual. Si está creando un sitio de mensajería que está bien, para un banco probablemente no esté bien.

La ventaja es que ahora hay varios modelos sobre cómo almacenar datos, por lo que puede elegir cómo implementar cosas, mientras que antes todo lo que tenía eran bases de datos SQL.

SE Radio ha tenido algunos buenos episodios sobre este tema.

MongoDB funciona bien cuando escribe muchos datos y cuando sus necesidades de consulta no son demasiado complicadas. Por lo tanto, MongoDB es una buena opción cuando implementa CQRS con Event Sourcing en el lado del comando, es decir, su tienda de eventos es una base de datos MongoDB.

En el lado de las consultas, todavía utilizamos una base de datos SQL Server con vistas y WCF Data Services en la parte superior, debido a su flexibilidad. Creo que en la mayoría de los casos realmente necesitará el poder de una base de datos relacional para realizar consultas.

La diferencia inmediata y fundamental entre MongoDB y un RDBMS es el modelo de datos subyacente. Una base de datos relacional estructura los datos en tablas y filas, mientras que MongoDB estructura los datos en colecciones de documentos JSON. JSON es un formato de datos autodescriptivo, legible por humanos. Originalmente diseñado para intercambios ligeros entre el navegador y el servidor, se ha aceptado ampliamente para muchos tipos de aplicaciones.

Los documentos JSON son particularmente útiles para la gestión de datos por varias razones. Un documento JSON se compone de un conjunto de campos que son en sí mismos pares clave-valor. Esto significa que cada documento JSON lleva consigo su propio diseño de esquema legible por humanos donde quiera que vaya, lo que permite que los documentos se muevan fácilmente entre la base de datos y las aplicaciones del cliente sin perder su significado.

JSON también es un formato de datos natural para usar en la capa de aplicación. JSON admite una estructura de datos más rica y flexible que las tablas compuestas de columnas y filas. Además de admitir tipos de campo como número, cadena, booleano, etc., los campos JSON pueden ser matrices o subobjetos anidados. Esto significa que podemos representar un conjunto de relaciones sofisticadas que son una representación más cercana de los objetos con los que trabajan nuestras aplicaciones. El uso de documentos JSON en nuestra base de datos significa que no necesitamos un mapeador relacional de objetos entre nuestra base de datos y las aplicaciones a las que sirve. Podemos conservar nuestros datos en la forma correcta.

Si sus datos necesitan muchas consultas, entonces una solución NoSQL no es buena y cuando necesita soporte transaccional (ACID), entonces un NoSql no es la mejor opción. Creo que NoSQL brilla cuando tienes muchas lecturas que deben ser rápidas y cuando la estructura es algo ad hoc, recuperas por documento o por estructura de página, algo así. Pero muchas soluciones NoSQL mejoran bastante rápido, por lo que las deficiencias pueden desaparecer pronto. De todos modos, creo que las bases de datos relacionales siguen siendo una buena opción para la mayoría de las aplicaciones.