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?
He usado CouchDB antes para proyectos de tres mascotas.
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
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:
Cons:
Puntos a menudo mal entendidos:
Para robar descaradamente de Renesis (en realidad estoy haciendo esta respuesta CW):
Uso de RDBMS en lugar de otros tipos:
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).
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.
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.
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.
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 documentosJSON 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
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.