Me interesa conocer las estrategias de diseño que ha utilizado con bases de datos "nosql" no relacionales , es decir, la clase (en su mayoría nueva) de almacenes de datos que no utilizan el diseño relacional tradicional o SQL (como Hypertable, CouchDB, SimpleDB, almacén de datos de Google App Engine, Voldemort, Cassandra, SQL Data Services, etc.). También se les conoce como "almacenes clave / valor" y, en el fondo, actúan como tablas hash persistentes distribuidas gigantes.
Específicamente, quiero aprender sobre las diferencias en el diseño conceptual de datos con estas nuevas bases de datos. ¿Qué es más fácil, qué es más difícil, qué no se puede hacer en absoluto?
¿Ha creado diseños alternativos que funcionen mucho mejor en el mundo no relacional?
¿Te has golpeado la cabeza contra algo que parece imposible?
¿Ha cerrado la brecha con algún patrón de diseño, por ejemplo, para traducir de uno a otro?
¿Incluso hace modelos de datos explícitos ahora (por ejemplo, en UML) o los ha descartado por completo a favor de blobs de datos semiestructurados / orientados a documentos?
¿Echa de menos alguno de los principales servicios adicionales que proporcionan los RDBMS, como la integridad relacional, el soporte de transacciones arbitrariamente complejas, los activadores, etc.?
Vengo de un entorno de bases de datos relacionales SQL, por lo que la normalización está en mi sangre. Dicho esto, obtengo las ventajas de las bases de datos no relacionales por su simplicidad y escala, y mi instinto me dice que tiene que haber una superposición más rica de capacidades de diseño. ¿Qué has hecho?
Para su información, ha habido discusiones de StackOverflow sobre temas similares aquí:
Respuestas:
Creo que hay que tener en cuenta que los DBMS no relacionales difieren mucho con respecto a su modelo de datos y, por lo tanto, el diseño de datos conceptual también diferirá mucho. En el hilo Diseño de Datos en Bases de Datos No Relacionales del grupo NOSQL de Google se categorizan los diferentes paradigmas así:
Me gustan principalmente las bases de datos gráficas , y la elegancia del diseño de datos utilizando este paradigma fue lo que me llevó allí, cansado de las deficiencias de RDBMS . He puesto algunos ejemplos de diseño de datos usando una base de datos de gráficos en esta página wiki y también hay un ejemplo de cómo modelar los datos básicos de películas / actores / roles de IMDB .
La presentación de diapositivas (slideshare) Bases de datos de gráficos y el futuro de la gestión del conocimiento a gran escala de Marko Rodríguez contiene una muy buena introducción al diseño de datos utilizando una base de datos de gráficos.
Respondiendo a las preguntas específicas desde el punto de vista de graphdb:
Diseño alternativo: agregando relaciones entre muchos tipos diferentes de entidades sin preocupaciones o la necesidad de predefinir qué entidades pueden conectarse.
Cerrar la brecha: tiendo a hacer esto de manera diferente para cada caso, en función del dominio en sí, ya que no quiero un "gráfico orientado a tablas" y cosas por el estilo. Sin embargo, aquí hay información sobre la traducción automática de RDBMS a graphdb.
Modelos de datos explícitos: los hago todo el tiempo (estilo pizarra) y luego uso el modelo tal como está en la base de datos.
Miss del mundo RDBMS: formas sencillas de crear informes. Actualización: tal vez no es que duro para crear informes de una base de datos de gráfico, vea Creación de un informe de una base de datos Neo4J la muestra .
fuente
Acabo de comenzar con bases de datos no relacionales, y todavía estoy tratando de entenderlo y descubrir cuál sería el mejor modelo. Y solo puedo hablar por CouchDB.
Aún así, tengo algunas conclusiones preliminares:
¿Ha creado diseños alternativos que funcionen mucho mejor en el mundo no relacional?
El enfoque del diseño cambia: el diseño del modelo de documento (correspondiente a las tablas de la base de datos) se vuelve casi irrelevante, mientras que todo depende del diseño de las vistas (correspondiente a las consultas).
La base de datos de documentos cambia las complejidades: SQL tiene datos inflexibles y consultas flexibles, las bases de datos de documentos son al revés.
El modelo CouchDB es una colección de "documentos JSON" (básicamente tablas hash anidadas). Cada documento tiene una identificación única y se puede recuperar trivialmente por identificación. Para cualquier otra consulta, escribe "vistas", que se denominan conjuntos de funciones de mapa / reducción. Las vistas devuelven un conjunto de resultados como una lista de pares clave / valor.
El truco es que no consulta la base de datos en el sentido de que consulta una base de datos SQL: los resultados de ejecutar las funciones de vista se almacenan en un índice y solo se puede consultar el índice. (Como "obtener todo", "obtener clave" o "obtener rango de claves").
La analogía más cercana en el mundo de SQL sería si solo pudiera consultar la base de datos utilizando procedimientos almacenados: cada consulta que desee admitir debe estar predefinida.
El diseño de los documentos es enormemente flexible. He encontrado solo dos restricciones:
Pero todo depende del diseño de las vistas.
Los diseños alternativos que he encontrado que funcionan mejor con CouchDB que con cualquier base de datos SQL están a nivel de sistema en lugar de a nivel de almacenamiento. Si tiene algunos datos y desea servirlos en una página web, la complejidad del sistema total se reduce al menos en un 50%:
Para las aplicaciones web normales, las bases de datos basadas en documentos / JSON son una gran ventaja, y los inconvenientes de las consultas menos flexibles y algún código adicional para la validación de datos parecen un pequeño precio a pagar.
¿Te has golpeado la cabeza contra algo que parece imposible?
Aún no. Map / reduce como un medio de consultar una base de datos no es familiar y requiere mucho más pensamiento que escribir SQL. Hay una cantidad bastante pequeña de primitivas, por lo que obtener los resultados que necesita es principalmente una cuestión de ser creativo con la forma en que especifica las claves.
Existe una limitación en el sentido de que las consultas no pueden examinar dos o más documentos al mismo tiempo: no hay combinaciones ni otros tipos de relaciones de varios documentos, pero hasta ahora nada ha sido insuperable.
Como limitación de ejemplo, los recuentos y las sumas son fáciles, pero los promedios no se pueden calcular mediante una vista / consulta de CouchDB. Solución: devuelva la suma y cuente por separado y calcule el promedio del cliente.
¿Ha cerrado la brecha con algún patrón de diseño, por ejemplo, para traducir de uno a otro?
No estoy seguro de que sea factible. Es más un rediseño completo, como traducir un programa de estilo funcional a un estilo orientado a objetos. En general, hay muchos menos tipos de documentos que tablas SQL y más datos en cada documento.
Una forma de pensarlo es buscar en su SQL inserciones y consultas comunes: ¿qué tablas y columnas se actualizan cuando un cliente realiza un pedido, por ejemplo? ¿Y cuáles para los informes de ventas mensuales? Esa información probablemente debería ir en el mismo documento.
Es decir: Un documento para Pedido, que contiene ID de cliente e ID de producto, con campos replicados según sea necesario para simplificar las consultas. Cualquier cosa dentro de un documento se puede consultar fácilmente, cualquier cosa que requiera una referencia cruzada entre, por ejemplo, el Pedido y el Cliente, debe hacerlo el cliente. Entonces, si desea un informe sobre las ventas por región, probablemente debería poner un código de región en el pedido.
¿Incluso hace modelos de datos explícitos ahora (por ejemplo, en UML)?
Lo siento, nunca hice mucho UML antes de documentar DBs :)
Pero necesita algún tipo de modelo que diga qué campos pertenecen a qué documentos y qué tipo de valores contienen. Tanto para su propia referencia más adelante como para asegurarse de que todos los usuarios de la base de datos conozcan las convenciones. Dado que ya no obtiene un error si almacena una fecha en un campo de texto, por ejemplo, y cualquiera puede agregar o eliminar cualquier campo que desee, necesita tanto el código de validación como las convenciones para tomar el relevo. Especialmente si trabaja con recursos externos.
¿Echa de menos alguno de los principales servicios adicionales que ofrecen los RDBMS?
¡No! Pero mi experiencia es desarrollador de aplicaciones web, tratamos con bases de datos solo en la medida en que debemos :)
Una empresa para la que solía trabajar creó un producto (una aplicación web) que fue diseñado para ejecutarse en bases de datos SQL de múltiples proveedores, y los "servicios adicionales" son tan diferentes de una base de datos a otra que tuvieron que implementarse por separado para cada base de datos. Así que nos costó menos sacar la funcionalidad del RDBMS. Esto incluso se extendió a la búsqueda de texto completo.
Entonces, lo que sea que estoy renunciando es algo que nunca tuve en primer lugar. Obviamente, su experiencia puede diferir.
Una advertencia: en lo que estoy trabajando ahora es en una aplicación web para datos financieros, cotizaciones de acciones y similares. Esta es una muy buena combinación para una base de datos de documentos, desde mi punto de vista, obtengo todos los beneficios de una base de datos (persistencia y consultas) sin ninguna molestia.
Pero estos datos son bastante independientes entre sí, no existen consultas relacionales complejas. Obtenga las últimas cotizaciones por ticker, obtenga cotizaciones por ticker y rango de fechas, obtenga metainformación de la empresa, eso es prácticamente todo. Otro ejemplo que vi fue una aplicación de blog, y los blogs tampoco se caracterizan por esquemas de bases de datos enormemente complicados.
Lo que estoy tratando de decir es que todas las aplicaciones exitosas de bases de datos de documentos que conozco han sido con datos que no tenían muchas interrelaciones en primer lugar: documentos (como en la búsqueda de Google), publicaciones de blogs, artículos de noticias, datos financieros .
Espero que haya conjuntos de datos que se asignen mejor a SQL que al modelo de documento, así que imagino que SQL sobrevivirá.
Pero para aquellos de nosotros que solo queremos una forma sencilla de almacenar y recuperar datos, y sospecho que somos muchos, las bases de datos de documentos (como en CouchDB) son una bendición.
fuente
Estoy respondiendo a esto con CouchDB en el fondo de mi mente, pero supongo que la mayoría también sería cierta para otras bases de datos. Analizamos el uso de CouchDB, pero finalmente decidimos no hacerlo ya que nuestro acceso a los datos no se conoce de antemano y la escalabilidad no es el problema.
Más fuerte:
Más fácil:
El modelado debería ser más o menos el mismo, pero debes tener cuidado con lo que pones en un documento: UML también se puede usar tanto para el modelado OO como para el modelado DB, que ya son dos bestias diferentes.
Me hubiera gustado ver una buena base de datos OO abierta bien integrada con C # / Silverlight. Solo para hacer la elección aún más difícil. :)
fuente
Los archivos planos se han considerado durante mucho tiempo arcanos y poco prácticos para un conjunto de datos de cualquier tamaño. Sin embargo, las computadoras más rápidas y con más memoria hacen posible cargar un archivo en la memoria y clasificarlo en tiempo real, al menos para aplicaciones de un solo usuario locales y razonablemente pequeñas.
Por ejemplo, normalmente puede leer un archivo de 10,000 registros Y ordenarlo en un campo en menos de medio segundo, un tiempo de respuesta aceptable.
Por supuesto, existen razones para usar una base de datos en lugar de un archivo plano: operaciones relacionales, integridad de datos, capacidad multiusuario, acceso remoto, mayor capacidad, estandarización, etc., pero el aumento de la velocidad de la computadora y la capacidad de la memoria han hecho que la manipulación en la memoria de datos más práctico en algunos casos.
fuente
Las bases de datos relacionales que veo en la vida real tienden a no estar muy bien normalizadas, contrariamente a lo que afirma. Cuando se les pregunta, los diseñadores me dicen que se debe principalmente al rendimiento. Los RDBM no son buenos para unirse, por lo que las tablas tienden a ser demasiado amplias desde el punto de vista de la normalización. Las bases de datos orientadas a objetos tienden a ser mucho mejores en esto.
Otro punto en el que los RDBM tienen problemas es el manejo de claves dependientes del historial / tiempo.
fuente