Comparación de bases de datos relacionales y bases de datos de gráficos

90

¿Alguien puede explicarme las ventajas y desventajas de una base de datos de relaciones como MySQL en comparación con una base de datos de gráficos como Neo4j?

En SQL tiene varias tablas con varios identificadores que las vinculan. Entonces tienes que unirte para conectar las tablas. Desde la perspectiva de un novato, ¿por qué diseñaría la base de datos para requerir una combinación en lugar de tener las conexiones explícitas como bordes desde el principio, como con una base de datos de gráficos? Conceptualmente, no tendría sentido para un novato. ¿Presumiblemente hay una razón muy técnica pero no conceptual para esto?

sql  relational-database  graph-databases 
— user782220
fuente
Los métodos de acceso son diferentes. En una base de datos relacional, utiliza álgebra relacional , mejor aumentada con recursividad, una representación extraña pero popular de la cual es (recursiva, con extras de procedimiento) SQL. En una base de datos de gráficos, utiliza lenguajes transversales de gráficos como Gremlin . Las implementaciones de base de datos subyacentes hasta el diseño en disco se elegirían para proporcionar el mejor rendimiento para el método de acceso respectivo, y se pueden encontrar ajustes / variaciones arbitrarios en las implementaciones.
— David Tonhofer

Respuestas:

115

De hecho, hay un razonamiento conceptual detrás de ambos estilos. Wikipedia sobre el modelo relacional y las bases de datos de gráficos ofrece una buena descripción general de esto.

La principal diferencia es que en una base de datos de gráficos, las relaciones se almacenan en el nivel de registro individual, mientras que en una base de datos relacional, la estructura se define en un nivel superior (las definiciones de la tabla).

Esto tiene importantes ramificaciones:

  • Una base de datos relacional es mucho más rápida cuando se opera con una gran cantidad de registros. En una base de datos gráfica, cada registro debe examinarse individualmente durante una consulta para determinar la estructura de los datos, mientras que esto se conoce de antemano en una base de datos relacional.
  • Las bases de datos relacionales utilizan menos espacio de almacenamiento, porque no tienen que almacenar todas esas relaciones.

El almacenamiento de todas las relaciones a nivel de registro individual solo tiene sentido si va a haber mucha variación en las relaciones; de lo contrario, está duplicando las mismas cosas una y otra vez. Esto significa que las bases de datos de gráficos son adecuadas para estructuras complejas e irregulares. Pero en el mundo real, la mayoría de las bases de datos requieren estructuras regulares relativamente simples. Por eso predominan las bases de datos relacionales.

— dan1111
fuente
16
El almacenamiento de relaciones a nivel de registro también tiene sentido en otros casos, ya que proporciona adyacencia sin índice. Es decir, se pueden realizar recorridos de gráficos sin búsquedas de índices que conduzcan a un rendimiento mucho mejor. Y no es una duplicación, ya que almacena las relaciones reales, que difieren.
— Nawroth
4
Usted dice: "En una base de datos gráfica, cada registro debe examinarse individualmente durante una consulta para determinar la estructura de los datos". ¿Es esta una propiedad universal de las bases de datos de gráficos o más o menos cierta en general? ¿Qué hay de OrientDb que admite un esquema completo para vértices y bordes?
— Lodewijk Bogaards
@LodewijkBogaards Algunas bases de datos de gráficos, como Neo4j, permiten la indexación básica. Si la consulta llega a los índices, creo que no es necesario determinar la estructura de los datos detrás del índice. Pero depende de la consulta.
— Vojtěch Vít
3
Estoy totalmente en desacuerdo con ambos puntos. La base de datos de gráficos siempre es más rápida cuando hay claves externas. Porque no necesitamos operaciones de unión. Las bases de datos relacionales deben almacenar la clave externa en muchas tablas. Un borde y una clave externa deben ocupar el mismo espacio de almacenamiento.
— cegprakash
3
@cegprakash ¿Tiene también una documentación de la que también podamos concluir lo mismo?
— Victor
102

La diferencia clave entre un gráfico y una base de datos relacional es que las bases de datos relacionales funcionan con conjuntos, mientras que las bases de datos de gráficos funcionan con rutas.

Esto se manifiesta de formas inesperadas y poco útiles para un usuario de RDBMS. Por ejemplo, cuando se intenta emular operaciones de ruta (por ejemplo, amigos de amigos) uniéndose de forma recursiva a una base de datos relacional, la latencia de las consultas crece de forma impredecible y masiva al igual que el uso de la memoria, sin mencionar que tortura a SQL para expresar ese tipo de operaciones. Más datos significa más lento en una base de datos basada en conjuntos, incluso si puede retrasar el dolor mediante una indexación juiciosa.

