¿Cuáles son las ventajas de usar una base de datos sin esquema como MongoDB en comparación con una base de datos relacional?

Estoy acostumbrado a usar bases de datos relacionales como MySQL o PostgreSQL, y combinadas con frameworks MVC como Symfony, RoR o Django, y creo que funciona muy bien.

Pero últimamente he escuchado mucho sobre MongoDB, que es una base de datos no relacional o, para citar la definición oficial ,

una base de datos orientada a documentos, escalable, de alto rendimiento, de código abierto, sin esquemas.

Estoy realmente interesado en estar al límite y quiero estar al tanto de todas las opciones que tendré para un próximo proyecto y elegir las mejores tecnologías que existen.

¿En qué casos es mejor usar MongoDB (o bases de datos similares) que usar bases de datos relacionales "clásicas"? ¿Y cuáles son las ventajas de MongoDB vs MySQL en general? O al menos, ¿por qué es tan diferente?

Si tiene sugerencias sobre documentación y / o ejemplos, también sería de gran ayuda.

Estas son algunas de las ventajas de MongoDB para crear aplicaciones web:

1. Un modelo de datos basado en documentos. La unidad básica de almacenamiento es análoga a JSON, diccionarios de Python, hashes de Ruby, etc. Esta es una estructura de datos rica capaz de contener matrices y otros documentos. Esto significa que a menudo puede representar en una sola entidad una construcción que requeriría varias tablas para representar correctamente en una base de datos relacional. Esto es especialmente útil si sus datos son inmutables.
2. Capacidad de consulta profunda. MongoDB admite consultas dinámicas en documentos mediante un lenguaje de consulta basado en documentos que es casi tan poderoso como SQL.
3. Sin migraciones de esquemas. Dado que MongoDB no tiene esquema, su código define su esquema.
4. Un camino claro hacia la escalabilidad horizontal.

Necesitará leer más sobre él y jugar con él para tener una mejor idea. Aquí hay una demostración en línea:

http://try.mongodb.org/

Existen numerosas ventajas.

Por ejemplo, el esquema de su base de datos será más escalable, no tendrá que preocuparse por las migraciones, el código será más agradable de escribir ... Por ejemplo, aquí está uno de los códigos de mi modelo:

class Setting
  include MongoMapper::Document

  key :news_search, String, :required => true
  key :is_availaible_for_iphone, :required => true, :default => false

  belongs_to :movie
end

¡Agregar una clave es simplemente agregar una línea de código!

También hay otras ventajas que aparecerán a largo plazo, como una mejor escalabilidad y velocidad.

... Pero tenga en cuenta que una base de datos no relacional no es mejor que una relacional . Si su base de datos tiene muchas relaciones y normalización, puede tener poco sentido usar algo como MongoDB. Se trata de encontrar la herramienta adecuada para el trabajo.

Para más cosas para leer, recomiendo echar un vistazo a " Por qué creo que Mongo es para las bases de datos lo que Rails fue para los Frameworks " o esta publicación en el sitio web de mongodb. Para emocionarse y si habla francés, eche un vistazo a este artículo que explica cómo configurar MongoDB desde cero.

Editar: Casi me olvido de contarles sobre este railscast de Ryan . ¡Es muy interesante y te hace querer empezar de inmediato!

La ventaja de sin esquema es que puede volcar lo que sea que tenga en él, y nadie tendrá ningún motivo para quejarse o para decir que estaba mal.

También significa que todo lo que le eches en él, quedará totalmente vacío de significado después de haberlo hecho.

Algunos lo etiquetarían como una gran desventaja, otros no.

El hecho de que una base de datos relacional tenga un esquema bien establecido, es consecuencia del hecho de que cuenta con un conjunto bien establecido de predicados extensionales, que son los que nos permiten dar significado a lo que está registrado en la base de datos, y cuáles son también es un requisito previo necesario para que podamos hacerlo.

Sin un esquema bien establecido, sin predicados extensionales y sin precicados extensionales, no hay forma de que el usuario le dé ningún significado a lo que contiene.

MongoDB apareció en FLOSS Weekly esta semana: http://twit.tv/floss105 Una base de datos que utiliza un concepto similar es CouchDB, que apareció en otro FLOSS Weekly: http://twit.tv/floss36

Creo que vale la pena escucharlos además de los enlaces proporcionados por @marcgg

Mi experiencia con Postgres y Mongo después de trabajar con ambas bases de datos en mis proyectos.

Postgres (RDBMS)

Se recomienda Postgres si sus aplicaciones futuras tienen un esquema complicado que necesita muchas uniones o todos los datos tienen relaciones o si tenemos una escritura pesada. Postgres es de código abierto, más rápido, compatible con ACID y utiliza menos memoria en el disco, y también tiene un buen rendimiento para el almacenamiento JSON e incluye la serialización completa de transacciones con 3 niveles de aislamiento de transacciones.

