sql - relacionales - ¿Cómo es una base de datos de gráficos diferente a un gráfico representado en una base de datos relacional?

estructura de una base de datos relacional (1)

¿Es uno un subconjunto del otro?

Definitivamente no; ambos son modelados en los conceptos matemáticos de relaciones o gráficos. Ambos modelos son super generales, básicamente no hay contenido de información que no se puede representar utilizando cualquiera de los dos. Esto significa que si bien pueden diferir en muchas formas sintácticas de azúcar, y en la forma en que lo alientan a modelar / pensar en los datos (al igual que los lenguajes de programación difieren) ambos tienen el mismo "poder expresivo".

Lo que describes en tu pregunta es una forma de modelar un gráfico (tablas de vertex y edge ). Esa implementación de un gráfico es un subconjunto de lo que relacional puede expresar. Del mismo modo, podría simular tablas y filas utilizando una base de datos de gráficos, pero habría elegido una implementación particular: esto no demostraría que los datos relacionales son un subconjunto de datos de gráficos.

Entonces, la primera percepción es que tienen aproximadamente el mismo poder expresivo. Puedes modelar cualquier cosa en cualquiera de los dos. Entonces, la verdadera pregunta que debes hacerte es ¿por qué elegirías una sobre la otra?

¿Por qué elegirías uno sobre el otro?

Todas las bases de datos existen para facilitar el acceso a los datos. En pocas palabras, lo almacena para que pueda obtener los datos. ¿Pero exactamente cómo necesita obtener los datos? Hay muchos patrones de acceso diferentes. El espacio de diseño para las bases de datos en general es enorme . Cada vez que una base de datos toma una decisión determinada, tiende a mejorarla automáticamente en algunas cosas, peor en otras. Por ejemplo, cuando crea un índice en una base de datos relacional, acaba de acelerar las lecturas, pero ha degradado el rendimiento de las escrituras, porque el índice debe mantenerse.

Entonces, cuando nos acercamos a la pregunta, ¿Gráfico o Relacional? - primero debe averiguar cómo son sus datos y cómo son sus patrones de acceso a datos. Si supiera cuáles son esas cosas, entonces podría evaluar un conjunto de bases de datos, ver las elecciones que han realizado y elegir la que mejor se adapte a sus necesidades. Y luego, si un DBMS tomó una decisión que haría que ciertos patrones de acceso fueran difíciles, problemáticos o lentos, podría evitar ese DBMS para ese conjunto de datos.

Es (en parte) sobre los patrones de acceso a los datos

Las bases de datos de gráficos tienden a ser mejores que las relacionales cuando los datos que se almacenan son gráficos, cuando el patrón de acceso a los datos implica una gran cantidad de cruces de gráficos, o ambos. ( Vea esta otra respuesta que escribí para una discusión más profunda de por qué esto es). Ese enlace también proporciona la respuesta a su pregunta específica: " ¿Una base de datos de gráficos estructura su almacenamiento, u optimiza sus consultas, de alguna manera que proporciona características de rendimiento que no se pueden obtener de una base de datos relacional? "

Usted dice: puedo consultar este gráfico usando SQL, con subconsultas recursivas si es necesario y con múltiples consultas separadas en una transacción si es necesario. - Así que, técnicamente, esto es cierto, pero tomemos un ejemplo para ver por qué la relación puede no ser lo suficientemente buena. Digamos que tengo un gráfico (en RDBMS, una tabla de nodos, una tabla de bordes, con una clave de combinación entre ellos). Digamos que selecciono un nodo y quiero identificar todo lo que está entre 6 y 8 saltos de ese nodo. Aquí está la cifra para hacer eso:

match (myChosenNode {id: ''foo''})-[r:relationshipType*6..8]->(y) return y;

Realmente quiero verte escribir eso como SQL. Es posible, pero es difícil y complicado . Y también funcionará como un perro, debido a la gran cantidad de unión que estará haciendo en cantidades no triviales de datos.

ÁCIDO

Ahora bien, con las garantías de ACID, Neo4J ofrece transacciones con garantías de ACID . Sin embargo, la respuesta será diferente para diferentes bases de datos de gráficos, particularmente las implementadas sobre Hadoop / HBase. YMMV allí, entonces verifique la letra pequeña con cada base de datos.

Es cierto que hay una serie de funciones de RDBMS que normalmente no encontrará en las bases de datos de gráficos, por ejemplo, desencadenantes y ciertos tipos de restricciones. Como nerd de RDMBS desde hace mucho tiempo, no estoy tan contento con las cosas que faltan, creo que son valiosas.

Resumen

Lo que esto se reduce a mí, y muchos otros ingenieros con los que trabajo son:

¿Cuál es tu información?
¿Cuáles son tus patrones de acceso?

Si sus datos son un gráfico, o sus patrones de acceso implican mucho cruce de gráficos, probablemente debería usar un gráfico DB. Si sus datos son más tabú, o sus patrones de acceso están más orientados en escaneos masivos, entonces debe usar RDBMS. Al final del día, son dos herramientas diferentes con nichos diferentes. Si los usas en su área de fuerza, serás feliz. Si usa RDBMS para modelar un gráfico simplemente "porque puede", sufrirá. Si usa una base de datos de gráficos para hacer muchos escaneos a granel de cada nodo en cada gráfico, sufrirá. Como la mayoría de la tecnología, solo se trata de usar la herramienta adecuada para el trabajo.

Puedo representar un gráfico trivialmente en una base de datos relacional con dos tablas: vertex y edge . Una estructura más rica como "propiedades" y "etiquetas" (en la terminología Neo4j) se puede representar como más tablas. ¿He entendido mal, o una base de datos de gráficos como Neo4j me permite representar cualquier cosa que no sea fácilmente representable relacionalmente?

Puedo consultar este gráfico usando SQL, con subconsultas recursivas si es necesario y con múltiples consultas separadas en una transacción si es necesario. ¿He entendido mal, o un lenguaje de consulta de gráficos como Cypher proporciona una mayor expresividad que SQL?

El modelo relacional de un gráfico se almacena y consulta de manera eficiente, AFAIK. ¿Una base de datos de gráficos estructura su almacenamiento, u optimiza sus consultas, de alguna manera que proporciona características de rendimiento que no se pueden obtener de una base de datos relacional?

Mi base de datos relacional proporciona garantías de ACID, y me permite escribir restricciones bastante expresivas sobre los datos de mi gráfico (y aún más restricciones si vertex tabla de vertex simple en un esquema correctamente normalizado). ¿He entendido mal o una base de datos de gráficos proporciona algunas garantías o verifica algún tipo de propiedades de corrección que no están disponibles en mi base de datos relacional?

Estoy luchando para ver cómo una base de datos de gráficos como Neo4j no es más que un subconjunto del modelo relacional. (Disculpas por usar Neo4j como representante de todas las bases de datos de gráficos aquí, es el único que he visto).

En resumen: ¿la base de datos de gráficos ⊆ es una base de datos relacional?