¿Son las bases de datos orientadas a documentos más adecuadas que las relacionales para objetos persistentes?

Question

En términos de uso de bases de datos, la última década fue la era del ORM con cientos compitiendo para conservar nuestros gráficos de objetos en el antiguo RMDBS.Ahora parece que estamos siendo testigos de la mayoría de edad de las bases de datos orientadas a documentos. Estos bases de datos están altamente optimizados para documentos sin esquemas, pero también son muy atractivos por su capacidad de escalar y consultar un clúster en paralelo.

Las bases de datos orientadas a documentos también tienen un par de ventajas sobre los RDBMS para modelos de datos persistentes en diseños orientados a objetos.Como las tablas no tienen esquemas, se pueden almacenar objetos que pertenecen a diferentes clases en una jerarquía de herencia, uno al lado del otro.Además, a medida que cambia el modelo de dominio, siempre que el código pueda recuperar objetos de una versión anterior de las clases de dominio, se puede evitar tener que migrar toda la base de datos en cada cambio.

Por otro lado, los beneficios de rendimiento de las bases de datos orientadas a documentos parecen surgir principalmente cuando se almacenan documentos más profundos.En términos orientados a objetos, clases que se componen de otras clases, por ejemplo, una publicación de blog y sus comentarios.Sin embargo, en la mayoría de los ejemplos de esto que se me ocurren, como el del blog, la ganancia en acceso de lectura parecería compensarse con la penalización de tener que escribir el "documento" completo de la publicación del blog cada vez que se publica un nuevo comentario. agregado.

Me parece que las bases de datos orientadas a documentos pueden aportar beneficios significativos a los sistemas orientados a objetos si se tiene sumo cuidado en organizar los objetos en gráficos profundos optimizados para la forma en que se leerán y escribirán los datos, pero esto significa conocer los casos de uso. frente.En el mundo real, a menudo no lo sabemos hasta que tenemos una implementación en vivo que podemos perfilar.

Así es el caso de relacional vs.¿Las bases de datos orientadas a documentos son una de columpios y rotondas?Me interesan las opiniones y los consejos de la gente, en particular si alguien ha creado aplicaciones importantes en una base de datos orientada a documentos.

Answer 1

Bueno, depende de cómo se estructuran los datos y en la ficha de acceso patrones.

bases de datos documentales almacenar y recuperar documentos almacenados y la unidad atómica básica es un documento. Como usted ha dicho, es necesario pensar acerca de sus patrones de acceso a datos / casos de uso para crear un documento de modelo inteligente. Cuando su modelo de dominio puede ser dividida y se repartió a través de algunos documentos, un documento de una base de datos funciona como un encanto. Por ejemplo para un blog en software, un CMS o un wiki-software de un documento-db funciona muy bien. Mientras usted puede encontrar una buena manera de exprimir sus datos en un documento que no tiene ningún problema. Pero no intente para adaptarse a un modelo relacional en un documento-base de datos.  Tan pronto como los patrones de acceso a los datos de uso de una gran cantidad de 'navegación' en las relaciones, gráfico o de objeto bases de datos son una opción más natural.

Otra cosa es sobre compensaciones de lectura / escritura en el rendimiento. Por ejemplo un blog en software. En un RDBMS modelo de datos de transición se normaliza los datos. Esto significa que la lectura de los datos es caro, porque leen de diferentes tablas, las relaciones calcular con une etc para leer un blog post. A cambio, el cambio de una etiqueta es de bajo costo. Por el contrario, en un documento de una base de datos de la lectura de un blog post es barato, ya que acaba de cargar el post-documento. Sin embargo actualización es probablemente más caro, ya que es necesario almacenar todo el documento. O peor aún, pasar por un montón de documentos a cambio de algo (cambiar el nombre de una etiqueta-escenario). En la mayoría de los sistemas, la lectura es mucho más importante que la escritura. Lo que en realidad tiene sentido utilizar los almacenes de datos renormalizado.

Creo que en grandes bases de datos el diseño sin esquema puede tener sus ventajas. En RDBMS que necesita para actualizar el esquema que es un proceso muy doloroso. Especialmente para convertir los datos existentes al nuevo esquema. En una base de datos sin esquema, sus necesidades de aplicación para hacer frente a eso, lo que da más flexibilidad. Por ejemplo, puede actualizar el esquema sobre la marcha, cuando un documento de edad es de acceso. De esta manera, usted puede mantener su base de datos gigante en funcionamiento, mientras que las versiones más antiguas de los mangos de aplicación sobre la marcha.