ventajas tutorial español ejemplos desventajas consultas caracteristicas mongodb database

tutorial - mongodb vs mysql español



¿Cuáles son las ventajas de usar una base de datos libre de esquemas como MongoDB en comparación con una base de datos relacional? (9)

  1. MongoDB admite búsquedas 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 el equilibrio de carga y las funciones de replicación de datos en varias máquinas para almacenar archivos.

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

Pero últimamente he oído 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, libre de esquemas y orientada a documentos.

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 usar MongoDB (o bases de datos similares) es mejor que usar una base de datos relacional "clásica"? ¿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.

Bellow Lines escrito en MongoDB: The Definitive Guide.

Hay varias buenas razones:

  1. Mantener diferentes tipos de documentos en la misma colección puede ser una pesadilla para los desarrolladores y administradores. Los desarrolladores deben asegurarse de que cada consulta solo devuelva documentos de cierto tipo o que el código de la aplicación que realiza una consulta pueda manejar documentos de diferentes formas. Si estamos buscando publicaciones de blog, es una molestia 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 en una colección. Por ejemplo, si tuviéramos una clave de tipo en la colección que dijera si cada documento es un documento "descremado", "entero" o "mono 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. Agrupar documentos del mismo tipo en la misma colección permite la ubicación de los datos. Obtener varias publicaciones de blog de una colección que solo contiene 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 en 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 cuestión de bases de datos con almacenamiento de texto), eché un vistazo a MongoDB y sistemas similares.
Si entendí correctamente, se supone que es más fácil de usar y configurar, y mucho más rápido. Quizás también más seguro ya que la falta de SQL impide la inyección de SQL ...
Aparentemente, MongoDB se usa principalmente para aplicaciones web.
Básicamente, y ellos mismos afirman, estas bases de datos no son adecuadas para consultas complejas, extracción de datos, etc. Pero brillan al recuperar rápidamente gran cantidad de datos planos.

Estas son algunas de las ventajas de MongoDB para construir 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 enriquecida 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 adecuadamente 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 usando un lenguaje de consulta basado en documentos que es casi tan poderoso como SQL.
  3. Sin migraciones de esquema. Como MongoDB no tiene esquemas, tu código define tu esquema.
  4. Un camino claro hacia la escalabilidad horizontal.

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

http://try.mongodb.org/

Hay numerosas ventajas.

Por ejemplo, su esquema de 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í hay 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 solo 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, podría tener poco sentido usar algo como MongoDB. Se trata de encontrar la herramienta adecuada para el trabajo.

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

Editar: Casi me olvido de contarte acerca de esta transmisión por Ryan . ¡Es muy interesante y te hace desear comenzar de inmediato!

La ventaja de estar libre de esquemas es que puede volcar cualquier carga que tenga, y nadie tendrá motivos para quejarse ni para decir que fue incorrecto.

También significa que, independientemente de lo que arroje, queda totalmente vacío de significado una vez que lo haya hecho.

Algunos calificarían a eso de una gran desventaja, otros no.

El hecho de que una base de datos relacional tenga un esquema bien establecido es una consecuencia del hecho de que tiene un conjunto bien establecido de predicados extensionales, que es lo que nos permite asociar el significado a lo que se registra en la base de datos, y cuáles son también es un requisito previo necesario para que lo hagamos.

Sin un esquema bien establecido, sin predicados extensionales, y sin precintos extensionales, no hay forma de que el usuario adquiera ningún significado de lo que se incluyó en él.

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

La mayor ventaja de quedarse 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 características SQL para otros tipos de datos. El motor subyacente es muy estable y se adapta bien a un buen rango 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 total 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 completamente 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 lo que Mongo está optimizado para hacer. Mongo almacena sus datos en un formato binario llamado BSONb que es (más o menos) solo una representación binaria de un superconjunto de JSON. MongoDB almacena los objetos exactamente como fueron diseñados. Según MongoDB, para aplicaciones de escritura intensiva, Mongo dice que el nuevo motor (Wired Tiger) ofrece a los usuarios un aumento de hasta 10 veces en el rendimiento de escritura (debería intentarlo), con una reducción del 80% en la utilización de almacenamiento, ayudando a reducir los costos de almacenamiento , lograr una mayor utilización de hardware.

Restricciones generales de MongoDb

El uso de un motor de almacenamiento de esquema inferior 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 autónomas NoSQL no cumplen con los estándares ACID porque sacrifican las protecciones críticas de los datos a favor del rendimiento de alto rendimiento para las aplicaciones no estructuradas. No es difícil aplicar ACID en bases de datos NoSQL, pero haría que la base de datos fuera lenta e inflexible hasta cierto punto. "La mayoría de las limitaciones de NoSQL se optimizaron en las versiones más nuevas y versiones que superaron en gran medida sus limitaciones anteriores".

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.