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

128

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

Por lo que sé, las bases de datos de tipo NoSQL no están destinadas a reemplazar los RDBMS, pero ¿qué deben hacer exactamente?

    
pregunta Glorfindel 03.03.2011 - 19:48
fuente

9 respuestas

33

He usado CouchDB antes para proyectos de tres mascotas.

  • Un sistema de microblogging.
  • Para guardar información para una pequeña aplicación para tomar notas que hice.
  • Una aplicación de intercambio de ideas de propósito general.

La razón principal por la que elegí esto sobre algo como MSSQL o MySQL es la flexibilidad que obtienes cuando lo usas. Sin esquema rígido. Si tres meses después de la línea necesitas una tabla determinada para tener un campo adicional, y esto y aquello, simplemente lo cambias y se ondula de ahí en adelante.

Usé CouchDB para principiantes de Apress para aprender a usarlo.

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

Lee también: ¿Por qué debo usar la base de datos basada en documentos en lugar de relacional base de datos? en StackOverflow

    
respondido por el Sergio 03.03.2011 - 19:55
fuente
14

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

Pros:

  • MongoDB tiene una menor latencia por consulta & gasta menos tiempo de CPU por consulta porque está haciendo mucho menos trabajo (por ejemplo, sin uniones, transacciones). Como resultado, puede manejar una mayor carga en términos de consultas por segundo y, por lo tanto, a menudo se usa 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 consistencia.
  • MongoDB tiene una velocidad de escritura más rápida porque no tiene que preocuparse por las transacciones o las 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.

Cons:

  • 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 cliente . Por ejemplo, para unir datos, uno tiene que emitir varias consultas y hacer la unión 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 reciente. También hay menos expertos en MongoDB que sus homólogos relacionales.

Puntos a menudo mal entendidos:

  • Tanto las bases de datos relacionales como MongoDB son compatibles con la indexación. El rendimiento de sus consultas es similar en términos de ejecución de consultas grandes .
  • MongoDB no elimina la necesidad de migraciones o, más específicamente, actualiza sus datos existentes a medida que evoluciona su esquema. 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 (digamos que agrega un campo de imagen de perfil), entonces aún deberá:
    • 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 el código para proporcionar un valor predeterminado en el momento de la consulta si este campo no está presente O
    • Maneja el campo faltante de alguna otra manera
respondido por el Pace 18.04.2017 - 22:13
fuente
12

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

Uso de RDBMS en lugar de otros tipos:

respondido por el Matthew Read 23.05.2017 - 14:40
fuente
9

Cuando sus datos no son relacionales, puede haber grandes beneficios al usar las 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 normalmente 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 realizar 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 de 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 el CQRS).

    
respondido por el Graeme Hill 03.03.2011 - 22:17
fuente
7

Las bases de datos como MongoDB son excelentes cuando generalmente se 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 principales o tienen claves primarias / externas. Esto es genial si, por ejemplo, tienes 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 obtiene todos los comentarios de la publicación sin necesidad de consultar una tabla separada).

MongoDB es esquemático. Esto significa que tomará la estructura de datos que le envíe, en su mayor parte.

Por otra parte, si necesita utilizar funciones agregadas y siente la necesidad de consultar datos de formas complejas que no se pueden lograr a través de 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 a 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 estén incrustados en un documento principal. El desarrollo con MongoDB es muy divertido porque hay muchos menos pasos para poner en marcha un proyecto (por ejemplo, en Rails). Necesitas hacer un cambio? No hay problema. Solo agrega un atributo a tu 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 se pueden fragmentar o escalar 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 grabaciones periódicas de disco para persistencia), pero también tiene la capacidad de almacenar tipos de datos como conjuntos y ordenarlos.

    
respondido por el Ravenstine 23.03.2015 - 22:14
fuente
6

La ganancia principal es cuando desea compartir datos o tener bases de datos múltiples maestras. Puede compartir datos en MySQL pero se convierte en un gran dolor. Si está realizando muchas escrituras, a menudo es útil compartir los datos en varios servidores, el problema es que si desea tener una consistencia referencial sólida al hacer esto, puede ser muy difícil, si no imposible, consultar el teorema de CAP.

Las bases de datos SQL tienen una muy buena consistencia pero un soporte de partición realmente malo. Fácil de particionar 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 de cómo almacenar datos, por lo que hay opciones para implementar las cosas, mientras que antes solo tenías bases de datos SQL.

SE Radio ha tenido algunos buenos episodios sobre este tema.

    
respondido por el Zachary K 22.03.2011 - 15:57
fuente
1

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 está implementando CQRS con Event Sourcing en el lado del comando, es decir, su almacén de eventos es una base de datos de MongoDB.

En el lado de las consultas, todavía usamos una base de datos de 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.

    
respondido por el Roy Dictus 22.03.2011 - 15:45
fuente
1

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 legible por humanos, autodescriptivo. Originalmente diseñado para intercambios ligeros entre el navegador y el servidor, ha sido ampliamente aceptado 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 pares pares clave-valor. Esto significa que cada documento JSON lleva consigo su propio diseño de esquema legible por humanos donde sea que vaya, lo que permite a los documentos moverse fácilmente entre la base de datos y las aplicaciones 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 persistir nuestros datos en la forma correcta

    
respondido por el Diwakar upadhyay 23.03.2015 - 12:00
fuente
1

Si sus datos requieren muchas consultas, entonces una solución NoSQL no es buena y cuando necesita soporte transaccional (ACID), entonces 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 un tanto ad hoc, recuperas por documento o por estructura de página, algo así. Sin embargo, muchas soluciones NoSQL mejoran bastante rápido, por lo que es posible que pronto falten algunos defectos. De todos modos, creo que las bases de datos relacionales siguen siendo una buena opción para la mayoría de las aplicaciones.

    
respondido por el marko 24.03.2015 - 13:04
fuente

Lea otras preguntas en las etiquetas