nosql - una - mongodb caracteristicas
¿Me estoy perdiendo algo acerca de las bases de datos de documentos? (4)
He estado observando el auge del movimiento NoSql y el aumento en la popularidad de las bases de datos de documentos como mongodb, ravendb y otros. Si bien hay algunas cosas sobre estas que me gustan, siento que no estoy entendiendo algo importante.
Digamos que está implementando una aplicación de tienda y desea almacenar en los productos de base de datos, todos los cuales tienen una categoría única y única. En las bases de datos relacionales, esto se lograría al tener dos tablas, un producto y una tabla de categorías, y la tabla de productos tendría un campo (llamado quizás "category_id") que haría referencia a la fila en la tabla de categorías que contiene la entrada de categoría correcta. Esto tiene varios beneficios, incluyendo la no repetición de datos.
También significa que si escribió mal el nombre de la categoría, por ejemplo, podría actualizar la tabla de categorías y luego se solucionará, ya que ese es el único lugar donde existe ese valor.
En las bases de datos de documentos, sin embargo, no es así como funciona. Desnormaliza completamente, es decir, en el documento de "productos", en realidad tendría un valor que contiene la cadena de categoría real, lo que lleva a una gran cantidad de repetición de datos, y los errores son mucho más difíciles de corregir. Pensando más en esto, ¿no significa también que ejecutar consultas como "dame todos los productos con esta categoría" puede llevar a resultados que no tienen integridad?
Por supuesto, la forma de evitar esto es volver a implementar todo lo relacionado con "category_id" en la base de datos de documentos, pero cuando llego a ese punto en mi pensamiento, me doy cuenta de que debería quedarme con las bases de datos relacionales en lugar de volver a implementarlas.
Esto me lleva a creer que me estoy perdiendo algún punto clave sobre las bases de datos de documentos que me lleva por este camino incorrecto. Así que quería ponerlo en el desbordamiento de pila, ¿qué me estoy perdiendo?
Desnormaliza completamente, es decir, en el documento de "productos", en realidad tendría un valor que contiene la cadena de categoría real, lo que lleva a una gran cantidad de repetición de datos [...]
Es cierto que denormalizar significa almacenar datos adicionales. También significa menos colecciones (tablas en SQL), lo que resulta en menos relaciones entre piezas de datos. Cada documento individual puede contener la información que de otro modo provendría de varias tablas SQL.
Ahora, si su base de datos está distribuida en múltiples servidores, es más eficiente consultar un solo servidor en lugar de múltiples servidores. Con la estructura desnormalizada de las bases de datos de documentos, es mucho más probable que solo necesite consultar un único servidor para obtener todos los datos que necesita . Con una base de datos SQL, es probable que sus datos relacionados se distribuyan en varios servidores, lo que hace que las consultas sean muy ineficientes.
y los errores son mucho más difíciles de corregir.
También es cierto. La mayoría de las soluciones NoSQL no garantizan cosas como la integridad referencial, que son comunes a las bases de datos SQL. Como resultado, su aplicación es responsable de mantener las relaciones entre los datos. Sin embargo, como la cantidad de relaciones en una base de datos de documentos es muy pequeña, no es tan difícil como puede parecer.
Una de las ventajas de una base de datos de documentos es que no tiene esquema . Usted es completamente libre de definir el contenido de un documento en todo momento; no está vinculado a un conjunto predefinido de tablas y columnas como lo está con una base de datos SQL.
Ejemplo del mundo real
Si está creando un CMS sobre una base de datos SQL, tendrá una tabla separada para cada tipo de contenido de CMS o una tabla única con columnas genéricas en las que almacena todo tipo de contenido. Con tablas separadas, tendrás muchas mesas. Solo piense en todas las tablas de unión que necesitará para cosas como etiquetas y comentarios para cada tipo de contenido . Con una sola tabla genérica, su aplicación es responsable de administrar correctamente todos los datos. Además, los datos sin procesar en su base de datos son difíciles de actualizar y carecen de sentido fuera de su aplicación CMS.
Con una base de datos de documentos, puede almacenar cada tipo de contenido de CMS en una sola colección, mientras mantiene una estructura fuertemente definida dentro de cada documento. También puede almacenar todas las etiquetas y comentarios dentro del documento, haciendo que la recuperación de datos sea muy eficiente . Esta eficiencia y flexibilidad tienen un precio: su aplicación es más responsable de administrar la integridad de los datos. Por otro lado, el precio de ampliación de escala con una base de datos de documentos es mucho menor, en comparación con una base de datos SQL.
Consejo
Como puede ver, las soluciones SQL y NoSQL tienen ventajas y desventajas. Como David ya señaló , cada tipo tiene sus usos. Le recomiendo analizar sus requisitos y crear dos modelos de datos, uno para una solución SQL y otro para una base de datos de documentos. Luego elija la solución que mejor se ajuste, teniendo en cuenta la escalabilidad.
Diría que lo primero que se pasa por alto (al menos en función del contenido de la publicación) es que las bases de datos de documentos no pretenden reemplazar las bases de datos relacionales. El ejemplo que da, de hecho, funciona realmente bien en una base de datos relacional. Probablemente debería quedarse allí. Las bases de datos de documentos son solo otra herramienta para realizar tareas de otra manera, no son adecuadas para todas las tareas.
Las bases de datos de documentos se crearon para abordar el problema que (al mirarlo al revés), las bases de datos relacionales no son la mejor manera de resolver todos los problemas. Ambos diseños tienen su uso, ninguno es inherentemente mejor que el otro.
Eche un vistazo a los casos de uso en el sitio web de MongoDB: http://www.mongodb.org/display/DOCS/Use+Cases
Un documento db da una sensación de libertad cuando empiezas. Ya no tiene que escribir crear tablas y modificar scripts de tablas. Simplemente incrusta los detalles en los ''registros'' maestros.
Pero después de un tiempo te das cuenta de que estás encerrado de una manera diferente. Se vuelve menos fácil combinar o agregar los datos de una manera que no creía que era necesaria cuando almacenó los datos. La minería de datos / inteligencia empresarial (buscar lo desconocido) se vuelve más difícil.
Eso significa que también es más difícil verificar si su aplicación ha almacenado los datos en la base de datos de manera correcta.
Por ejemplo, tiene dos colecciones con cada aproximadamente 10000 ''registros''. Ahora desea saber qué ID están presentes en la ''tabla'' A que no están presentes en la ''tabla'' B.
Trivial con SQL, mucho más difícil con MongoDB.
Pero me gusta MongoDB !!
OrientDB , por ejemplo, admite el modo sin esquema, con esquema completo o mixto. En algunos contextos, necesita restricciones, validación, etc., pero necesitaría la flexibilidad para agregar campos sin tocar el esquema. Este es un esquema de modo mixto.
Ejemplo:
{''@rid'': 10: 3, ''@class'': ''Cliente'', ''@ver'': 3, ''nombre'': ''Jay'', ''apellido'': ''Minero'', ''inventado'': [''Amiga'' ]}
En este ejemplo, los campos "nombre" y "apellido" son obligatorios (al definirlos en el esquema), pero el campo "inventado" se ha creado solo para este documento. Toda su aplicación necesita no saberlo, pero puede ejecutar consultas en su contra:
SELECCIONE DEL CLIENTE DONDE EL INVENTO NO ES NULO
Sólo se devolverán los documentos con el campo "inventado".