database - tutorial - Diseño de base de datos no relacional
nosql tutorial español (5)
Acabo de comenzar con DB 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:
¿Has encontrado diseños alternativos que funcionan mucho mejor en el mundo no relacional?
Los cambios de enfoque de diseño: el diseño del modelo de documento (correspondiente a las tablas de BD) se vuelve casi irrelevante, mientras que todo se basa en el diseño de las vistas (que corresponden a las consultas).
La clase de documento DB intercambia las complejidades: SQL tiene datos inflexibles y consultas flexibles, documentos DB 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 ID. Para cualquier otra consulta, escriba "vistas", que se denominan conjuntos de funciones de mapa / reducir. 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 en 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 clave").
La analogía más cercana en el mundo de SQL sería si solo pudiera consultar la base de datos utilizando procedimientos almacenados: todas las consultas que desea admitir deben estar predefinidas.
El diseño de los documentos es enormemente flexible. He encontrado solo dos restricciones:
- Mantenga los datos relacionados juntos en el mismo documento, ya que no hay nada que corresponda a una unión.
- No haga que los documentos sean tan grandes que se actualicen con demasiada frecuencia (como poner todas las ventas de la empresa para el año en el mismo documento), ya que cada actualización de documentos desencadena una nueva indexación.
Pero todo depende del diseño de las vistas.
Los diseños alternativos que he encontrado que trabajan órdenes de magnitud mejor con CouchDB que cualquier base de datos SQL están en el nivel del sistema en lugar del nivel de almacenamiento. Si tiene algunos datos y desea enviarlos a una página web, la complejidad del sistema total se reduce al menos en un 50%:
- no diseñar tablas de DB (problema menor)
- sin capa intermedia ODBC / JDBC, todas las consultas y transacciones en http (problema moderado)
- simple mapeo DB-a-objeto desde JSON, que es casi trivial en comparación con el mismo en SQL (¡muy importante!)
- puede omitir todo el servidor de aplicaciones, ya que puede diseñar sus documentos para ser recuperados directamente por el navegador usando AJAX y agregar un poco de pulido de JavaScript antes de que se muestren como HTML. (¡¡ENORME!!)
Para las webapps normales, las bases de datos basadas en documentos / JSON son una gran victoria, y los inconvenientes de las consultas menos flexibles y algunos códigos adicionales para la validación de datos parecen ser un pequeño precio a pagar.
¿Te has golpeado la cabeza contra algo que parece imposible?
Aún no. Mapa / reducir como una forma de consultar una base de datos no es familiar, y requiere mucho más pensamiento que escribir SQL. Hay un número bastante pequeño de primitivas, por lo que obtener los resultados que necesita es principalmente una cuestión de ser creativo con la forma de especificar las claves.
Existe una limitación en el sentido de que las consultas no pueden mirar dos o más documentos al mismo tiempo, sin uniones u otros tipos de relaciones de múltiples documentos, pero hasta ahora nada ha sido insuperable.
Como una 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 en el cliente.
¿Ha superado la brecha con cualquier 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 la traducción de 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 mirar su SQL para inserciones y consultas comunes: ¿Qué tablas y columnas se actualizan cuando un cliente hace un pedido, por ejemplo? ¿Y cuáles para 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 puede ser consultada fácilmente, cualquier cosa que requiera referencias cruzadas entre say Order y Customer debe ser realizada por el cliente. Entonces, si desea un informe sobre las ventas por región, probablemente deba incluir 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é tipos de valores contienen. Tanto para su propia referencia más adelante como para asegurarse de que todos los que usan DB conozcan las convenciones. Como ya no obtienes un error si almacenas una fecha en un campo de texto, por ejemplo, y cualquiera puede agregar o eliminar cualquier campo que le apetezca, necesitas tanto el código de validación como las convenciones para compensar la holgura. Especialmente si trabajas con recursos externos.
¿Echa de menos alguno de los principales servicios adicionales que proporcionan RDBMS?
Nop. Pero mi experiencia se basa en el desarrollo de aplicaciones web, solo trabajamos con bases de datos en la medida en que debemos :)
Una empresa para la que solía trabajar creó un producto (una aplicación web) diseñado para ejecutarse en bases de datos SQL de múltiples proveedores, y los "servicios adicionales" son tan diferentes de DB a DB que tuvieron que implementarse por separado para cada DB. Así que nos fue menos trabajo mover la funcionalidad del RDBMS. Esto incluso se extendió a la búsqueda de texto completo.
Entonces, lo que sea que me esté dando por vencido es algo que nunca tuve realmente en primer lugar. Obviamente, tu experiencia puede diferir.
Una advertencia: en lo que estoy trabajando ahora es en una aplicación web para datos financieros, cotizaciones de acciones y demás. Esta es una muy buena combinación para un documento DB, desde mi punto de vista obtengo todos los beneficios de un DB (persistencia y consultas) sin ninguna molestia.
Pero estos datos son bastante independientes entre sí, no hay consultas relacionales complejas. Obtenga las últimas cotizaciones por ticker, obtenga cotizaciones por ticker y rango de fechas, obtenga meta-info de la compañía, 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 trato de decir es que todas las aplicaciones exitosas de documentos DB que conozco han sido con datos que no tenían muchas interrelaciones en primer lugar: documentos (como en la búsqueda de Google), publicaciones en blogs, artículos de noticias, datos financieros .
Espero que haya conjuntos de datos que se correlacionen mejor con SQL que con el modelo de documento, así que supongo que SQL sobrevivirá.
Pero para aquellos de nosotros que solo queremos una manera simple de almacenar y recuperar datos, y sospecho que hay muchos de nosotros, las bases de datos de documentos (como en CouchDB) son un regalo del cielo.
Estoy interesado en conocer las estrategias de diseño que ha utilizado con las bases de datos "nosql" no relacionales , es decir, la clase (en su mayoría nueva) de almacenes de datos que no usan 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 suelen denominarse "tiendas clave / valor", y en la base actúan como gigantescas tablas hash persistentes distribuidas.
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?
¿Has encontrado diseños alternativos que funcionan mucho mejor en el mundo no relacional?
¿Te has golpeado la cabeza contra algo que parece imposible?
¿Ha superado la brecha con cualquier 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 orientados a documentos o semiestructurados?
¿Echa de menos alguno de los principales servicios adicionales que proporcionan RDBMS, como integridad relacional, soporte de transacciones arbitrariamente complejo, activadores, etc.?
Vengo de un fondo DB DB relacional, por lo que la normalización está en mi sangre. Dicho esto, obtengo las ventajas de las bases de datos no relacionales para simplificar y escalar, y mi instinto me dice que tiene que haber una superposición más rica de las capacidades de diseño. ¿Qué has hecho?
FYI, ha habido discusiones de StackOverflow sobre temas similares aquí:
Creo que debe tener en cuenta que los DBMS no relacionales difieren mucho en cuanto a su modelo de datos y, por lo tanto, el diseño de los datos conceptuales también será muy diferente. En el hilo Diseño de datos en bases de datos no relacionales del grupo Google NOSQL, los diferentes paradigmas se clasifican así:
- Sistemas parecidos a Bigtable (HBase, Hypertable, etc.)
- Tiendas de valores clave (Tokio, Voldemort, etc.)
- Bases de datos de documentos (CouchDB, MongoDB, etc.)
- Bases de datos de gráficos (AllegroGraph, Neo4j, Sesame, etc.)
Principalmente me dedico a las bases de datos de gráficos , 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ícula / actor / rol de IMDB .
Las diapositivas de presentación (slideshare) Las bases de datos de gráficos y el futuro de la gestión del conocimiento a gran escala de Marko Rodriguez también contienen una muy buena introducción al diseño de datos usando una base de datos de gráficos.
Respondiendo a las preguntas específicas desde un punto de vista graphdb:
Diseño alternativo: agregar relaciones entre muchos tipos diferentes de entidades sin preocupaciones o una necesidad de predefinir qué entidades se pueden conectar.
Cerrando la brecha: Tiendo a hacer esto diferente para cada caso, basado en el dominio mismo, ya que no quiero un "gráfico orientado a la mesa" y similares. Sin embargo, here''s información sobre la traducción automática de RDBMS a graphdb.
Modelos de datos explícitos: hago esto todo el tiempo (estilo de pizarra), y luego uso el modelo tal como está en la base de datos también.
Extraño del mundo de RDBMS: formas fáciles de crear informes. Actualización: tal vez no sea tan difícil crear informes desde una base de datos de gráficos, consulte Crear un informe para una base de datos de ejemplo de Neo4J .
Estoy respondiendo esto con CouchDB en el fondo de mi mente, pero supongo que la mayoría sería cierto para otros DB también. 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:
- Toma un replanteamiento a nivel conceptual, por lo que es ''más difícil'' ya que simplemente es diferente. Como debe conocer sus patrones de acceso a datos por adelantado, no se puede aplicar ninguna traducción automática. Debería agregar el patrón de acceso al menos.
- La base de datos no maneja la consistencia, pero debe tratarse en la aplicación. Menos garantías significa una migración más fácil, un fail-over y una mejor escalabilidad a costa de una aplicación más complicada. Una aplicación tiene que lidiar con conflictos e inconsistencias.
- Los enlaces que cruzan documentos (o clave / valor) también deben tratarse en el nivel de la aplicación.
- El tipo de base de datos SQL tiene IDEs que son mucho más maduros. Obtiene una gran cantidad de bibliotecas de soporte (aunque la superposición de esas bibliotecas hace que las cosas sean mucho más complejas de lo necesario para SQL).
Más fácil:
- Más rápido si conoce sus patrones de acceso a datos.
- Migrar / Fail-over es más fácil para la base de datos ya que no se le hacen promesas como programador de aplicaciones. Aunque obtienes consistencia eventual. Probablemente. Finalmente. Algun tiempo.
- Una clave / valor es mucho más fácil de entender que una fila de una tabla. Todas las relaciones (árbol) ya están dentro, y los objetos completos pueden ser reconocidos.
El modelado debe ser aproximadamente el mismo, pero debe tener cuidado con lo que coloca 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 abierta de OO muy bien integrada con C # / Silverlight. Solo para hacer la elección aún más difícil. :)
Las bases de datos relacionales que veo en la vida real tienden a no estar muy bien normalizadas, en contra de su afirmación. Cuando me preguntan, los diseñadores me dicen que eso 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 donde los RDBM tienen problemas es el manejo de las claves dependientes del historial / tiempo.
Los archivos planos durante mucho tiempo han sido considerados arcanos y poco prácticos para un conjunto de datos de cualquier tamaño. Sin embargo, las computadoras más rápidas con más memoria permiten cargar un archivo en la memoria y ordenarlo en tiempo real, al menos para aplicaciones relativamente pequeñas ny locales de un solo usuario.
Por ejemplo, generalmente 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, hay 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 la mayor velocidad de la computadora y la capacidad de memoria han hecho que la memoria se manipule de datos más prácticos en algunos casos.