Son las bases de datos orientadas a documentos destinados a sustituir a las bases de datos relacionales?

Question

Recientemente he estado trabajando un poco con MongoDB y tengo que decir que me gusta mucho. Sin embargo, es un tipo completamente diferente de la base de datos entonces estoy acostumbrado. Me he dado cuenta de que es definitivamente mejor para ciertos tipos de datos, sin embargo, para las bases de datos normalizados en gran medida podría no ser la mejor opción.

Me parece sin embargo que puede tomar por completo el lugar de casi cualquier base de datos relacional que pueda tener y en la mayoría de los casos un mejor desempeño, que es alucinante. Esto me lleva a hacer algunas preguntas:

1. son bases de datos orientadas a documentos siendo desarrollado para ser la próxima generación de bases de datos y, básicamente reemplazar bases de datos relacionales completamente?
2. ¿Es posible que los proyectos serían mejor usar tanto una base de datos documental y un lado de base de datos relacional a lado por varios datos, que es más adecuado para una o la otra?
3. 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)?

Answer 1

  

son bases de datos orientadas a documentos han sido desarrollados para ser la próxima generación de bases de datos y, básicamente reemplazar bases de datos relacionales completamente?

No. bases de datos orientadas a documentos (como MongoDB) son muy buenos para el tipo de tareas que normalmente vemos en los sitios web modernos (rápida mirada planos de objetos individuales o pequeños grupos de artículos).

Pero hacen algunos grandes compensaciones con los sistemas relacionales. Sin cosas como el cumplimiento de ACID que no van a ser capaces de reemplazar ciertos RDBMS. Y si nos fijamos en sistemas como MongoDB, la falta de cumplimiento de ACID es una de las razones es tan rápido.

  

¿Es posible que los proyectos serían mejor usar tanto una base de datos documental y un lado de base de datos relacional a lado por varios datos, que es más adecuado para una o la otra?

Sí. De hecho, estoy corriendo una producción muy grande sitio web que utiliza ambos. El sistema se inició en MySQL, pero hemos migrado parte de ella a MongoDB, b / c que necesitamos un almacén de valor-clave y MySQL no es muy bueno en la búsqueda de un elemento en una más de 150 millones de registros.

  

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 almacenamiento de datos que es fácilmente contenidos en "clave-valor" y simples, lineales relaciones "padre-hijo". Ejemplos sencillos aquí son cosas como blogs y wikis.

Sin embargo, relacional de bases de datos todavía tienen una fuerte ventaja sobre cosas como la presentación de informes, que tiende a ser "basada puesta a punto".

Sinceramente, puedo ver un mundo donde la mayoría de los datos son "manejados" por base de datos documental, pero donde la información se realiza en una base de datos relacional que se actualiza por Mapa-a reducir puestos de trabajo.

Answer 2

Esto es realmente una cuestión de aptitud para el uso.

Si usted quiere ser capaz de unirse a algunas mesas y devolver un conjunto filtrado de los resultados, sólo se puede hacer eso con una base de datos relacional. Si quieres un rendimiento increíble y tienen volúmenes increíbles de datos, que es cuando la columna familiar o bases de datos orientadas a documentos entrar en su cuenta.

Este es un clásico equilibrio. bases de datos relacionales que ofrecen un conjunto completo de características, que viene con un costo de rendimiento. Si no puede unirse, índice, o llevar a cabo la exploración en su conjunto otra lista de características, se elimina la necesidad de tener ningún punto de vista sobre los datos de todos, lo que le ofrece el rendimiento y la distribución que necesita para crisis graves de datos.

También, recomendamos que siga los blogs de Ayende Rahien sobre este tema.

http://ayende.com/blog/

Answer 3

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

• son excelentes para la recuperación de información en combinaciones inesperadas - incluso si, que en ocasiones conduce a la mala idea de los informes extensos 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 podrá encontrar fácilmente el personal y bien probadas soluciones a cualquier número de problemas (incluyendo las limitaciones del modelo relacional, así como la aplicación imperfecta que es SQL).

Hágase lo que quiere hacer, y lo que cualidades son importantes para usted. Puede hacer todo lo relacionado con la programación de scripts de shell. ¿Quieres?

Answer 4

sigo haciendo la misma pregunta, que es lo que me llevó aquí. Yo MySQL y MongoDB (no en tándem en la actualidad, aunque su idea) utilizo. Tengo que decir sinceramente que estoy muy feliz de tocar nunca se MySQL de nuevo. Seguro que hay al cumplimiento "Acid", pero que nunca han topado con la necesidad de reparar las tablas con MySQL? ¿Alguna vez ha tenido una base de datos dañada? Sucede. ¿Ha tenido algún otro problema con MySQL? Cualquier contenciones de bloqueo o las cerraduras? Cualquier problema con la agrupación? ¿Ha sido fácil de instalar y configurar?

MongoDB ... Se enciende y se hace .... A continuación se autosharding. Es muy simple y es también muy rápido. Así que pensar en eso. Su tiempo.

No, ellos no tienen JOINs pero es una declaración totalmente incorrecto decir que se descuenta más del 99% de las necesidades de gestión de datos. A menudo recibo oposición al tratar de explicar MongoDB, la gente incluso a reírse. Permiten a hacerle frente. La gente no quiere aprender nuevas cosas y piensan que lo que saben es todo lo que necesitan. Claro, usted puede conseguir lejos de MySQL usando el resto de su vida y construir sus sitios web. Funciona, sabemos que funciona. También sabemos que falle. Si no fuera así, que nunca lo hace la pregunta y que probablemente no vería tantas bases de datos orientadas documento. Sabemos que sí lo hace escala, pero es un dolor en la parte trasera para escalarla.

También Vamos a eliminar el tráfico y la escala de la imagen. Saque de configuración. Ahora vamos a centrarnos en el uso. ¿Cuál es su experiencia al usar MySQL? ¿Qué tan bueno eres con la arquitectura MySQL y hacer consultas eficientes? ¿Cuánto tiempo pasas mirando por encima de consultas con EXPLICAR? ¿Cuánto tiempo pasas haciendo diagramas de esquema? ... Yo digo que tome tiempo atrás. Es mejor gastado en otro lugar.

Esa es mi granito de arena. Realmente me MongoDB amor y la esperanza de nunca usar MySQL de nuevo y por el tipo de sitios web que construyo, es muy posible que no voy a necesitar. Aunque todavía estoy tratando de averiguar cuándo me gustaría usar MySQL a través de MongoDB, no cuando puedo (seamos sinceros, que almacena los datos, felicitaciones, podría escribir una tonelada de archivos XML también, pero no es una buena idea) , pero cuando se beneficiaría de utilizar uno u otro. Mientras tanto, voy a ir a hacer mi trabajo con MongoDB y tienen menos dolores de cabeza.

Answer 5

Mientras que no es necesario transacciones múltiples objetos, MongoDB puede ser un reemplazo favorable para un RDMBS, especialmente en un contexto de aplicaciones web. Velocidad, schemalessness, y el modelado documento son útiles este dominio.

Answer 6

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

1. Bases de datos cuyos datos se refleje mejor el uso de 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 es necesario sacrificar los beneficios del modelo relacional.

Answer 7

Que yo sepa, las bases de datos de documentos no tienen JOIN. Eso es más o menos un show-tapón de> 99% de las necesidades de gestión de datos.

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