practicar - script de base de datos sql ejemplos

Comparación de bases de datos relacionales y bases de datos de gráficos (4)

¿Puede alguien 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 los vinculan. Luego debes unirte para conectar las tablas. Desde la perspectiva de un novato, ¿por qué diseñaría la base de datos para requerir una unió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?

Con una base de datos relacional, podemos modelar y consultar un gráfico mediante el uso de claves externas y autocombinaciones. El hecho de que RDBMS ''contenga 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 en sí mismo. O bien debe representarse explícitamente como una clave externa o implícitamente como un valor en una tabla de enlace (cuando se utiliza un enfoque de modelado genérico / universal). Los enlaces entre los conjuntos de datos se almacenan en los datos en sí.

Cuanto más aumentemos la profundidad de búsqueda en una base de datos relacional, más auto-uniones necesitamos realizar y más sufre nuestro rendimiento de consulta. Cuanto más profundizamos en nuestra jerarquía, más tablas necesitamos unir y más lenta es nuestra consulta. Matemáticamente, el costo crece exponencialmente en una base de datos relacional. En otras palabras, cuanto más complejas sean nuestras consultas y relaciones, más nos beneficiaremos de un gráfico frente a 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 de gráficos almacena las relaciones como objetos separados. Sin embargo, el rendimiento superior de lectura tiene el costo de las escrituras más lentas.

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

RDBMS tiene, por otro lado, ventajas en otras áreas, p. Ej., Agregar datos o hacer un control de versión con marca de tiempo en los datos.

Discuto algunos de los otros pros y contras en mi blog de bases de datos de gráficos para el almacenamiento de datos

Dan1111 ya ha dado una respuesta marcada como correcta. Un par de puntos adicionales valen la pena mencionar de pasada.

En primer lugar, en casi todas las implementaciones de bases de datos de gráficos, los registros están "anclados" porque hay un número desconocido de punteros que apuntan al registro en su ubicación actual. Esto significa que no se puede barajar un registro en una nueva ubicación sin dejar una dirección de reenvío en la ubicación anterior o 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 gran base de datos de gráficos, y durante ese tiempo 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 en una escala bastante grande, y lo único que se debe hacer es reconstruir cualquier índice que se haya visto afectado. Esta es una operación bastante grande, pero no es tan grande como el equivalente de una base de datos de gráficos.

El segundo punto que vale la pena mencionar de pasada es que la red mundial se puede ver como una gigantesca base de datos de gráficos. Las páginas web contienen hipervínculos e hipervínculos que 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 rompe una cantidad desconocida de hipervínculos. Estos enlaces rotos dan lugar al temido mensaje "Error 404: página no encontrada" que interrumpe el placer de tantos internautas.

En realidad hay un razonamiento conceptual detrás de ambos estilos. Wikipedia en el modelo relacional y las bases de datos de gráficos ofrece buenas descripciones de esto.

La principal diferencia es que en una base de datos de gráfico, 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 tabla).

Esto tiene ramificaciones importantes:

Una base de datos relacional es mucho más rápida cuando se trabaja con un gran número de registros. En una base de datos de gráficos, cada registro debe examinarse individualmente durante una consulta para determinar la estructura de los datos, mientras que esto se conoce con anticipación en una base de datos relacional.
Las bases de datos relacionales usan menos espacio de almacenamiento, porque no tienen que almacenar todas esas relaciones.

Almacenar todas las relaciones en el nivel de registro individual solo tiene sentido si va a haber mucha variación en las relaciones; de lo contrario, solo 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 y relativamente simples. Esta es la razón por la cual las bases de datos relacionales predominan.

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 en formas inesperadas e inútiles para un usuario de RDBMS. Por ejemplo, al intentar emular operaciones de ruta (por ejemplo, amigos de amigos) al unirse recursivamente en una base de datos relacional, la latencia de consulta crece de forma impredecible y masiva como lo hace el uso de memoria, sin mencionar que tortura SQL para expresar ese tipo de operaciones. Más datos significan más lentos en una base de datos basada en conjuntos, incluso si puede retrasar el dolor a través de una indexación juiciosa.

Como Dan1111 insinuó, la mayoría de las bases de datos de gráficos no sufren este tipo de dolor de unión porque expresan relaciones en un nivel fundamental. Es decir, las relaciones existen físicamente en el disco y se nombran, se dirigen y se pueden decorar con propiedades (esto se llama modelo de gráfico de propiedades, consulte: https://github.com/tinkerpop/blueprints/wiki/Property-Graph-Model ). Esto significa que si así lo desea, podría ver las relaciones en el disco y ver cómo se "unen" las entidades. Las relaciones son, por lo tanto, entidades de primera clase en una base de datos de gráficos y semánticamente mucho más sólidas que las relaciones implícitas reificadas en el tiempo de ejecución en un almacén relacional.

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

Las bases de datos de gráficos son mucho más rápidas que las bases de datos relacionales para datos conectados, una fortaleza del modelo subyacente. Una consecuencia de esto es que la latencia de consulta en una base de datos de gráfico es proporcional a la cantidad de gráfico que elige explorar en una consulta, y no es proporcional a la cantidad de datos almacenados, lo que desactiva la bomba de unión .
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 de WTF. Por ejemplo, expresar friend-of-friend para una red social típica en el lenguaje de consulta Cypher de Neo4j es simplemente MATCH (me)-[:FRIEND]->()-[:FRIEND]->(foaf) RETURN foaf .