¿Están las bases de datos orientadas a documentos destinadas a reemplazar las bases de datos relacionales?

Question

Recientemente he estado trabajando un poco con MongoDB y tengo que decir que realmente me gusta. Sin embargo, es un tipo de base de datos completamente diferente, entonces me utilizan. Me he dado cuenta de que definitivamente es mejor para ciertos tipos de datos, sin embargo, para bases de datos muy normalizadas, puede que no sea la mejor opción.

Sin embargo, me parece que puede ocupar el lugar de casi cualquier base de datos relacional que pueda tener y en la mayoría de los casos funciona mejor, lo que es alucinante. Esto me lleva a hacer algunas preguntas:

1. son bases de datos orientadas a documentos que se están desarrollando para ser la próxima generación de bases de datos y, básicamente reemplazar bases de datos relacionales por completo?
2. ¿Es posible que los proyectos utilicen tanto una base de datos orientada a documentos como una base de datos relacional una al lado de la otra para varios datos que se adapten mejor para uno u otro?
3. Si las bases de datos orientadas a documentos no están destinadas a reemplazar las bases de datos relacionales, ¿alguien tiene un ejemplo de una estructura de base de datos que estaría absolutamente mejor en una base de datos relacional (o viceversa)?

Answer 1

¿Las bases de datos orientadas a documentos se han desarrollado para ser la próxima generación de bases de datos y básicamente reemplazan completamente las bases de datos relacionales?

bases de datos orientadas a documentos

No. (como MongoDB) son muy buenos para el tipo de tareas que normalmente vemos en los sitios web modernos (rápido look-ups de artículos individuales o pequeños grupos de artículos).

Pero hacen algunas concesiones grandes con los sistemas relacionales. Sin cosas como el cumplimiento de ACID, no van a poder reemplazar ciertos RDBMS. Y si nos fijamos en sistemas como MongoDB, la falta de cumplimiento de ACID es una gran razón por la que es tan rápido.

¿Es posible que los proyectos estén mejor usando una base de datos orientada a documentos y una base de datos relacional uno al lado del otro para varios datos que son más adecuados para uno u otro?

Sí. De hecho, estoy ejecutando un sitio web de producción muy grande que usa ambos. El sistema se inició en MySQL, pero hemos migrado parte de él a MongoDB, porque necesitamos una tienda Key-Value y MySQL simplemente no es muy bueno para encontrar un artículo en un registro de 150M.

Si las bases de datos orientadas a documentos no están destinados a sustituir a las bases de datos relacionales, a continuación, ¿alguien tiene un ejemplo de una estructura de base de datos que absolutamente mejor en una base de datos relacional (o viceversa)?

bases de datos orientadas a documentos son grandes datos de almacenamiento que es fácilmente contenida en "clave-valor" y las relaciones simples y lineales "padre-hijo". Ejemplos simples aquí son cosas como Blogs y Wikis.

Sin embargo, bases de datos relacionales todavía tienen una ventaja fuerte en cosas como la creación de informes, que tiende a estar "basada en conjuntos".

Honestamente, puedo ver un mundo donde la mayoría de los datos son "manejados" por la base de datos orientada a documentos, pero donde los informes se realizan en una base de datos relacional que es actualizada por Map-reduce jobs.

Answer 2

AFAIK, las bases de datos de documentos no tienen JOIN. Eso es más o menos un obstáculo para> 99% de las necesidades de administración de datos.

Como señala Matthew Flaschen en los comentarios, incluso en el escritorio, bases de datos como SQLite están introduciendo la semántica de SQL en áreas que tradicionalmente han utilizado formatos de archivo de propiedad o XML.

Answer 3

Esto es realmente una cuestión de adecuación para el propósito.

Si desea poder unir algunas tablas y devolver un conjunto filtrado de resultados, solo puede hacerlo con una base de datos relacional. Si desea un rendimiento alucinante y volúmenes de datos increíbles, entonces es cuando las bases de datos de columna o familiares se vuelven independientes.

Este es un intercambio clásico. Las bases de datos relacionales le ofrecen un conjunto completo de funciones, que tiene un costo de rendimiento. Si no pudo unir, indexar, escanear o realizar una lista completa de características, elimina la necesidad de tener una vista de TODOS los datos, lo que le proporciona el rendimiento y la distribución que necesita para procesar datos serios.

