Universidad ORT Uruguay
Facultad de Ingenier´ıa
Estudio del estado del arte en bases de datos orientadas a grafos
Entregado como requisito para la obtenci´ on del t´ıtulo de Licenciatura en Ingenier´ıa de Software
Miguel Nu˜ nez (191877)
Tutores: Juan Gabito, Sergio Yovine
2021
Declaraciones de autor´ıa
Miguel Nu˜nez el autor de esta obra, declaro que el trabajo que se presenta en esta obra es de mi propia mano. Puedo asegurar que:
La obra fue producida en su totalidad mientras realizaba el Trabajo integrador;
Cuando he consultado el trabajo publicado por otros, lo he atribuido con claridad;
Cuando he citado obras de otros, he indicado las fuentes. Con excepci´on de estas citas, la obra es enteramente m´ıa;
En la obra, he acusado recibo de las ayudas recibidas;
Cuando la obra se basa en trabajo realizado conjuntamente con otros, he explicado claramente qu´e fue contribuido por otros, y qu´e fue contribuido por mi;
Ninguna parte de este trabajo ha sido publicada previamente a su entrega, excepto donde se han realizado las aclaraciones correspondientes.
Miguel Nu˜nez
26/07/2021
Agradecimientos
A mi familia por el apoyo y la paciencia que me han brindado d´ıa a d´ıa para alcanzar una de las metas propuestas.
A mi amigo Eduardo, quien directa o indirectamente ha influido en mis decisio- nes, ya sea con una pl´atica o con el ejemplo de sus acciones.
A compa˜neros y compa˜neras con quienes hemos ido caminando juntos y mutua- mente nos hemos apoyado.
A los profesores por compartir todos sus conocimientos, paciencia y voluntad de explicar las veces necesario para comprender el tema, para que pueda crecer tanto en el ´ambito personal como en el profesional.
A mis tutores y gu´ıa acad´emico que me han trasmitido sus conocimientos para seguir adelante.
Abstract
En este trabajo de tesis se muestran las denominadas bases de datos orientada a grafos (BDoG) y para comprender el contexto se hace una introducci´on a grafos, sus propiedades y tipos de grafos para despu´es profundizar en las BDoG.
Otro aspecto trabajado son las comparaciones de motores de bases de datos orientadas a grafos contra bases de datos relacionales, comparando consultas com- plejas y el armado del modelado. En efecto el modelado y algunos tipos de consultas se pueden volver complejos en el mundo relacional mientras que en las BDoG se da de forma natural.
Tambi´en se brinda una gu´ıa para decidir cu´ando utilizar una BDoG con simples preguntas y tambi´en resumidas en un ´arbol de decisi´on.
Adem´as se menciona diferentes tipos de gestores de base de datos orientadas a grafos cubriendo almacenamiento en disco, en la nube y en memoria. Para cada una se detallan la estructura de almacenamiento, el modelado de datos, manejo de transacciones, interfaces y lenguajes de consultas.
Sobre los lenguajes de consultas, se comparan los tres m´as populares de la ac- tualidad.
Finalmente se menciona el aprendizaje sobre grafos done se comentan cuatro t´ecnicas principales.
Palabras clave
grafo; base de datos orientada a grafos (BDoG); base de datos relacional (RDBMS);
SQL (Structured Query Language); NoSQL; Common Table Expressions (CTE); ti- pos de grafos; neo4j; ArangoDB; TerminusDB; Amazon Neptune; Cypher; Gremlin;
Sparql;
´ Indice general
1. Introducci´on 8
1.1. Contexto y motivaci´on . . . 8
1.2. Objetivos . . . 9
1.3. Estructura del documento . . . 9
2. Introducci´on a grafos 11 2.1. ¿Qu´e es un grafo? . . . 11
2.2. ¿Qu´e es una base de datos orientada a grafos (BDoG)? . . . 12
2.3. Comparaci´on con otros tipos de bases de datos . . . 13
2.4. ¿Por qu´e existen? . . . 14
3. Base de datos orientada a grafos vs base de datos relacional 16 3.1. Consultas recursivas . . . 18
3.1.1. Representaci´on con RDBMS . . . 19
3.1.2. Representaci´on con BDoG . . . 21
3.2. Diferentes tipos de resultados . . . 23
3.2.1. Representaci´on con RDBMS . . . 23
3.2.2. Representaci´on con BDoG . . . 24
3.3. Caminos . . . 25
3.4. Modelado BDoG . . . 26
4. Cu´ando usar BDoG 29 4.1. Selecci´on - b´usqueda . . . 29
4.2. Datos relacionados o recursivos . . . 30
4.3. Agregaci´on . . . 30
4.4. Coincidencia de patrones . . . 31
4.5. Centralidad, agrupaci´on e influencia . . . 31
4.6. Gu´ıa para decidir . . . 32
4.7. Algunos usos de la BDoG . . . 34
5. Tipos de grafos 36 5.1. Grafo no dirigido . . . 36
5.2. Grafo dirigido . . . 36
5.3. Grafo con peso o ponderado . . . 37
5.4. Grafo con etiquetas . . . 37
5.5. Grafo de propiedades . . . 38
5.6. Multigrafo . . . 38
6. Tipos de gestores de BDoG 39
6.1. Neo4j . . . 39
6.1.1. Modelo de datos . . . 39
6.1.2. Restricciones de integridad . . . 39
6.1.3. Manejo de transacciones . . . 40
6.1.4. Almacenamiento f´ısico de la estructura de datos . . . 40
6.1.5. Datos en cache . . . 43
6.2. ArangoDB . . . 45
6.2.1. Modelo de datos . . . 45
6.2.2. Restricciones de integridad . . . 45
6.2.3. Manejo de transacciones . . . 45
6.2.4. Almacenamiento f´ısico de la estructura de datos . . . 47
6.3. TerminusDB . . . 47
6.3.1. Modelo de datos . . . 48
6.3.2. Restricciones de integridad . . . 49
6.3.3. Manejo de transacciones . . . 49
6.3.4. Almacenamiento de la estructura de datos . . . 49
6.4. Amazon Neptune . . . 51
6.4.1. Modelo de datos . . . 52
6.4.2. Restricciones de integridad . . . 52
6.4.3. Manejo de transacciones . . . 54
6.4.4. Almacenamiento de la estructura de datos . . . 54
6.4.5. Almacenamiento distribuido . . . 55
7. Lenguajes de consultas BDoG 56 7.1. CYPHER vs GREMLIN vs SPARQL . . . 56
7.2. Ejemplo pr´actico . . . 58
7.2.1. Datos del modelo - COVID-19 . . . 59
7.2.2. Consultas . . . 60
8. Aprendizaje sobre grafo 63 8.1. Clasificaci´on de nodos . . . 63
8.2. Predicci´on de enlaces . . . 63
8.3. Detecci´on de comunidad . . . 63
8.4. Clasificaci´on de grafo . . . 64
8.5. Modelos de inteligencia artificial - aprendizaje autom´atico explicables 64 9. Conclusiones 66 10.Glosario 67 11.Anexo A 73 11.1. Datos de ejemplos - COVID-19 . . . 73
1. Introducci´ on
Los RDBMS han sido el paradigma que ha dominado el almacenamiento de datos en los sistemas que se han desarrollado durante los ´ultimos 40 a˜nos. Es un modelo bien fundado en bases matem´aticas que puede representarse f´acilmente usando al- goritmos computacionales, pero tambi´en lo hace muy r´ıgido.
Aun as´ı, hemos llegado a un punto en que seguir usando bases de datos relacio- nales para todos los casos es simplemente inviable.
En un mundo de constantes cambios a nivel de sistemas, donde los RDBMS no son flexibles, tambi´en por su naturaleza computacional se vio la necesidad de otras opciones para otros tipos de escenarios complejos.
Por lo que nace el movimiento NoSQL o tambi´en “No uses solo SQL”. Donde las categor´ıas m´as usadas de NoSQL son:
Bases de datos clave valor.
Bases de datos columnares.
Bases de datos orientadas a documentos.
Bases de datos orientadas a grafos (BDoG).
En este trabajo se profundizar´a en las bases de datos orientadas a grafos.
1.1. Contexto y motivaci´ on
En la actualidad hay un gran n´umero de BDoG con sus propios lenguajes de consultas y estructuras de almacenamiento.
Adem´as, en los grafos se puede observar que se consideran las relaciones (aris- tas) con lo cual las consultas que implican estas relaciones se pueden hacer de forma eficiente.
Teniendo en cuenta lo mencionado anteriormente, surgi´o la motivaci´on de pro- fundizar en algunos motores, como almacenan los datos, los tipos de grafos que soportan, las diferencias entre los lenguajes de consultas y sus ventajas contra los almacenamientos RDBMS.
1.2. Objetivos
1. Introducci´on a grafos.
2. Comparativa entre BDoG vs RDBMS.
3. Cuando utilizar BDoG.
4. Tipos de Grafos.
5. Lenguaje de consultas.
6. Aprendizaje sobre grafos.
1.3. Estructura del documento
Cap´ıtulo 1: Introducci´on
Este cap´ıtulo presenta el contexto y motivaci´on del trabajo con el alcance del mismo.
Cap´ıtulo 2: Introducci´on a grafos
El objetivo de este cap´ıtulo es relacionarse con los grafos y bases de datos orien- tadas a grafos. Tambi´en se compara contra otros motores de bases de datos.
Cap´ıtulo 3: Base de datos orientada a grafos vs base de datos relacional Se comparan los RDBMS contra la BDoG en sus accesos a b´usquedas: consultas recursivas, devolver diferentes tipos de resultados y caminos. Adem´as, la compara- tiva abarca el modelado en la pr´actica mostrando las ventajas del grafo.
Cap´ıtulo 4: Cu´ando usar BDoG
En este cap´ıtulo se brindan herramientas para identificar el uso de BDoG. Tam- bi´en se detalla un ´arbol de decisi´on para mejorar la elecci´on sobre la BDoG.
Cap´ıtulo 5: Tipos de grafos
El motivo de este cap´ıtulo es clasificar los tipos de grafos para reconocerlos en los diferentes motores de base de datos de grafos.
Cap´ıtulo 6: Tipos de gestores de BDoG
En este cap´ıtulo se mencionan algunos tipos de BDoG mostrando la estructura de almacenamiento. Tambi´en se menciona el manejo de las transacciones, el modelo
de datos, las interfaces y lenguaje de consultas.
Cap´ıtulo 7: Lenguajes de consultas BDoG
Este cap´ıtulo se centra en la comparativa de los lenguajes de consultas Cypher, Gremlin y Sparql con un ejemplo pr´actico de la actualidad.
Cap´ıtulo 8: Aprendizaje sobre grafo
En este cap´ıtulo se presentan distintas t´ecnicas de aprendizaje sobre grafos.
Cap´ıtulo 9: Conclusiones
En este cap´ıtulo se reflexiona las lecciones aprendidas durante el transcurso del trabajo.
2. Introducci´ on a grafos
Las aplicaciones modernas se basan en datos, datos que aumentan constantemen- te tanto en tama˜no como en complejidad. Incluso a medida que crece la complejidad de nuestros datos, tambi´en aumentan nuestras expectativas de la informaci´on que nuestras aplicaciones pueden derivar de esos datos.
2.1. ¿Qu´ e es un grafo?
Cuando miras una mapa de rutas o usas redes sociales como Facebook, Linke- dIn o Twitter, usas un grafo. Los grafos son una forma casi ubicua de pensar en escenarios del mundo real, ya que abstraen los elementos y las relaciones que se representan, y esta abstracci´on permite un procesamiento r´apido y eficiente de las conexiones dentro de los datos.
En los mapas, las ciudades se representan con frecuencia mediante c´ırculos, y las carreteras que las conectan se representan mediante l´ıneas. En una red social, las personas se conectan entre s´ı a trav´es de amigos o seguidores. Este proceso de generalizar entidades y las conexiones entre ellas es la base fundamental de los grafos y la teor´ıa de grafos. Debido a que los matem´aticos han definido y estudiado los grafos durante siglos, podemos ofrecer estas definiciones utilizadas en la teor´ıa de grafos:
Grafo: G = (V, A) donde V es un conjunto de v´ertices conectados por un conjunto de aristas A.
V´ertice: un punto en un gr´afico donde cero o m´as bordes se encuentran, tambi´en conocido como un nodo o una entidad.
Arista: una relaci´on entre dos v´ertices dentro de un gr´afico, a veces llamado relaci´on, enlace o conexi´on.
Si bien las definiciones son agradables, los grafos tienen la ventaja de ser simples de ilustrar. Al trabajar con grafos, los diagramas generalmente consisten en c´ırculos que representan v´ertices y l´ıneas que representan aristas.
Figura 2.1: Representaci´on de grafos con c´ırculos para los v´ertices y l´ıneas para las aristas
Los grafos no son conceptos nuevos para los desarrolladores de software. ´Estas son la base de muchas estructuras de datos comunes que usamos todo el tiempo, probablemente sin siquiera darnos cuenta. Las estructuras de datos comunes, como listas vinculadas y ´arboles, son simplemente tipos de grafos a los que se les apli- can reglas espec´ıficas. Si bien estas estructuras de datos son bien conocidas por los desarrolladores, los detalles reales de implementaci´on espec´ıficos de los grafos gene- ralmente se abstraen.
2.2. ¿Qu´ e es una base de datos orientada a grafos (BDoG)?
Es una base de datos que tiene como prop´osito almacenar estructuras de datos que tienen topolog´ıa de grafo, es decir, que la informaci´on que se almacena se puede representar por medio de v´ertices y aristas entre ellos.
Por definici´on, una BDoG agrupar´ıa a cualquier soluci´on de almacenamiento en la que los elementos que est´an conectados se enlazan sin hacer uso de una referencia por medio de ´ındices (que ser´ıa el m´etodo habitual de simular una relaci´on en una RDBMS), de esta forma, los vecinos de una entidad son accesibles directamente por ella por medio de una referencia directa, sin pasar por estructuras intermedias que hagan el proceso de referenciado.
En esta definici´on no tenemos en cuenta el tipo de grafo (en su sentido m´as amplio) que nuestros datos seguir´an, ni en el tipo de relaci´on (dirigidas o no), ni en la multiplicidad de las mismas entre dos v´ertices (unirelacional o multirelacional), ni en la aridad que reflejen las aristas (grafo o hipergrafo).
Por lo tanto, una BDoG cumple los siguientes criterios:
El almacenamiento est´a optimizado para que los datos sean repre- sentados como un grafo, con una disposici´on para almacenar v´ertices y aristas.
El almacenamiento est´a optimizado para el recorrido del grafo, sin usar un ´ındice al seguir las aristas. Una BDoG est´a optimizada para consultas aprovechando la proximidad de los datos, comenzando desde uno o varios v´ertices ra´ız, en lugar de consultas globales.
Modelo de datos flexible para algunas soluciones: no es necesario declarar tipos de datos para v´ertices o aristas, a diferencia del modelo orientado a tablas m´as restringido de una base de datos relacional.
API integrado con puntos de entrada para los algoritmos m´as cl´asicos de la teor´ıa de grafos.
Como punto final, las BDoG mejoran la productividad del desarrollador para ciertos problemas de una manera que otras tecnolog´ıas no pueden. Almacenar los datos de una manera que represente mejor a su contraparte del mundo real puede facilitar que los desarrolladores razonen y comprendan el dominio en el que est´an trabajando. Esto permite que los nuevos miembros del equipo se pongan al d´ıa m´as r´apidamente en el dominio. Aprenden el dominio y la representaci´on de su base de datos simult´aneamente.
2.3. Comparaci´ on con otros tipos de bases de datos
Debemos tener en cuenta que el mundo de las bases de datos no se limita a los tipos de almacenes de datos relacional o de grafo. En los t´erminos m´as amplios, una base de datos se puede clasificar como un tipo de motor en una de las cinco formas siguientes:
Clave-Valor: representa todos los datos mediante un identificador ´unico (una clave) y un objeto de datos asociado (el valor).
Columna ancha u orientada a columnas: almacena datos en filas con un potencial de una gran cantidad de columnas y/o de columnas variables en cada fila.
Documento: almacena datos en un documento con clave ´unica que puede tener diferentes esquemas y que puede contener datos anidados.
Relacional: almacena datos en tablas que contienen filas con un esquema estricto. Se pueden establecer relaciones entre tablas permitiendo la uni´on de filas.
Grafo: almacena datos como v´ertices (tambi´en conocida como nodos) y aristas (tambi´en conocida como relaciones).
Figura 2.2: Tipos de motor de base de datos ordenados por complejidad de datos, recuperado de [1]
En la Figura 2.2 se puede observar que solo las RDBMS y las BDoG, por defecto, incluyen la capacidad de relacionar entidades dentro de los datos. Puede ser posible hacerlo con implementaciones para el resto, pero esto suele ser una mejora agregada por la implementaci´on espec´ıfica de un proveedor.
2.4. ¿Por qu´ e existen?
Una de las formas para obtener los datos de un sistema es a trav´es de la base de datos relacional. Los RDBMS cuentan con el ´algebra relacional1 y con un lenguaje de consultas com´un para todas los fabricantes SQL (Structured Query Language)2. Esta forma de almacenar y obtener los datos se ve afectada con la aparici´on de la web 2.0, el desarrollo de software basado en navegadores web como tambi´en la llegada de nuevas aplicaciones, como redes sociales, ecommerce, donde cualquier usuario puede subir contenidos provocando as´ı un crecimiento exponencial de los datos.
1https://es.wikipedia.org/wiki/ %C3 %81lgebra relacional
2https://es.wikipedia.org/wiki/SQL
Dada la gran cantidad de datos sumado a problemas de escalabilidad y rendi- miento donde hay escritura de miles de usuarios concurrentes y con millones de consultas diarias surgi´o la necesidad de sistemas especifico apareciendo as´ı el movi- miento NoSQL3.
Las bases de datos NoSQL son sistemas de almacenamiento que no cumple el esquema entidad-relaci´on. Tampoco tienen el formato de tabla donde almacenan sus datos, hacen usos de otros formatos: clave-valor, mapeo de columnas, grafos.
Las relaciones existen en la base de datos relacionales, pero solo en el momento del modelado. En el momento de unir las tablas estas relaciones desaparecen y que- dan expresadas en restricciones de claves for´aneas4 para mantener la validez de los datos, pero no queda la relaci´on plasmada en el modelo f´ısico. De esta manera la gran mayor´ıa de consultas deben proyectar de varias tablas (JOIN) con estrategias diversas para obtener los datos. Para entender podemos explorar el ´arbol de ejecu- ci´on en una consulta SQL5.
A medida que los datos at´ıpicos se multiplican y la estructura general del con- junto de datos se vuelve mas compleja y menos uniforme, el modelo relaciona se sobrecarga con grandes tablas de combinaciones, filas escasamente pobladas y mu- chos campos nulos, nos impiden el rendimiento y dificultan la evoluci´on de una base de datos existente a respuestas de nuevas funcionalidades, cambios en el sistema.
Adem´as tanto los RDBMS como las NoSQL est´an pensadas para almacenar co- sas y no para entender como estas se relacionan entre si. Aqu´ı es donde el modelo orientado a grafos cobra sentido.
3https://es.wikipedia.org/wiki/NoSQL
4https://es.wikipedia.org/wiki/Clave for´anea
5https://slideplayer.es/slide/2747325/
3. Base de datos orientada a grafos vs base de datos relacional
Una BDoG es una buena opci´on para explorar datos estructurados como un gra- fo (o derivados como un ´arbol), en particular cuando las relaciones entre esos datos son tan significativas como los mismos datos. El caso ideal de una consulta ser´ıa comenzar por uno o varios v´ertices y ejecutar recorridos de grafos.
A pesar de sus nombres, las RDBMS est´an poco preparadas para explorar rela- ciones de forma masiva, en donde necesita, por regla general, usar claves for´aneas accediendo a tablas intermedias. En BDoG los recorridos se realizan siguiendo pun- teros f´ısicos, mientras que las claves externas son punteros l´ogicos.
Aunque el siguiente ejemplo es muy simple, muestra un escenario en el que el rendimiento de una BDoG es muy superior a la de una RDBMS. En ambos casos tenemos la misma informaci´on y pretendemos extraer todos los trabajadores de una determinada empresa. Por ejemplo, suponemos un caso para encontrar a todas las personas que trabajan en Google.
Con un modelo relacional podr´ıamos ejecutar la siguiente consulta, que proba- blemente necesitar´ıa 3 b´usquedas de ´ındice correspondientes a las claves externas del modelo.
Figura 3.1: Ejemplo Tablas Company, adaptado de [2], [3]
Figura 3.2: Ejemplo Tablas Company - SELECT, adaptado de [2], [3]
En el caso de un grafo, la consulta necesitar´a una b´usqueda de ´ındice, luego atravesar´a las relaciones desreferenciando punteros f´ısicos directamente.
Figura 3.3: Ejemplo Tablas Company, adaptado de [2], [3]
Este es un ejemplo muy simple, sin embargo, muestra una situaci´on en la que el rendimiento de una BDoG ser´a superior al de una base de datos relacional.
Esta diferencia de rendimientos puede parecer poco relevante cuando se trabaja con pocos datos, pero a medida que el volumen se incrementa, esta diferencia se hace notable. A pesar de que probablemente en la primera parte de la consulta la BDoG tambi´en deba mirar un ´ındice para encontrar los v´ertices iniciales para el recorrido, en el resto de los pasos se hace por uso directo de los punteros f´ısicos que relacionan los v´ertices (esta consulta se ejecutar´a m´as o menos en tiempo constante), mientras que en la RDBMS es necesario buscar en al menos un ´ındice (a menudo dos) cada una de las referencias buscadas costar´a O(log2n) si se usa un ´ındice B-Tree (siendo n el n´umero de registros en la tabla).
En cualquier caso, comparar modelos de bases de datos entre s´ı suele ser un reto debido a las diferentes concepciones que tienen y a los distintos problemas que intentan resolver. Podemos decir que, cuando la profundidad del recorrido sea im- portante, o cuando no se conozca de antemano las BDoG son m´as eficientes que las RDBMS, pero si la consulta se puede estructurar mucho, entonces hay herramientas de optimizaci´on para RDBMS que pueden ofrecer resultados m´as eficientes. Uno de los casos en los que las RDBMS no pueden optimizar sus consultas es precisamente cuando la b´usqueda es parametrizada y no se tiene a priori una forma estructurada
uniforme, sino que depende de los resultados intermedios que se vayan obteniendo a medida que se recorra el grafo.
3.1. Consultas recursivas
Las consultas recursivas se ejecutan varias veces seguidas, llam´andose a s´ı mismas repetidamente hasta que alcanzan alguna condici´on de escape o terminaci´on. Las ba- ses de datos relacionales no manejan bien las operaciones recursivas (especialmente las ilimitadas), y tienen problemas tanto con la sintaxis como con el rendimiento.
Esto generalmente lleva a escribir y mantener consultas complejas, desnormalizaci´on excesiva de nuestros datos, o ambos, todo en un esfuerzo por devolver resultados de manera oportuna.
En las RDBMS en general, las consultas recursivas son ´utiles cuando se trabaja con datos autorreferenciales o estructuras de datos en forma de grafo / ´arbol. Es- tas consultas aprovechan el llamado Common Table Expressions (CTE)1 que es la cl´ausula SQL WITH.
Observaremos la estructura formal de la consulta recursivas.
Figura 3.4: Estructura formal de consulta SQL recursiva, recuperado de [4]
En la estructura vemos que no es muy intuitiva adem´as de la complejidad que agrega para depurar como tambi´en el costo en t´erminos de c´omputos.
Analizaremos un ejemplo sencillo para entender las partes de la consulta en una RDBMS contra la BDoG, el ejemplo minimalista trata de una jerarqu´ıa de gesti´on de una posible soluci´on para una empresas. Se utilizo para el ejemplo en RDBMS MySQL2 y para BDoG Neo4j3.
1https://social.technet.microsoft.com/wiki/contents/articles/37558.t-sql-common-table- expression-cte.aspx
2https://www.mysql.com/
3https://neo4j.com/
Figura 3.5: Ejemplo de jerarqu´ıa de personas en una empresa
3.1.1. Representaci´ on con RDBMS
Para modelar la jerarqu´ıa (ver Figura 3.5 ), tenemos el siguiente esquema de tabla e inserciones de los datos a continuaci´on:
Figura 3.6: Representaci´on del esquema en MySQL - ejemplo de jerarqu´ıa de perso- nas en una empresa
Luego usamos una funci´on recursiva para consultar estos datos para encontrar la jerarqu´ıa de administraci´on del presidente (ver Figura 3.7).
Figura 3.7: C´odigo recursivo RDBMS - ejemplo de jerarqu´ıa de personas en una empresa, adaptado de [4], [5]
Lo primero es montar una CTE que busque el elemento de partida. Con las l´ıneas del c´odigo de recursivas podemos identificar sobre una consulta tipo:
En las l´ıneas del 1 a 3 se define el CTE.
En las l´ıneas del 4 a 6 identificamos el primer elemento de la estructura jer´arquica, nodo o ra´ız. El WHERE implica el punto de partida.
En la l´ınea 7 preparamos el conjunto recursivo.
En la l´ınea 8 por ser UNION ALL devolvemos el mismo numero de elementos y tipos.
En las l´ıneas 9 al 10 se relacionan la tabla origen con la tabla de expresi´on com´un o lo que es lo mismo la recursividad.
En la l´ınea 11 se indica que tiene que buscar los elementos de la tabla origen en los cuales su columna padre, apunte al id que tenga en ese instante el CTE.
En las l´ıneas 12 y 13, la salida de la tabla con expresi´on com´un.
El resultado de la consulta (ver Figura 3.1.1).
Figura 3.8: Salida de la consulta recursiva - ejemplo de jerarqu´ıa de personas en una empresa
3.1.2. Representaci´ on con BDoG
Para modelar esta jerarqu´ıa con neo4j se utiliz´o el lenguaje de consultas Cypher4 en primer lugar creamos los v´ertices (nodos) y luego las aristas (relaciones) (ver Figura 3.9, Figura 3.10).
Figura 3.9: Crear v´ertices - ejemplo de jerarqu´ıa de personas en una empresa
4https://neo4j.com/developer/cypher/
Figura 3.10: Crear relaciones - ejemplo de jerarqu´ıa de personas en una empresa
Figura 3.11: Consulta lenguaje Cypher para neo4j - ejemplo de jerarqu´ıa de personas en una empresa
Este ejemplo (ver Figura 3.11) demuestra la naturaleza sencilla con la que pue- de hacer preguntas de forma recursiva en un grafo. Las BDoG utilizan sus ricas representaciones de relaciones para manejar estas consultas recursivas ilimitadas de manera limpia y eficiente.
Este recorrido se corresponde naturalmente con nuestro instinto de navegar vi- sualmente por la jerarqu´ıa de los datos. Podemos intuir que desde el v´ertice persona presidente quiero obtener todas las aristas hacia el resto de las personas con la re- laci´on TRABAJA CON.
Por otro lado, las BDoG tambi´en pueden visualizar el resultado en forma de grafo. Y comparando con Figura 3.5 que fue la estructura de partida, obtendremos el mismo resultado (no hubo cambio con el dominio de la soluci´on) Figura 3.12.
Figura 3.12: Resultado de neo4j - ejemplo de jerarqu´ıa de personas en una empresa
3.2. Diferentes tipos de resultados
Cuando se necesitado devolver varios tipos de datos diferentes de una base de datos, todo dentro de un ´unico conjunto de resultados.
Veamos c´omo se comparan las RDBMS y BDoG cuando devuelven diferentes tipos.
Para esto tomaremos un ejemplo de un sistema de procesamiento de ordenes y queremos devolver la informaci´on de las ´ordenes y los productos. Es una implemen- taci´on simple para cada base de datos con la intenci´on de comparar ambos mundos.
3.2.1. Representaci´ on con RDBMS
Es posible lograr esto con una uni´on de todas las columnas en todas las tablas, tiende a producir resultados menos que ideales.
Figura 3.13: Tablas de productos y ordenes en una RDBMS, adaptado de [1]
El siguiente fragmento de c´odigo muestra c´omo escribir una consulta para recu- perar la informaci´on de ´ordenes y productos.
Figura 3.14: Fragmento de c´odigo SQL para la consulta - ´ordenes y productos, adaptado de [1]
Figura 3.15: Resultado de la consulta SQL – ´ordenes y productos, adaptado de [1]
Vemos en el resultado que la uni´on de estos dos tipos de datos dispares dicta que nuestra respuesta contiene una gran cantidad de valores nulos (com´unmente conocidos como datos dispersos o matriz dispersa)5. Esta abundancia de datos nulos se debe a que las columnas entre las dos tablas son inconsistentes.
Una RDBMS especifica que el conjunto de resultados devuelto debe contener un conjunto coherente de columnas. En los casos de datos escasos, esto no solo aumenta la cantidad de datos devueltos, sino que tambi´en reduce la naturaleza descriptiva de la estructura de datos.
3.2.2. Representaci´ on con BDoG
Uno de los puntos fuertes de una base de datos orientada a grafos es la capacidad de devolver diferentes tipos de datos en los resultados.
5https://es.wikipedia.org/wiki/Matriz dispersa
Figura 3.16: Grafo de producto y ordenes en BDoG – neo4j
Con este grafo, podemos escribir una consulta para devolver tanto los datos del producto como del pedido muy simple sin contener valores nulos.
Figura 3.17: Fragmento de c´odigo Cypher – neo4j y su resultado
En comparaci´on con los resultados anteriores de SQL, los datos devueltos por el grafo conservan el significado sem´antico de lo que es el objeto y lo que representa, sin los datos nulos extra˜nos.
Debido a que las BDoG brindan la flexibilidad para devolver datos dispares, podemos crear un c´odigo mucho m´as limpio cuando trabajamos con tipos de datos muy variados.
3.3. Caminos
Un camino es la secuencia de v´ertices y aristas que describen c´omo se movi´o el recorrido a trav´es del grafo.
Representa problemas fundamentales que se encuentran en muchas aplicaciones del mundo real, como encontrar un camino en un mapa, encontrar el uso ´optimo
de recursos en un sistema log´ıstico, localizar conexiones entre personas en una red social, etc. Cada uno de estos casos se trata fundamentalmente de determinar el conjunto ´optimo de pasos para pasar de una entidad a otra. La estructura de datos del grafo nos permite aprovechar estas capacidades de b´usqueda de caminos, que no son una construcci´on nativa en otros tipos de bases de datos.
Usando una RDBMS, no podemos encontrar una manera de resolver caminos
´
optimos sin usar un m´etodo de fuerza bruta para calcular todas las combinaciones posibles. Sin embargo, con un modelado de datos un poco inteligente y el poder de un algoritmo de b´usqueda de caminos, es bastante sencillo resolver el/los caminos que satisfaga el problema con un grafo.
La capacidad de devolver como dos entidades, est´an conectados entre s´ı, desde dentro de la base de datos es una caracter´ıstica exclusiva de las BDoG.
3.4. Modelado BDoG
Por ´ultimo, una caracter´ıstica en la que las BDoG no tienen rival es en su faci- lidad para modelar y adaptarse a modelos cambiantes, modelar datos como un grafo es natural y tiene la ventaja de ser legible incluso para personas sin conoci- mientos t´ecnicos.
En RDBMS lo habitual tras dise˜nar un modelo de datos es pasar a normalizarlo para asegurarnos el correcto funcionamiento del modelo relacional sobre los datos, pero el modelado usando BDoG es tan natural que el modelado puede hacerse sin conocimientos t´ecnicos expl´ıcitos, puesto que el modelo de datos de la BDoG y el de los datos que se quieren almacenar es, en la mayor´ıa de los casos, el mismo (es- ta afirmaci´on es voluntaria y exageradamente simplista, pero refleja un hecho muy cercano al mundo real).
Un ejemplo simplista: representar un problema comercial y las entidades asocia- das.
Figura 3.18: Modelo del negocio (simulando pizarra), recuperado de [3]
Luego, cuando se ha elegido el sistema de almacenamiento, se debe incorporar el modelo de datos.
Si se elige una base de datos relacional, generalmente se comienza normalizando el modelo para que cumpla con la tercera forma normal, y podr´ıa verse as´ı:
Figura 3.19: Modelo relacional, recuperado de [3]
Pero si uno elige modelar los datos con una BDoG, probablemente se ver´a as´ı:
Figura 3.20: Modelo de Grafo, recuperado de [3]
4. Cu´ ando usar BDoG
Como saber si es una buena opci´on usar BDoG, lo identificaremos de una manera gen´erica.
Estamos de acuerdo en que el mundo real se describe f´acilmente en t´erminos de grafos, pero decir que todo se resuelve con un tipo de base de datos es una simplifi- caci´on dr´astica. El hecho de que un problema se pueda representar como un grafo no significa necesariamente que una BDoG sea la mejor tecnolog´ıa para elegir resolver ese problema.
El proceso comienza con una simple pregunta: ¿Qu´e problema estamos tratan- do de resolver? Responder a esta pregunta proporciona detalles cruciales sobre qu´e preguntas vamos a hacer, y esto rige los tipos de datos que necesitamos almacenar y c´omo debemos recuperarlos.
Desglosamos las respuestas en las siguientes categor´ıas de problemas:
Selecci´on - b´usqueda.
Datos relacionados o recursivos.
Agregaci´on.
La coincidencia de patrones.
Centralidad, agrupaci´on e influencia.
4.1. Selecci´ on - b´ usqueda
Las preguntas sobre las selecci´on-b´usqueda se enfocan de manera estricta en encontrar un peque˜no conjunto de entidades que comparten un atributo com´un como el nombre, la ubicaci´on o el empleador:
¿Qui´enes trabajan en X empresa?
¿Qui´en en mi sistema tiene un nombre como John?
¿D´onde est´an los comercios dentro de X kil´ometros?
Este tipo de preguntas no requieren relaciones ricas dentro de los datos. En la mayor´ıa de las bases de datos, responder a estas preguntas requiere utilizar un ´unico criterio de filtrado o, potencialmente, un ´ındice.
Debido a que estos problemas no aprovechan las relaciones en nuestros datos, es poco probable que valga la pena asumir las complejidades adicionales de las BDoG.
En este caso es recomendable usar RDBMS.
4.2. Datos relacionados o recursivos
Las preguntas que exploran las relaciones entre entidades agregan significado y brindan valor topol´ogico a los datos, proporcionando un caso de uso s´olido para una BDoG.
Algunos ejemplos de este tipo de preguntas incluyen:
¿Cu´al es la forma m´as f´acil de que me presenten a un ejecutivo de X empresa?
¿C´omo se conocen John y Paula?
¿C´omo se relaciona la empresa X con la empresa Y?
Las BDoG aprovechan esta informaci´on mejor que cualquier otro tipo de motor de datos, y sus lenguajes de consulta son m´as adecuados para razonar sobre las re- laciones dentro de los datos. Aunque no es imposible en bases de datos relacionales, este tipo de consultas de amigos de amigos requieren complejas y dif´ıciles de man- tener o razonar sobre CTE recursivas o combinaciones complejas en muchas tablas diferentes.
En este caso es recomendable usar BDoG.
4.3. Agregaci´ on
Las consultas de agregaci´on de datos constituyen un excelente caso de uso para una RDBMS. Las mismas est´an optimizadas para realizar consultas de agregaci´on complejas de forma r´apida y con una sobrecarga m´ınima.
Las preguntas de ejemplo pueden incluir:
¿Cu´antas empresas hay en mi sistema?
¿Cu´ales son mis ventas promedio de cada d´ıa durante el ´ultimo mes?
¿Cu´al es la cantidad de transacciones procesadas por mi sistema cada d´ıa?
Estos mismos tipos de consultas se pueden realizar en BDoG, pero la naturale- za de los recorridos de grafos requiere que se toquen muchos m´as datos. Pero esto provoca una mayor latencia de consulta y utilizaci´on de recursos.
En este caso es recomendable usar RDBMS.
4.4. Coincidencia de patrones
La coincidencia de patrones basada en c´omo se relacionan las entidades es un excelente ejemplo de c´omo aprovechar el poder de las BDoG. Los casos de uso t´ıpi- cos para este tipo de consultas involucran cosas como motores de recomendaci´on, detecci´on de fraude o detecci´on de intrusiones.
Algunas preguntas pueden incluir:
¿Qui´en en mi sistema tiene un perfil similar al m´ıo?
¿Esta transacci´on se parece a otras transacciones fraudulentas conocidas?
¿El usuario J. Smith es el mismo que Johan S.?
Los casos de uso de coincidencia de patrones se realizan con tanta frecuencia en BDoG que los lenguajes de consulta de grafos tienen caracter´ısticas integradas espec´ıficas para manejar con precisi´on este tipo de consultas.
En este caso es recomendable usar BDoG.
4.5. Centralidad, agrupaci´ on e influencia
La influencia o importancia relativa de una entidad en comparaci´on con otra es un caso de uso t´ıpico de una BDoG.
Algunas preguntas de ejemplo pueden incluir:
¿Qui´en es la persona m´as influyente con la que estoy conectado en LinkedIn?
¿Qu´e equipo de mi red tiene el impacto m´as sustancial si se rompe?
¿Qu´e partes tienden a fallar al mismo tiempo?
Ejemplos de otros problemas de este tipo incluyen encontrar a la persona m´as influyente en una red de Twitter, identificar piezas cr´ıticas de infraestructura o ubi- car grupos de entidades dentro de sus datos.
Calcular las respuestas a este tipo de problemas requiere observar las entidades, sus relaciones y las relaciones de incidentes y entidades adyacentes.
Al igual que con los casos de uso de coincidencia de patrones, estos tipos de problemas a menudo tienen caracter´ısticas espec´ıficas de lenguajes de consulta de grafo incorporados.
En este caso es recomendable usar BDoG.
4.6. Gu´ıa para decidir
¿Deber´ıa usar una base de datos orientada a grafo? Desde el ´arbol de decisi´on avanzamos contestando las preguntas hasta llegar a un estado de s´ı, no o quiz´as.
Figura 4.1: ´Arbol de decisi´on – utilizar un BDoG, adaptado de [1]
¿Nos preocupan las relaciones entre entidades tanto o m´as que las propias entidades?
Esta pregunta es quiz´as la pista m´as cr´ıtica. Habla del coraz´on de una de las ca- racter´ısticas m´as poderosas de las BDoG: las relaciones son tan significativas como las entidades.
Si nuestra respuesta a esta pregunta es s´ı, entonces probablemente necesitemos un modelo de datos que permita representaciones sofisticadas de las relaciones, un candidato excelente para usar una BDoG. Pero si nuestra respuesta es no, entonces quiz´as otro motor de datos ser´ıa una mejor opci´on.
¿Mi consulta SQL realiza m´ultiples combinaciones en la misma tabla o requiere un CTE recursivo?
Si bien una gran cantidad de combinaciones en una consulta SQL puede indicar que una BDoG podr´ıa ser una buena opci´on, no asegura esa posibilidad. Un gran n´umero de combinaciones en una consulta SQL suele ser un signo de un modelo de datos bien normalizado. Pero cuando esas uniones no se utilizan para recuperar datos de referencia (como se hace con una tercera forma normal en una base de datos relacional) y, en cambio, se utilizan para vincular elementos juntos (como con una relaci´on padre-hijo), entonces es posible que deseemos considerar una BDoG.
Adem´as, los patrones de consulta recursivos se benefician de las BDoG cuando no sabemos el n´umero de uniones que se realizar´an.
¿La estructura de mis datos evoluciona continuamente?
Las RDBMS tienen una reputaci´on bien merecida por la rigurosidad de su es- quema y la complejidad asociada al realizar cambios de esquema.
Si su problema requiere tomar datos con diferentes esquemas de datos, entonces vale la pena investigar una BDoG.
La flexibilidad con el esquema de datos por s´ı sola no deber´ıa ser una raz´on suficiente para elegir una BDoG, sin embargo, combinada con otras caracter´ısticas, podr´ıa ser suficiente para inclinar la balanza a favor del uso de una BDoG.
¿Es mi dominio un ajuste natural para un grafo?
Si est´a haciendo algo como enrutamiento, administraci´on de dependencias, an´ali- sis de redes sociales, etc. entonces su problema gira en torno a datos altamente in- terconectados, por lo que su dominio puede ser adecuado para usar un grafo.
Una advertencia: aunque su dominio se modela naturalmente en un grafo, si sus preguntas no se basan en las relaciones del grafo para las respuestas, entonces
deber´ıa considerar otras opciones.
4.7. Algunos usos de la BDoG
Las potencialidades m´ultiples de las BDoG las hacen atractivas para diferentes tipos de proyectos. Existen condiciones especiales donde es casi obligatorio pensar en implementar una.
Detecci´on de fraude
Sirven para estudiar patrones relacionales que se presentan en las estrategias que utilizan los delincuentes para cometer fraude.
Esta potencialidad es muy ´util para empresas del sector financiero y bancario donde es dif´ıcil ver por donde circula el dinero, sobre todo si se usan empresas pan- talla o empresas en para´ısos fiscales, testaferros, sociedades, etc. Al final tenemos un conjunto de datos de diferentes fuentes, pero con relaciones directas o indirectas di- ficultando el seguimiento del dinero y por tanto ocultando el fraude. Con un modelo basado en grafos, nos facilita el trabajo pudiendo seguir la pista, sobre todo si hay una representaci´on visual de los datos, ejecutando consultas y b´usquedas de los ele- mentos, llegando a establecer las relaciones por donde haya podido circular el dinero.
Sistema de recomendaci´on
Al tener la capacidad de mostrar las relaciones complejas entre v´ertices estas nos brindan la posibilidad de establecer aristas entre personas e intereses.
Su implementaci´on ha ayudado a las redes sociales a optimizar su funcionamien- to.
Tambi´en es una gran oportunidad para las empresas ya que con informaci´on de esta clase pueden optimizar sus productos y servicios a los intereses de su p´ublico, donde un cliente tiene una compra pendiente de un producto, y por relaci´on de similitud o proximidad de productos te ofrece otros para completar el pedido. Esto se consigue gracias a que entre ambos productos existe una o varias relaciones.
C´alculo de rutas en log´ıstica
Son capaces de aplicar el algoritmo del camino m´as corto, usando algoritmos de Kruskal1, Dijkstra2 o Prim3. Lo que le facilita a la empresa el c´alculo y reducci´on de costos en la selecci´on de las rutas.
1https://es.wikipedia.org/wiki/Algoritmo de Kruskal
2https://es.wikipedia.org/wiki/Algoritmo de Dijkstra
3https://es.wikipedia.org/wiki/Algoritmo de Prim
Relaciones sociales
Donde mayor uso se le puede dar y en donde mejor encajan.
En este caso hay m´ultiples ejemplos, desde temas relacionados con el cine, per- sonajes, actores, directores, etc.
Tambi´en lo podemos usar para modelar el conocimiento adquirido por los em- pleados, que tecnolog´ıas conocen, en qu´e proyectos han estado trabajando, con qu´e personas han estado trabajando.
Modelos de redes
Donde una red de sistemas o computadoras puede ser representado por un grafo.
5. Tipos de grafos
En el cap´ıtulo 3: Introducci´on a grafos vimos la definici´on de grafos.
Ahora veremos algunos tipos de grafos.
5.1. Grafo no dirigido
Un grafo no dirigido es un tipo de grafo en el cual las aristas representan rela- ciones sim´etricas y no tienen un sentido definido.
Formalmente, se definen por un par de conjuntos G = (V, E), donde:
V 6= ∅ es el conjunto no vac´ıo de v´ertices.
E ⊆ {(a, b) ∈ V xV } es el conjunto de aristas, tal que (a, b) = (b, a).
Figura 5.1: Grafo no dirigido con dos v´ertices y una arista, recuperado de [6]
5.2. Grafo dirigido
Un grafo dirigido es un tipo de grafo en el cual las aristas tienen un sentido definido.
Formalmente, se definen por un par de conjuntos G = (V, E), donde:
V 6= ∅ es el conjunto no vac´ıo de v´ertices.
E ⊆ {(a, b) ∈ V × V : a 6= b} es un conjunto de pares ordenados de elementos de V donde una arista va del primer v´ertice (a) al segundo v´ertice (b).
Figura 5.2: Grafo dirigido con tres v´ertices y tres aristas dirigidas, recuperado de [7]
5.3. Grafo con peso o ponderado
Es un grafo dirigido o no dirigido, donde las aristas tienen alg´un tipo de valora- ci´on.
Figura 5.3: Grafo no dirigido con peso, recuperado de [8]
5.4. Grafo con etiquetas
Es un grafo dirigido o no dirigido, donde se incorporan etiquetas que pueden definir los distintos v´ertices y tambi´en las aristas entre ellos.
Formalmente, dado un grafo G, un v´ertice etiquetado es una funci´on que hace corresponder v´ertices de G a un conjunto de etiquetas. De la misma manera, una arista etiquetada es una funci´on que hace corresponder aristas de G a un conjunto de etiquetas.
Figura 5.4: Grafo dirigido con etiquetas en v´ertices y aristas
5.5. Grafo de propiedades
Es el m´as complejo, es un grafo con etiquetas y donde podemos asignar propie- dades tanto a v´ertices como a sus aristas.
Figura 5.5: Grafo dirigido de propiedades, v´ertices con etiqueta “Person” y pro- piedades (Id, Name, Age), aristas con etiqueta “Knows” y propiedades (Id, Since), recuperado de [9]
5.6. Multigrafo
Los multigrafos pueden ser grafos no dirigidos o grafos dirigidos y con la combi- naci´on de grafo con peso, grafos con etiquetas y/o grafos de propiedades.
Con la diferencia que las aristas pueden ser un conjunto en un mismo v´ertices o entre un par de v´ertices.
Figura 5.6: Multigrafo con v´ertices que representan departamentos y sus aristas distintas opciones de llegar al destino
6. Tipos de gestores de BDoG
6.1. Neo4j
Neo4j es la base de datos orientada a grafos m´as polular seg´un db-engines.com1 a la fecha de este trabajo, es una plataforma de base de datos de grafos nativa que est´a dise˜nada para almacenar, consultar, analizar y administrar datos altamente conectados de manera eficiente.
6.1.1. Modelo de datos
El modelo de datos utilizado por Neo4j es un grafo de propiedades etiquetado (ver Secci´on 5.5). Por tanto, las unidades b´asicas de procesamiento en Neo4j son:
v´ertices, aristas entre v´ertices, etiquetas que permiten definir el tipo de los v´ertices y de las aristas y tambi´en las propiedades (definidas sobre v´ertices y/o aristas).
En Neo4j se utilizan los dos puntos “:” para representar las etiquetas. Las pro- piedades se acostumbran a representarse en min´usculas.
Por otro lado, para distinguir f´acilmente las etiquetas de v´ertices de las de aris- tas, en Neo4j se escriben las etiquetas de aristas en may´usculas y las etiquetas de v´ertices con la primera letra en may´uscula y el resto en min´usculas.
Como ejemplo :Libro, :Persona y :HA LE´IDO entonces Libro y Persona son eti- quetas de los v´ertices mientras que HA LE´IDO representa la etiqueta de la relaci´on.
6.1.2. Restricciones de integridad
En Neo4j es posible aplicar ciertas restricciones de integridad sobre los esquemas.
Estas restricciones son:
Unicidad (UNIQUE): permite indicar que el valor de una propiedad debe ser ´unico para todos los v´ertices del mismo tipo.
Existencia: permite indicar que una propiedad (o un conjunto de ellas) debe existir para todos los v´ertices de un tipo.
1https://db-engines.com/en/ranking/graph+dbms
Clave (PRIMARY KEY): permite indicar que una propiedad es clave para todos los v´ertices de un determinado tipo, es decir, que todos sus v´ertices deben tener definida la propiedad y que el valor de la propiedad es ´unico.
6.1.3. Manejo de transacciones
Para mantener completamente la integridad de los datos y garantizar un buen comportamiento transaccional, Neo4j admite las propiedades ACID (ver en el Cap´ıtu- lo 10).
Interfaces de consultas
Neo4j permite acceder a sus datos de diversas formas:
Desde consola.
Un entorno web gr´afico.
Mediante API.
Lenguaje de consultas
Neo4j permite consultar sus datos de distintos lenguajes de consulta:
Cypher, que es un lenguaje declarativo que permite consultar y manipular grafos.
Gremlin, que es un lenguaje espec´ıfico de dominio para la gesti´on de grafos.
6.1.4. Almacenamiento f´ısico de la estructura de datos
Neo4j almacena los datos en una serie de archivos de almacenes diferentes, cada archivo de almac´en contiene una parte espec´ıfica del grafo, entre ellos:
Archivo de almacenamiento de v´ertices.
Archivo de almacenamiento de aristas.
Archivo de almacenamiento de propiedades.
Archivo de almacenamiento de tipos de relaciones.
Otros.
Almacenamiento de v´ertices
Este archivo como su nombre lo indica solo almacena registro de v´ertices y el nombre f´ısico es neostore.nodestore.db.
Es un almacenamiento de registros fijos donde cada registro tiene 9 bytes de longitud. Esto le permite a Neo4j b´usquedas r´apidas en este archivo con un costo de O(1).
Figura 6.1: Neo4j registro de v´ertice de largo fijo (9 bytes)
En la Figura 6.1 tenemos un registro del v´ertice donde el byte 1 es la marca de uso, indica si el registro se esta usando actualmente los siguientes bytes del 2 al 5 (4 bytes) contiene el identificador del primer registro de la arista y el resto del 6 al 9 (4 bytes) identifica el registro de la primera propiedad.
Resumiendo, el registro del v´ertice es un par de punteros a listas de aristas y propiedades identificando el primero de cada lista.
Almacenamiento de aristas
Este archivo como su nombre lo indica solo almacena registro de aristas y el nombre f´ısico es neostore.relationshipstore.db.
Al igual que el registro de v´ertices, el registro de aristas es de longitud fija de 33 bytes. Con el cual Neo4j consulta con un costo de O(1).
Figura 6.2: Neo4j registro de arista de largo fijo (33 bytes)
En la Figura 6.2 es un registro de arista donde el 1 byte es la marca de uso con la misma funcionalidad de la marca de uso para el registro de v´ertice. Los bytes siguientes del 2 al 5 (4 bytes) tiene el identificador al v´ertice inicial y los otros 4 bytes del 6 al 9 el identificador del v´ertice final. Los bytes del 10 al 13 (4 bytes) el identificador de tipos de aristas (que tambi´en est´an en un archivo de almacenamien- to). El resto de los bytes del 14 al 29 (16 bytes) tiene el identificador de las aristas anterior y siguiente de cada v´ertice inicial y final mientras que los bytes del 30 al 33 (4 bytes) es el identificador a la primera propiedad.
Punteros de los registros v´ertices-aristas
Figura 6.3: Neo4j estructura de punteros, recuperado de [10]
En la Figura 6.3 se visualiza como interact´uan los distintos archivos de almace- namiento en disco. Cada registro de los 2 v´ertices contiene un puntero a la primera propiedad y relaci´on en una cadena de relaciones.
Para leer las propiedades de un v´ertice como arista se sigue la estructura de lista simples enlazadas comenzando con el puntero a la primera propiedad.
Para leer las aristas de un v´ertice se sigue la estructura de lista doblemente enla- zadas comenzando con el puntero a la primera arista. En el caso particular de querer leer una arista determinada, seguimos el mismo procedimiento y al encontrarla po- demos leer sus propiedades (si las tiene) o se puede examinar los dos registros de los v´ertices que conecta esa arista mediante sus identificadores de v´ertice inicial y v´erti- ce final. Estos identificadores multiplicados por el tama˜no del registro del v´ertice (9 bytes) obtenemos el desplazamiento inmediato en el archivo de almacenamiento de v´ertices.
Al tener las aristas con la estructura de listas dobles enlazadas permite recorrer en cualquier direcci´on e insertar y eliminar de forma eficiente.
6.1.5. Datos en cache
Representados por dos objetos en memoria: v´ertices y aristas.
Las representaciones de las propiedades tanto en v´ertices como en aristas son de clave, valor.
Los objetos de v´ertices agrupan sus aristas por tipo de relaci´on y su direcci´on, si son entrantes o salientes.
Figura 6.4: Neo4j – estructura minimalista de nodo y relaci´on, mostrando el ciclo para recorrer todos los nodos de alg´un tipo de relaci´on
Para entender esto supongamos que tenemos un grafo que representa las relacio- nes de amistad entre personas, las ciudades donde viven y el autom´ovil que manejan.
Como se aprecia en la Figura 6.5. Se puede observar en cada relaci´on el id que es la referencia directa a dicha relaci´on.
Figura 6.5: Neo4j - ejemplo nodos y relaciones
Suponiendo que queremos obtener los amigos de Miguel, tenemos los tipos de relaci´on ES AMIGO, VIVE EN y CONDUCE, pero solo nos interesa la relaci´on de amistad los dem´as tipos se descartan y se itera sobre la lista de salida y se obtienen los v´ertices Carlos, Luis, Ana de forma directa.
Figura 6.6: Neo4j - ejemplo del ciclo para obtener los amigos
6.2. ArangoDB
ArangoDB se encuentra en el puesto 3 del grupo BDoG db-engines.com2. Es una plataforma de base de datos dise˜nada para almacenar datos de forma nativa como grafo, pares clave-valor y documentos a los que se puede acceder con un lenguaje de consulta ´unico.
6.2.1. Modelo de datos
Es una base de datos multi-modelo porque combina los modelos clave/valor, do- cumentos y grafos en un solo n´ucleo desarrollado en C++. Pose´e un lenguaje de consulta unificado AQL (ArangoDB Query Language) que permite realizar consul- tas entre los diferentes modelos de datos indistintamente. Soporta un multigrafo dirigido de propiedades.
Tanto las aristas como los v´ertices son colecciones de documentos en formato JSON.
Figura 6.7: ArangoDB – vertices y aristas en formato JSON, recuperado de [11]
6.2.2. Restricciones de integridad
Solo cuenta con la clave primaria (atributo Key), pero se pueden definir otras cumpliendo ciertas restricciones definidas por ArangoDB3.
6.2.3. Manejo de transacciones
ArangoDB soporta transacciones ACID (ver en el Cap´ıtulo 10), las transacciones son siempre operaciones del lado del servidor.
2https://db-engines.com/en/ranking/graph+dbms
3https://www.arangodb.com/docs/stable/data-modeling-naming-conventions-document- keys.html
Se realiza con una funci´on de JavaScript db. executeTransaction(object) donde object contiene diferentes atributos (colecciones, acci´on, opcionales).
´Indices
ArangoDB indexa autom´aticamente algunos atributos del sistema y tambi´en per- mite crear ´ındice a los usuarios, pero a nivel de colecci´on. Los ´ındices son:
´Indices persistentes
Es un ´ındice ordenado con persistencia en disco.
´Indices TTL
Se puede utilizar para eliminar autom´aticamente documentos caducados en la co- lecci´on.
´Indices de texto completo
Para indexar texto completo dentro de los documentos.
´Indices geogr´aficos
´Indice que almacena coordenadas bidimensionales con los atributos latitud y longi- tud que tienen que ser de tipos num´ericos.
´Indices centrados en v´ertices
Son los mas importantes para el grafo donde se indexan los atributos de las aristas (atributos from y to). Proporcionan un acceso r´apido a todas las aristas que se originan o llegan a un v´ertice dado y permiten encontrar r´apidamente los vecinos de un v´ertice en el grafo.
Interfaces de consultas
La gesti´on de la base de datos se pueden hacer a trav´es de las interfaces:
Web.
ArangoSH.
REST/ API.
Lenguaje de consultas
El lenguaje de consulta de ArangoDB es declarativo y permite la combinaci´on de diferentes patrones de acceso a datos en una sola consulta AQL (ArangoDB Query Lenguage).
6.2.4. Almacenamiento f´ısico de la estructura de datos
ArangoDB tiene una estructura distinta para el almacenamiento del grafo donde se cuestiona el ´ındice de adyacencia4. Este usa un h´ıbrido entre ´ındice y lista doble- mente encadena.
El almacenamiento de los v´ertices est´a referenciado a un hash que fue creado por la clave del v´ertice. De igual forma se almacenan las aristas.
Cada v´ertice tiene referencia al identificador de la primera arista en el hash de aristas, y las aristas siguientes est´an en la estructura de lista doblemente encadenada, recorriendo la lista se obtiene todas sus relaciones.
Figura 6.8: ArangoDB – Hash h´ıbrido con listas vinculadas - ´ındices, adaptado de [12]
6.3. TerminusDB
TerminusDB se encuentra en el puesto 25 (mayo 2021) del grupo BDoG de db- engines.com5. Es una plataforma de base de datos de grafos en memoria.
4https://en.wikipedia.org/wiki/Talk:Graph database#Changed opening paragraph
5https://db-engines.com/en/ranking/graph+dbms
6.3.1. Modelo de datos
Es un grafo dirigido de propiedades etiquetados.
Figura 6.9: TerminusDB – grafo de propiedades, recuperado de [13]
En TerminusDB todo es un objeto de una clase. Los objetos pueden tener pro- piedades, y las propiedades pueden vincularse a otros objetos.
De la Figura 6.9 se identifican 4 estructuras principales:
OrdinaryClass.
DocumentClass (doc:Person).
ObjectProperty (knows:doc:Person).
DatatypeProperty (name:String).
Las clases de documentos son clases de nivel superior. Continuando con la Figu- ra 6.9 los v´ertices Mar´ıa , Anna , Tom y Jim son objetos de documento. knows es una propiedad de objeto y con alcance al documento de persona.
Las clases pueden ser subclases de otras clases, lo que significa que heredan todas las propiedades de los padres (al igual que la herencia en la programaci´on orientada a objetos). Se admite tambi´en la herencia m´ultiple.
El tipo de datos al que apunta la propiedad puede ser un simple literal de tipo de datos DatatypeProperty o puede ser una clase ObjectProperty.
TerminusDB es una base de datos de grafos que almacena datos como Git con los mismos beneficios como tener registro de quienes hicieron confirmaciones, permite volver a un estado anterior y la mayor motivaci´on de TerminusDB es poder clonar el conjunto de datos y hacer las modificaciones necesarias y sincronizar los datos para dejarlo en el nuevo estado, esto permite que diferentes desarrolladores pueden
trabajar con los mismos datos. Resumiendo, permite todo el conjunto de funciones de control de revisiones: branch, merge, squash, rollback, blame, y time-travel.
6.3.2. Restricciones de integridad
A nivel de estructura solo cumple con unicidad.
6.3.3. Manejo de transacciones
TerminusDB soporta transacciones ACID (ver en el Cap´ıtulo 10).
Interfaces de consultas
La gesti´on de la base de datos se pueden hacer a trav´es de las interfaces:
Consola.
Entorno Web.
REST/ API.
Lenguaje de consultas
TerminusDB tiene un ´unico lenguaje de consulta WOQL (Web Object Query Language).
6.3.4. Almacenamiento de la estructura de datos
TerminusDB basa su modelos de datos en el est´andar RDF (ver en el Cap´ıtu- lo 10). Este modelo es implementado usando una estructura de datos sucinta6 en la cual los datos se comprimen al m´aximo posible. La estructura del dise˜no del grafo se basa en HDT (ver en el Cap´ıtulo 10).
En particular, se conservan las estructuras de datos principales del formato HDT, a saber, diccionarios, secuencias de bits y ´arboles de wavelet. Los ´arboles de wavelet almacenan la estructura de datos sucinta, lo cual la descompone hasta tener datos homog´eneos en sus hojas.
Tiene funciones de mapeos de las estructuras de sujetos, predicados y objeto a n´umeros naturales y de estos n´umeros podemos obtener las estructuras. Con los n´umeros naturales obtenidos de los sujetos y predicados se genera una secuencia de bit de tal forma que los datos quedan comprimidos en las secuencias de bits.
Veamos un ejemplo:
6https://en.wikipedia.org/wiki/Succinct data structure
Figura 6.10: TerminusDB – grafo ejemplo
DiccionarioSujetos(Juan:Persona) = 1, donde tambi´en Juan:Persona = Dic- cionarioSujetoPorId(1).
DiccionarioSujetos(Ana:Persona) = 2 , donde tambi´en Ana:Persona = Diccio- narioSujetoPorId(2).
DiccionarioSujetos(BMW:Auto) = 3, donde tambi´en BMW:Auto = Dicciona- rioSujetoPorId(3).
DiccionarioPredicado(ES AMIGO) = 2, donde tambi´en ES AMIGO = Diccio- narioPredicadoPorId(2).
DiccionarioPredicado(TRABAJA EN) = 3, donde tambi´en TRABAJA EN = DiccionarioPredicadoPorId(3).
DiccionarioPredicado(ES JEFE DE) = 4, donde tambi´en ES JEFE DE = Dic- cionarioPredicadoPorId(4).
DiccionarioPredicado(CHOFER) = 5, donde tambi´en CHOFER = Dicciona- rioPredicadoPorId(5).
DiccionarioObjeto(Jose:Persona) = 3 , donde tambi´en Jose:Persona = Diccio- narioObjetoPorId(3).
DiccionarioObjeto(Maria:Persona) = 4, donde tambi´en Maria:Persona = Dic- cionarioObjetoPorId(4).
DiccionarioObjeto(Montevideo:Ciudad) = 5, donde tambi´en Montevideo:Ciudad
= DiccionarioObjetoPorId(5).
DiccionarioObjeto(Romina:Persona) = 6, donde tambi´en Romina:Persona = DiccionarioObjetoPorId(6).
DiccionarioObjeto(Lucas:Persona) = 7, donde tambi´en Lucas:Persona = Dic- cionarioObjetoPorId(7).
Los identificadores se almacenan en formas de ternas de subjeto, predicado y objeto.
Figura 6.11: TerminusDB – grafo ejemplo con identificadores
En la Figura 6.12 podemos ver la terna y la codificaci´on indicado de color azul el sujeto, de rojo el predicado y verde el objeto. Tambi´en se pueden ver las secuencias de bits codificada de sujetos y predicados. Con esto se obtiene una forma ´optima de b´usqueda.
Partiendo del sujeto, desde la secuencia de bit del sujeto obtenemos los identifi- cadores de los predicados y por cada predicado desde su secuencia de bit obtenemos los identificadores de objetos.
Figura 6.12: TerminusDB – representaci´on del grafo, recuperado de [14]
6.4. Amazon Neptune
Amazon Neptune se encuentra en el puesto 8 (junio 2021) del grupo BDoG seg´un db-engines.com.
Es una plataforma de base de datos de grafos distribuida, basada en la nube y ofrecida como SaaS. Esto trae como beneficio tareas como el mantenimiento del hardware, las aplicaciones de parches del software, instalaci´on, configuraci´on y copias de seguridad son gestionadas y administradas por Amazon.
6.4.1. Modelo de datos
Admite los modelos de grafos de propiedades y Resource Description Framework (RDF) est´andar del W3C.
6.4.2. Restricciones de integridad
Amazon Neptune no cuenta de forma predeterminada con restricciones como:
Clave (PRIMARY KEY).
Unicidad (UNIQUE).
Existencia.
Pero si tiene filtros de alto rendimiento donde indicamos que se cumplan ciertas restricciones como por ejemplo unicidad. Podemos observar en el siguiente ejemplo en los lenguajes de consultas Gremlin y Sparql, en la que insertamos una persona con la propiedad ssn con valor 123456789 y debe cumplir con la restricci´on de unicidad o clave.
Figura 6.13: Amazon Neptune – Valor ´unico de una propiedad, recuperado de [15]
Entonces sobre el ´ındice POGS (ver a continuaci´on ´ındices) donde P=ssn y O=123456780 se establece la condici´on de esas igualdades sobre P y O antes de la inserci´on y se cumple:
Si la condici´on es verdadera, no se realiza ninguna acci´on.
Si la condici´on es falsa, el bloque impide cualquier transacci´on simultanea e inserta esa propiedad.
´Indices
La unidad b´asica del grafo de Amazon Neptune es un elemento de cuatro posiciones similar a RDF.
Cu´adruple de Amazon Neptune:
Sujeto (S).
Predicado (P).
Objeto (O).
Grafo (G).
Amazon Neptune tiene 16 patrones de acceso posibles para las cuatro posiciones del cuadrante. Los patrones de accesos son ´ındices cu´adruples compuesto por sujeto (S), predicado (P), objeto (O) y grafo (G), concatenados en orden diferentes. Los 6
´ındices para filtrar son SPOG, POGS, GPSO, GSPO, OGSP y OSGP.
Los 16 patrones de acceso son:
Patr´on de acceso Restricciones Orden de las claves del ´ındice
???? Sin restricciones SPOG
SPOG Cada posici´on con restricciones SPOG
SPO? S, P y O con restricciones SPOG
SP?? S y P con restricciones SPOG
S??? S con restricci´on SPOG
?POG P, O y G con restricciones POGS
?PO? P y O con restricciones POGS
?P?? P con restricci´on POGS
?P?G P y G con restricciones GPSO
SP?G S, P y G con restricciones GSPO
S??G S y G con restricciones GSPO
???G G con restricci´on GSPO
S?OG S, O y G con restricciones OGSP
??OG O y G con restricciones OGSP
??O? O con restricci´on OGSP
S?O? S y O con restricciones OSGP
Tabla 6.1: Restricciones de los ´ındices, tabla recuperada de [15]
Amazon Neptune crea y mantiene los 3 primeros ´ındices:
SPOG clave compuesta por sujeto, predicado, objeto y grafo.
POGS clave compuesta por predicado, objeto, grafo y sujeto.
GPSO clave compuesta por grafo, predicado, sujeto y objeto.
Por ejemplo, el ´ındice SPOG permite una b´usqueda eficiente del v´ertice, por los valores de la clave o propiedad, para el ´ındice POGS permite una b´usqueda eficiente por aristas, seg´un los valores de las etiquetas o propiedades almacenadas.
6.4.3. Manejo de transacciones
Para mantener completamente la integridad de los datos y garantizar un buen comportamiento transaccional, Amazon Neptune admite las propiedades ACID.
Interfaces de consultas
Por ser un servicio alojado en la nube el acceso a los datos tiene alta seguridad con diferentes niveles: aislamiento de redes con Amazon VPC, autenticaci´on por usuario IAM7, conexiones HTTPS cifradas de clientes y el cifrado en reposo mediante un token generado por AWS Key Management Service (KMS)8.
Consola Gremlin, con diferentes lenguajes de programaci´on entre Pytohn, Ja- vascript, .NET, entre otros.
REST/ API con Gremlin.
Consulta por la web AWS permitiendo seleccionar los lenguajes Gremlin y Sparql.
Lenguaje de consultas
Amazon Neptune permite consultar sus datos de distintos lenguajes de consulta:
Sparql, que es un lenguaje para consultas de modelos RDF.
Gremlin, que es un lenguaje espec´ıfico de dominio para la gesti´on de grafos.
6.4.4. Almacenamiento de la estructura de datos
El fabricante AWS no proporciona datos sobre la estructura f´ısica de almacena- miento.
7https://docs.aws.amazon.com/es es/IAM/latest/UserGuide/introduction.html
8https://aws.amazon.com/es/kms/
6.4.5. Almacenamiento distribuido
Cuando es necesario el almacenamiento distribuido por lo general es para obtener alta disponibilidad, pero esto tambi´en implica doble esfuerzo en la mantenibilidad.
Amazon Neptune hace todo ese trabajo de forma transparente, como administrar replicas de solo lectura ofreciendo alta disponibilidad con un cl´uster primario donde se impactan las actualizaciones y las distribuye a los cl´usteres de lectura.
Adem´as, administra los recursos del hardware a la necesidad del momento, por ejemplos al necesitar mas CPU, o mas RAM se auto ajustan los valores.
Tambi´en ante un fallo Neptune tiene la capacidad de auto recuperarse.
De igual manera administra de forma aut´onomo las actualizaciones del software.
Por ´ultimo, Neptune realiza y mantiene copias de seguridad lo cual permite re- cuperar los datos a un momento dado.
Con todos lo anterior se dice que Amazon Neptune est´a completamente admi- nistrado.
Tambi´en cuenta con un monitor de rendimiento mediante Amazon CloudWatch.
Podemos observar en la Figura 6.14 una posible arquitectura de Amazon Netpune en donde un cliente se conecta a trav´es de un balanceador de carga. Tambi´en se identifican al menos dos subredes en dos zonas de disponibilidad diferentes.
Figura 6.14: Amazon Neptune – arquitectura, recuperado de [16]
7. Lenguajes de consultas BDoG
7.1. CYPHER vs GREMLIN vs SPARQL
Se seleccionaron los tres lenguajes mas populares. Cypher con base a Neo4j sien- do Neo4j pionera y la m´as popular (ver Secci´on 6.1), Sparql es el est´andar de W3C y Gremlin una herramienta que se abstrae de la base de datos.
A continuaci´on, se comparan usando sentencias simples los tres lenguajes men- cionados anteriormente. Para el lenguaje de Gremlin se debe crear un espacio de grafo que se almacena en la variable g, el paso es:
g = TinkerGraph.open().traversal()
Figura 7.1: Crear un v´ertice
Figura 7.2: Consultar un v´ertice
Figura 7.3: Crear un v´ertice y una arista
Figura 7.4: Consultar los lugares visitados por Pedro
