Diseño de bases de datos no relacionales [cerrado]

Question

Me interesa saber acerca de las estrategias de diseño que ha utilizado con bases de datos no relacionales "nosql" - 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, el almacén de datos de Google App Engine, Voldemort, Cassandra, SQL Data Services, etc.).También se les suele denominar "almacenes de clave/valor" y, en esencia, actúan como tablas hash persistentes distribuidas gigantes.

Específicamente, quiero aprender sobre las diferencias en diseño de datos conceptuales 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?

• ¿Se te han ocurrido 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, p.traducir de uno a otro?

• ¿Incluso haces modelos de datos explícitos ahora (p. ej.en UML) o los ha descartado por completo en favor de blobs de datos semiestructurados/orientados a documentos?

• ¿Echa de menos alguno de los principales servicios adicionales que brindan los RDBMS, como integridad relacional, soporte para transacciones arbitrariamente complejas, activadores, etc.?

Vengo de una base de datos relacional SQL, por lo que la normalización está en mi sangre.Dicho esto, obtengo las ventajas de las bases de datos no relacionales en cuanto a simplicidad y escalabilidad, 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 sobre StackOverflow sobre temas similares aquí:

• la próxima generación de bases de datos
• cambiar esquemas para trabajar con Google App Engine
• elegir una base de datos orientada a documentos

Answer 1

Yo creo que hay que tener en cuenta que el DBMS no relacionales difieren mucho en cuanto a su modelo de datos y por lo tanto el diseño conceptual de datos también diferirá mucho. En el hilo de datos de diseño de bases de datos no relacionales del href="http://groups.google.com/group/nosql-discussion/" rel="nofollow noreferrer"> grupo los diferentes paradigmas se clasifican como sigue:

1. sistemas Bigtable-como (HBase, Hypertable, etc)
2. clave-valor tiendas (Tokio, Voldemort, etc)
3. bases de datos de documentos (CouchDB, MongoDB, etc)
4. bases de datos de gráficos (AllegroGraph, Neo4j, sésamo, etc.)

Lo que más me 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 utilizando una base de datos gráfico de esta y hay una de cómo modelar la básica IMDB datos de película / agente / papel también.

Las diapositivas de presentación (Slideshare) Bases de datos y el futuro de Gran Escala de Gestión del conocimiento Marko Rodríguez contiene una muy buena introducción a diseño de datos mediante una base de datos gráfica también.

Responder a las preguntas específicas desde un punto de vista graphdb:

El diseño alternativo:. La adición de las relaciones entre los diferentes tipos de entidades sin ningún tipo de preocupaciones o la necesidad de definir previamente qué entidades pueden conectarse

Cerrar la brecha: tiendo a hacerlo diferente para cada caso, basado en el dominio de sí mismo, ya que no quiero un "gráfico orientado mesa" y similares. Sin embargo, aquí está alguna información sobre la traducción automática de RDBMS a graphdb.

modelos de datos explícitos: Sí. Estas todo el (estilo de pizarra) el tiempo, y luego usar el modelo, ya que está en la base de datos, así

La señorita de RDBMS mundo: formas sencillas para crear informes. Actualización: tal vez no es que duro para crear informes a partir de una base de datos gráfica, consulte Creación de un informe de una base de datos de la muestra Neo4J .

Answer 2

Recién comencé con bases de datos no relacionales y todavía estoy tratando de entenderlo y descubrir cuál sería el mejor modelo.Y sólo puedo hablar en nombre de CouchDB.

Aún así, tengo algunas conclusiones preliminares:

¿Se te han ocurrido 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 (correspondientes a las consultas).

La base de datos de documentos intercambia 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 puede recuperarse fácilmente mediante identificación.Para cualquier otra consulta, escriba "vistas", que son conjuntos denominados 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 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" u "obtener rango de claves".)

La analogía más cercana en el mundo 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.Sólo he encontrado dos restricciones:

• Mantenga los datos relacionados juntos en un mismo documento, ya que no hay nada correspondiente 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 durante el año en el mismo documento), ya que cada actualización del documento desencadena una reindexación.

Pero todo depende del diseño de las vistas.

Los diseños alternativos que he descubierto que funcionan mucho mejor con CouchDB que con cualquier base de datos SQL están en el nivel del sistema en lugar del nivel de almacenamiento.Si tienes algunos datos y quieres servirlos en una página web, la complejidad del sistema total se reduce al menos en un 50%:

• sin diseñar tablas de base de datos (problema menor)
• sin capa intermedia ODBC/JDBC, todas las consultas y transacciones a través de http (problema moderado)
• Mapeo simple de base de datos a objetos desde JSON, que es casi trivial en comparación con el mismo en SQL (¡importante!)
• potencialmente puede omitir todo el servidor de aplicaciones, ya que puede diseñar sus documentos para que el navegador los recupere directamente usando AJAX y agregar un poco de pulido de JavaScript antes de que se muestren como HTML. (¡¡ENORME!!)

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 algo de 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.Mapear/reducir como medio para 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 al especificar 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 uniones ni otros tipos de relaciones entre múltiples 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.Arreglar: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, p.traducir de uno a otro?

