¿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
fuente
Respuestas:
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:
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.
fuente
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:
MATCH (me)-[:FRIEND]->()-[:FRIEND]->(foaf) RETURN foaf.fuente
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.
fuente
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
fuente
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:
Referencia: bases de datos de próxima generación
fuente
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
fuente