Como insinuó Dan1111, la mayoría de las bases de datos de gráficos no sufren este tipo de problemas de unión porque expresan relaciones en un nivel fundamental. Es decir, las relaciones existen físicamente en el disco y se nombran, dirigen y pueden decorarse ellas mismas con propiedades (esto se denomina modelo de gráfico de propiedades, consulte: https://github.com/tinkerpop/blueprints/wiki/Property-Graph -Modelo ). Esto significa que si lo desea, puede mirar las relaciones en el disco y ver cómo se "unen" a las entidades. Por lo tanto, las relaciones son entidades de primera clase en una base de datos de grafos y son semánticamente mucho más fuertes que las relaciones implícitas cosificadas en tiempo de ejecución en una tienda relacional.

Así que, por que deberías preocuparte? Por dos razones:

  1. Las bases de datos gráficas son mucho más rápidas que las bases de datos relacionales para datos conectados, una de las fortalezas del modelo subyacente. Una consecuencia de esto es que la latencia de la consulta en una base de datos de gráficos es proporcional a la cantidad del gráfico que elige explorar en una consulta y no es proporcional a la cantidad de datos almacenados, desactivando así la bomba de combinación .
  2. Las bases de datos de gráficos hacen que el modelado y las consultas sean mucho más agradables, lo que significa un desarrollo más rápido y menos momentos WTF. Por ejemplo, expresar amigo de amigo para una red social típica en el lenguaje de consulta Cypher de Neo4j es justo MATCH (me)-[:FRIEND]->()-[:FRIEND]->(foaf) RETURN foaf.
— Jim Webber
fuente
3
"Las relaciones son, por tanto, entidades de primera clase en una base de datos gráfica". Lo mismo ocurre normalmente en una base de datos relacional: las entidades se asignan a tuplas en las relaciones, al igual que las relaciones muchos-muchos. ¿Es la distinción que describe para las relaciones uno-muchos, que a menudo se fusionan en relaciones de entidad?
— beldaz
52
Esta comparación parece un poco sesgada. ¿Qué pasa con los inconvenientes?
— Kurren
9
¿Un poco? Demasiado parcial en mi sincera opinión. Parece un anuncio de "¡Este es un buen producto! Cómpreme este" en el mejor de los casos.
— ilgaar
37
Esto necesita una advertencia masiva : este tipo es el "científico jefe" de Neo Technology, quien crea la base de datos de gráficos de Neo4J.
— Rob Grant
4
¿Qué tal una búsqueda arbitraria ... dame todos los usuarios que tienen entre 35 y 55 años y compran en Walmart en los últimos 90 días?
— Matthew Whited
20

Dan1111 ya ha dado una respuesta marcada como correcta. Vale la pena señalar un par de puntos adicionales de pasada.

En primer lugar, en casi todas las implementaciones de bases de datos de gráficos, los registros se "fijan" porque hay un número desconocido de punteros que apuntan al registro en su ubicación actual. Esto significa que un registro no se puede barajar a una nueva ubicación sin dejar una dirección de reenvío en la ubicación anterior o sin romper un número desconocido de punteros.

Teóricamente, uno podría barajar todos los registros a la vez y encontrar una forma de localizar y reparar todos los punteros. En la práctica, esta es una operación que podría llevar semanas en una base de datos de gráficos grande, tiempo durante el cual la base de datos debería estar fuera del aire. Simplemente no es factible.

Por el contrario, en una base de datos relacional, los registros se pueden reorganizar a una escala bastante grande y lo único que se debe hacer es reconstruir los índices que se hayan visto afectados. Esta es una operación bastante grande, pero no tan grande como el equivalente para una base de datos de gráficos.

El segundo punto que vale la pena señalar de pasada es que la World Wide Web puede verse como una gigantesca base de datos de gráficos. Las páginas web contienen hipervínculos y los hipervínculos hacen referencia, entre otras cosas, a otras páginas web. La referencia es a través de URL, que funcionan como punteros.

Cuando una página web se mueve a una URL diferente sin dejar una dirección de reenvío en la URL anterior, se romperá un número desconocido de hipervínculos. Estos enlaces rotos dan lugar al temido mensaje "Error 404: página no encontrada" que interrumpe el placer de tantos internautas.

— Walter Mitty
fuente
4
Solo que la mayoría de las bases de datos de gráficos tienen reglas de integridad que no permiten enlaces rotos.
— Michael Hunger
1
Si el DBMS fija el objetivo, esto obviamente evitará la rotura del enlace debido al movimiento del objetivo del enlace. No conozco ninguna base de datos de gráficos que no fije registros que puedan ser objetivos de enlaces.
— Walter Mitty
¿Las bases de datos de gráficos generalmente no tienen esquema porque un cambio de esquema sería una operación muy pesada debido a la necesidad de volver a escribir todos los punteros? ¿No se puede eludir el problema de reorganización simplemente almacenando punteros virtuales, que pasan por una tabla de búsqueda? Esto todavía funcionaría en O (1) ¿verdad?
— Lodewijk Bogaards
He estado operando bajo una definición de bases de datos gráficas que incluirían bases de datos pre-relacionales como las jerárquicas o de red. Algunas de estas bases de datos tenían esquemas, aunque no esquemas relacionales. No estoy seguro de si mi definición operativa concuerda o no con la definición estándar.
— Walter Mitty
Una estructura de datos que proporciona un mapeo entre punteros virtuales y punteros físicos es esencialmente lo mismo que un índice, con aproximadamente los mismos costos. También puede seguir adelante y utilizar una base de datos relacional.
— Walter Mitty
7

Con una base de datos relacional, podemos modelar y consultar un gráfico mediante el uso de claves externas y autouniones. El hecho de que los RDBMS contengan la palabra relacional no significa que sean buenos para manejar las relaciones. La palabra relacional en RDBMS proviene del álgebra relacional y no de la relación. En un RDBMS, la relación en sí misma no existe como un objeto por derecho propio. Debe representarse explícitamente como una clave externa o implícitamente como un valor en una tabla de enlaces (cuando se usa un enfoque de modelado genérico / universal). Los enlaces entre conjuntos de datos se almacenan en los propios datos.

Cuanto más aumentamos la profundidad de búsqueda en una base de datos relacional, más autouniones necesitamos realizar y más se ve afectado el rendimiento de nuestras consultas. Cuanto más profundizamos en nuestra jerarquía, más tablas necesitamos unir y más lenta se vuelve nuestra consulta. Matemáticamente, el costo crece exponencialmente en una base de datos relacional. En otras palabras, cuanto más complejas se vuelven nuestras consultas y relaciones, más nos beneficiamos de un gráfico en comparación con una base de datos relacional. No tenemos problemas de rendimiento en una base de datos de gráficos cuando navegamos por el gráfico. Esto se debe a que una base de datos gráfica almacena las relaciones como objetos separados. Sin embargo, el rendimiento de lectura superior tiene el costo de escrituras más lentas.

En determinadas situaciones, es más fácil cambiar el modelo de datos en una base de datos gráfica que en un RDBMS, por ejemplo, en un RDBMS si cambio la relación de una tabla de 1: n am: n Necesito aplicar DDL con tiempo de inactividad potencial.

RDBMS tiene, por otro lado, ventajas en otras áreas, por ejemplo, la agregación de datos o el control de versiones con marcas de tiempo en los datos.

Discuto algunos de los otros pros y contras en mi publicación de blog sobre bases de datos gráficas para almacenamiento de datos

— Uli Bethke
fuente
4

Si bien el modelo relacional puede representar fácilmente los datos contenidos en un modelo de gráfico, en la práctica nos enfrentamos a dos problemas importantes:

  1. SQL carece de la sintaxis para realizar fácilmente recorridos de gráficos, especialmente recorridos donde la profundidad es desconocida o ilimitada. Por ejemplo, usar SQL para determinar los amigos de sus amigos es bastante fácil, pero es difícil resolver el problema de los "grados de separación".
  2. El rendimiento se degrada rápidamente a medida que recorremos el gráfico. Cada nivel de recorrido aumenta significativamente el tiempo de respuesta de la consulta.

Referencia: bases de datos de próxima generación

— Mohammad Akbari
fuente
0

Vale la pena investigar las bases de datos de gráficos por los casos de uso en los que se destacan, pero he tenido alguna razón para cuestionar algunas afirmaciones en las respuestas anteriores. En particular:

Una base de datos relacional es mucho más rápida cuando se opera con una gran cantidad de registros (el primer punto de dan1111)

Las bases de datos de gráficos son mucho más rápidas que las bases de datos relacionales para datos conectados, una de las fortalezas del modelo subyacente. Una consecuencia de esto es que la latencia de la consulta en una base de datos de gráficos es proporcional a la cantidad de gráfico que elige explorar en una consulta y no es proporcional a la cantidad de datos almacenados, desactivando así la bomba de combinación. (Primera viñeta de Jim Webber)

En otras palabras, cuanto más complejas se vuelven nuestras consultas y relaciones, más nos beneficiamos de un gráfico en comparación con una base de datos relacional. (Segundo párrafo de Uli Bethke)

Si bien estas afirmaciones pueden tener mérito, todavía tengo que encontrar una manera de alinear mi caso de uso específico con ellas. Referencia: Base de datos de gráficos o Base de datos relacional Extensiones de tabla común: Comparación del rendimiento de consultas de gráficos acíclicos

— usuario3105510
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.