No estoy seguro de que eso sea factible.Es más bien 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 verlo es mirar su SQL en busca de 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.

Eso es:Un documento para Pedido, que contiene el ID del cliente y el ID del 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 ser realizada por el cliente.Entonces, si desea un informe de ventas por región, probablemente debería ingresar un código de región en el pedido.

¿Incluso haces modelos de datos explícitos ahora (p. ej.en UML)?

Lo siento, tampoco hice mucho UML antes de las bases de datos de documentos :)

Pero necesita algún tipo de modelo que indique 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 la base de datos conozcan las convenciones.Dado que ya no recibe 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 trabajas con recursos externos.

¿Echas 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.Por lo tanto, nos costó menos trabajo sacar la funcionalidad del RDBMS.Esto incluso se extendió a la búsqueda de texto completo.

Entonces, cualquier cosa a la 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 intento 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 correspondan mejor con SQL que con el modelo de documento, por lo que imagino que SQL sobrevivirá.

Pero para aquellos de nosotros que sólo 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.

Answer 3

Estoy respondiendo esto con CouchDB en el fondo de mi mente, pero yo presumiría más sería cierto para otros DBs también. Nos fijamos en el uso de CouchDB, pero al final decidimos no hacerlo ya que nuestro acceso a los datos no se conoce de antemano y escalabilidad no es el problema.

Harder:

• Toma replantear el nivel conceptual por lo que es 'más duro', ya que es simplemente diferente. Puesto que usted tiene que saber sus patrones de acceso de datos de antelación, ninguna traducción automática puede ser aplicado. Usted tendría que añadir el patrón de acceso a por lo menos.
• La coherencia no es manejado por la base de datos, sino que debe ser tratado en la aplicación. Menos garantías significa una migración más fácil, fail-over y una mejor escalabilidad a costa de una aplicación más complicada. Una aplicación tiene que lidiar con los conflictos e inconsistencias.
• Enlaces qué documentos transversales (o clave / valor) tienen que ser tratados con el nivel de aplicación también.
Tipo
• SQL de bases de datos tienen entornos de desarrollo que son mucho más maduro. Se obtiene una gran cantidad de bibliotecas de soporte (aunque la superposición de las bibliotecas de hacer las cosas mucho más complejo de lo necesario para SQL).

Más fácil:

• más rápido si conoce sus patrones de acceso a datos.
• Migración / Fail-over es más fácil para la base de datos ya que no se hacen promesas a usted como un programador de aplicaciones. Aunque se obtiene la consistencia eventual. Probablemente. Finalmente. Algún tiempo.
• Una clave / valor es mucho más fácil de entender de una fila de una tabla. Todas las relaciones (de árboles) ya están en, y los objetos completos pueden ser reconocidos.

El modelado debe ser aproximadamente la misma, pero hay que tener cuidado con lo que se pone en un solo documento:. UML también se puede utilizar tanto para el modelado orientado a objetos, así como el modelado DB, que son dos animales diferentes ya

Me hubiera gustado ver una buena base de datos OO abierta muy bien integrado con C # / Silverlight. Sólo para hacer la elección aún más difícil. :)

Answer 4

Los archivos planos han sido considerados arcano y poco práctico para un conjunto de datos de cualquier tamaño. Sin embargo, un equipo más rápido con más memoria hacen que sea posible cargar un archivo en la memoria y ordenarla en tiempo real, al menos para las aplicaciones locales, de un único usuario razonablemente pequeño y n.

Por ejemplo, generalmente se puede leer un archivo de 10.000 registros y ordenarla en un campo en menos de medio segundo, un tiempo de respuesta aceptable.

Por supuesto, hay razones para utilizar una base de datos en lugar de un archivo plano - operaciones relacionales, integridad de datos, un sistema multiusuario, que da acceso a distancia, mayor capacidad, la normalización, etc., pero el aumento de la capacidad de la velocidad del ordenador y la memoria han hecho en la manipulación de los datos -Memoria más práctico en algunos casos.

Answer 5

Las bases de datos relacionales que veo en la vida real tienden a ser no muy bien normalizado en absoluto, al contrario de su reclamo. Cuando se les preguntó, los diseñadores me dicen que es sobre todo debido a rendimiento. RDBMs no son buenos en la unión, así que las mesas tienden a ser demasiado amplia, desde el punto de vista de la normalización. bases de datos orientadas a objetos tienden a ser mucho mejor en esto.

Otro punto en el que RDBMs tienen problemas es el manejo de las teclas de historia / dependientes del tiempo.