La mayor ventaja de permanecer con Postgres es que tenemos lo mejor de ambos mundos. Podemos almacenar datos en JSONB con restricciones, consistencia y velocidad. Por otro lado, podemos usar todas las funciones de SQL para otros tipos de datos. El motor subyacente es muy estable y se adapta bien a una buena variedad de volúmenes de datos. También se ejecuta en su elección de hardware y sistema operativo. Postgres proporciona capacidades NoSQL junto con soporte completo de transacciones, almacenando documentos JSON con restricciones en los datos de los campos.

Restricciones generales para Postgres

Escalar Postgres horizontalmente es significativamente más difícil, pero factible.

Las operaciones de lectura rápida no se pueden lograr por completo con Postgres.

SIN bases de datos SQL

Mongo DB (tigre con cable)

MongoDB puede vencer a Postgres en dimensión de "escala horizontal". El almacenamiento de JSON es para lo que Mongo está optimizado. Mongo almacena sus datos en un formato binario llamado BSONb que es (aproximadamente) solo una representación binaria de un superconjunto de JSON. MongoDB almacena objetos exactamente como fueron diseñados. Según MongoDB, para aplicaciones de escritura intensiva, Mongo dice que el nuevo motor (Wired Tiger) brinda a los usuarios un aumento de hasta 10 veces en el rendimiento de escritura (debería probar esto), con una reducción del 80 por ciento en la utilización del almacenamiento, lo que ayuda a reducir los costos de almacenamiento. , lograr una mayor utilización del hardware.

Restricciones generales de MongoDb

El uso de un motor de almacenamiento sin esquemas conduce al problema de los esquemas implícitos. Estos esquemas no están definidos por nuestro motor de almacenamiento, sino que se definen en función del comportamiento y las expectativas de la aplicación.

Las tecnologías NoSQL independientes no cumplen con los estándares ACID porque sacrifican las protecciones de datos críticos en favor de un alto rendimiento para aplicaciones no estructuradas. No es difícil aplicar ACID en bases de datos NoSQL pero haría que la base de datos sea lenta e inflexible hasta cierto punto. “La mayoría de las limitaciones de NoSQL se optimizaron en las nuevas versiones y lanzamientos que han superado sus limitaciones anteriores en gran medida”.

Se trata de compensaciones. MongoDB es rápido pero no ACID, no tiene transacciones. Es mejor que MySQL en algunos casos de uso y peor en otros.

Bellow Lines Written in MongoDB: The Definitive Guide.

Hay varias buenas razones:

1. Mantener diferentes tipos de documentos en la misma colección puede ser una pesadilla para desarrolladores y administradores. Los desarrolladores deben asegurarse de que cada consulta solo devuelva documentos de un cierto tipo o que el código de la aplicación que realiza una consulta pueda manejar documentos de diferentes formas. Si buscamos publicaciones de blog, es complicado eliminar los documentos que contienen datos de autor.
2. Es mucho más rápido obtener una lista de colecciones que extraer una lista de los tipos de una colección. Por ejemplo, si tuviéramos una clave de tipo en la colección que dijera si cada documento era un documento "descremado", "completo" o "grueso", sería mucho más lento encontrar esos tres valores en una sola colección que tener tres colecciones separadas y consultar sus nombres
3. La agrupación de documentos del mismo tipo en la misma colección permite la localización de los datos. Obtener varias publicaciones de blog de una colección que contiene solo publicaciones probablemente requerirá menos búsquedas de disco que obtener las mismas publicaciones de una colección que contenga publicaciones y datos de autor.
4. Comenzamos a imponer cierta estructura a nuestros documentos cuando creamos índices. (Esto es especialmente cierto en el caso de índices únicos). Estos índices se definen por colección. Al colocar solo documentos de un solo tipo en la misma colección, podemos indexar nuestras colecciones de manera más eficiente

Después de una pregunta sobre bases de datos con almacenamiento textual), eché un vistazo a MongoDB y sistemas similares.
Si entendí correctamente, se supone que son más fáciles de usar y configurar, y mucho más rápidos. Quizás también sea más seguro ya que la falta de SQL evita la inyección de SQL ...
Aparentemente, MongoDB se usa principalmente para aplicaciones web.
Básicamente, y afirman que ellas mismas, estas bases de datos no son adecuadas para consultas complejas, minería de datos, etc. Pero se destacan por recuperar rápidamente gran cantidad de datos planos.

1. MongoDB admite la búsqueda por campos, búsquedas de expresiones regulares. Incluye funciones de script java definidas por el usuario.
2. MongoDB se puede utilizar como un sistema de archivos, aprovechando las funciones de equilibrio de carga y replicación de datos en varias máquinas para almacenar archivos.