Además, le recomiendo que siga los blogs de Ayende Rahien sobre este tema.

http://ayende.com/blog/

Answer 4

@Sohnee es el clavo. Podría añadir que bases de datos relacionales

• son excelentes para la recuperación de información en combinaciones inesperadas - aunque de vez en cuando que conduce a la mala idea de extensos informes que se ejecutan en los sistemas de producción sensibles al tiempo en lugar de en un almacén de datos independiente.
• son una tecnología madura donde puede encontrar fácilmente personal y soluciones bien probadas para cualquier cantidad de problemas (incluidas las limitaciones del modelo relacional, así como la implementación imperfecta que es SQL).

Pregúntese lo que quiere hacer, y qué calidades son importantes para usted. Puede hacer todo lo relacionado con la programación en scripts de shell. ¿Quieres?

Answer 5

Siempre que no necesite transacciones multiobjeto, MongoDB puede ser un reemplazo favorable para un RDMBS, especialmente en un contexto de aplicación web. La velocidad, la ausencia de esquemas y el modelado de documentos son útiles para este dominio.

Answer 6

Sigo haciendo la misma pregunta, que es lo que me trajo aquí. Uso tanto MySQL como MongoDB (no en tándem actualmente, aunque es una idea). Honestamente, debo decir que estoy muy contento de nunca volver a tocar MySQL. Seguro que existe el cumplimiento "ACID", pero ¿alguna vez se ha encontrado con la necesidad de reparar sus tablas con MySQL? ¿Alguna vez has tenido una base de datos corrupta? Sucede. ¿Alguna vez ha tenido otros problemas con MySQL? ¿Alguna contención de bloqueo o bloqueos muertos? ¿Algún problema con la agrupación? ¿Qué tan fácil fue configurar y configurar?

MongoDB ... Lo enciendes y ya está ... Entonces es autosharding. Es increíblemente simple y también increíblemente rápido. Entonces piensa en eso. Su tiempo.

No, no tienen JOIN, pero es una afirmación completamente incorrecta decir que descuenta más del 99% de las necesidades de administración de datos. A menudo me opongo cuando trato de explicar MongoDB, incluso las personas se ríen. Solo enfrentémoslo. La gente no quiere aprender cosas nuevas y piensan que lo que saben es todo lo que necesitan.Claro, puedes escapar usando MySQL el resto de tu vida y construir tus sitios web. Funciona, sabemos que funciona. También sabemos que falla. Si no fuera así, nunca haría la pregunta y probablemente no veríamos tantas bases de datos orientadas a documentos. Sabemos que sí se escala, pero es un dolor en la parte posterior para escalarlo.

También eliminemos el tráfico y la escala de la imagen. Desinstalar instalación Ahora centrémonos en el uso. ¿Cuál es su experiencia al usar MySQL? ¿Qué tan bueno es usted con la arquitectura MySQL y hacer consultas eficientes? ¿Cuánto tiempo pasas revisando las consultas con EXPLAIN? ¿Cuánto tiempo pasas haciendo diagramas de esquema? ... Digo tomar ese tiempo de vuelta. Es mejor gastar en otro lugar.

Esa es mi granito de arena. Realmente me encanta MongoDB y espero no volver a utilizar MySQL nunca más y para el tipo de sitios web que construyo, es muy posible que no sea necesario. Aunque aún estoy tratando de averiguar CUÁNDO querría usar MySQL sobre MongoDB, no cuando PUEDA (seamos realistas, almacena datos, felicidades, podría escribir una tonelada de archivos XML también, pero no es una buena idea) , pero cuando BENEFICIARÍA usar uno u otro. Mientras tanto, haré mi trabajo con MongoDB y tendré menos dolores de cabeza.

Answer 7

En mis bases de datos orientadas a documentos de opinión sólo son buenos para

1. bases de datos los datos que se representan mejor mediante un modelo jerárquico (árbol). Esto no es común para las bases de datos del sitio web.
2. Bases de datos con gran cantidad de datos como las bases de datos de Facebook y Amazon. En este caso, se requiere sacrificar los beneficios del modelo relacional.