Introducción a las bases de datos NoSQL en grafo

Las bases de datos NoSQL ya no son una novedad sino una realidad que encontramos en muchas de las aplicaciones que utilizamos diariamente. En el pasado habíamos comentado las características de este tipo de bases de datos y su evolución. A diferencia de las bases de datos relacionales, las bases de datos NoSQL no responden a un único modelo de datos, sino a un conjunto de ellos. Actualmente existen centenares de sistemas gestores de bases de datos NoSQL, en general muy distintos entre sí. En aras de favorecer la discusión y su comparación, los sistemas gestores de bases de datos NoSQL se clasifican en diferentes familias: los basados en modelos de agregación (que se pueden agrupar en clave-valor, documental o de grandes columnas) y los basados en grafo. Con este post queremos dar inicio a una serie de entradas que sirvan de tutorial a quienes quieran aprender a utilizar bases de datos NoSQL.

En esta primera entrada, empezaremos viendo qué es una base de datos en grafo, qué modelo de datos permiten gestionar estas bases de datos y mostraremos algún ejemplo de uso. En las siguientes entradas aprenderemos a utilizar Neo4j, la base de datos en grafo de uso más extendido en la actualidad, según dbengines, y veremos algunos casos prácticos.

Las bases de datos NoSQL en grafo permiten representar los datos utilizando estructuras de grafos. Un grafo es una representación abstracta de un conjunto de objetos. Los objetos de los grafos se representan mediante vértices (también llamados nodos) y aristas.

El modelo en grafo es útil cuando los datos a almacenar tienen multitud de interrelaciones entre sí, y cuando la importancia recae más en las interrelaciones que se establecen entre los datos, que en los propios datos en sí. En consecuencia, este tipo de bases de datos tiende a almacenar pocos datos de los objetos del mundo real que se desean representar pero muchos datos sobre sus interrelaciones, a diferencia de lo que acostumbra a suceder en las bases de datos relacionales, donde hay muchos datos de los objetos (representados mayoritariamente en las propiedades o atributos de las relaciones) y pocas interrelaciones entre los objetos (representadas mediante claves foráneas). Como ejemplo, pensemos en un tweet. En este contexto, un tweet relevante no se mide en función de su contenido (el texto) sino en función de las interrelaciones que se establecen sobre él: cuántas veces lo han reenviado (retweeted), cuántas veces lo han respondido, quiénes son los seguidores del autor del tweet, etc.

Si recordamos nuestras clases de matemática discreta -los de la vieja escuela-, sabemos que hay distintos tipos de grafo en función de sus características y de los elementos que contienen. Los modelos NoSQL en grafo no siguen todos el mismo modelo de grafo. No obstante, quizás, el modelo más utilizado sea el modelo de grafo dirigido con propiedades y etiquetado. En este caso, el grafo estaría compuesto de nodos, aristas, etiquetas y propiedades. Los nodos o vértices nos permitirán representar conceptos generales u objetos del mundo real. Vendrían a ser el equivalente a las relaciones en el modelo relacional. Las aristas o arcos son relaciones dirigidas que nos permite relacionar los nodos. Las aristas representan interrelaciones entre objetos del mundo real y serían el equivalente a las claves foráneas en el modelo relacional o a las asociaciones en los diagramas de clases de UML.

En el modelo en grafo los nodos y las aristas se pueden etiquetar. Normalmente, las etiquetas en los nodos y en las aristas se utilizan para indicar de qué tipo son, es decir, su semántica. Por tanto, si tuviéramos un conjunto de nodos que representan tweets y otro conjunto de nodos que representan usuarios de Twitter, etiquetaríamos todos los tweets con la etiqueta “Tweet” y los usuarios con la etiqueta “TwitterUser”. Por otro lado, para proveer de semántica a las distintas relaciones, podríamos crear etiquetas para indicar que un tweet ha sido escrito por un usuario “Author” o que un tweet es respuesta a otro tweet “Reply”.

A continuación podemos ver un ejemplo simple en el que hemos creado un grafo con dos tweets (en color verde) y dos usuarios de Twitter (en color azul). Como vemos, los tweets y los usuarios se han etiquetado con las etiquetas “Tweet” y “TwitterUser” para indicar su tipo. Vemos también que uno de los tweets es un reply (se indica mediante una relación con una etiqueta “Reply”) y que los dos usuarios de Twitter se siguen mútuamente (se indica mediante la etiqueta “Follows”). También se indican los autores de cada tweet (mediante la etiqueta “Author”).

Asimismo, se han definido distintas propiedades en los tweets de ejemplo. Una propiedad es una pareja <clave, valor> que se asigna a un elemento del modelo. La clave es una cadena de caracteres que indica la semántica de la propiedad, mientras que el valor puede responder a un conjunto de tipos de datos predefinidos. En el caso de ejemplo tenemos las propiedades “text” para representar el texto del tweet y “date” para indicar la fecha en que se creó. También tenemos un par de propiedades para indicar el nombre de usuario de Twitter y su idioma por defecto.

La representación gráfica anterior no deja de ser una representación teórica, pero no dista mucho de la manera en que se almacenan, se muestran y se gestionan los datos en las bases de datos en grafo. En la siguiente imagen podéis ver el fragmento del ejemplo anterior implementado en la base de datos en grafo Neo4j.

Ahora que ya sabemos qué aspecto tienen los datos en una base de datos en grafo, es el momento de plantearnos cuáles son sus principales características y qué ofrecen respecto a una base de datos relacional clásica. Como característica principal, este tipo de bases de datos representa las interrelaciones de forma explícita en la base de datos. Eso quiere decir que las interrelaciones entre los distintos nodos del grafo se almacenan en el disco como punteros entre los dos nodos relacionados. Eso suele simplificar la recuperación de elementos relacionados y permite una mayor eficiencia que en los modelos relacionales cuando consultamos datos altamente relacionados. Eso es debido a que, en el modelo relacional, las interrelaciones entre datos están representadas de forma implícita (mediante claves foráneas) y requieren ejecutar operaciones de combinación (en inglés, join) para calcularlas. En cambio, en las bases de datos en grafo, las interrelaciones están definidas de forma explícita y sólo hay que navegar por ellas.

Por otro lado, las bases de datos en grafo son también schemaless, es decir, son mucho menos sensibles (o si preferís, son más flexibles) a los cambios en el esquema de datos (en comparación a una base de datos relacional). Como consecuencia, este modelo permite añadir nuevos tipos de nodos y aristas fácilmente, y sin realizar cambios en el esquema. A pesar de ello, es conveniente hacerlo de forma ordenada y planificada, para evitar añadir tipos de relaciones o nodos redundantes o mal etiquetados.

Uno de los problemas de los modelos en grafo es que no son tan fácilmente escalables como otros modelos NoSQL. Como los datos están altamente relacionados, particionarlos entre diferentes ordenadores debe hacerse con mucho cuidado para no “romper” relaciones entre los datos. Por este hecho, la distribución de datos en estos modelos es compleja y requiere de mucha información del dominio (qué datos se van a almacenar, cómo se van a consultar, desde qué puntos, qué patrones de acceso se van a seguir, etc.) para realizarse de forma correcta. De hecho, la problemática descrita es similar a los problemas de escalabilidad horizontal que potencialmente presentan las bases de datos relacionales.

Hasta aquí esta introducción a los modelos NoSQL en grafo. Podéis visualizar el siguiente vídeo en el caso de que queráis obtener más información. Ahora que ya conocemos los principios básicos de este tipo de bases de datos, en un par de semanas continuaremos viendo las principales características de Neo4j, aprendiendo su lenguaje de manipulación de datos CYPHER y creando nuestra primera base de datos en Neo4j. Os esperamos…

 

Jordi Conesa es profesor de los Estudios de Informática, Multimedia y Telecomunicación en la UOC y coordinador del ámbito de data science del eHealth Center. Su docencia se enfoca a las áreas de bases de datos, ciencia de datos e ingeniería del software y su investigación en el análisis de datos y el eLearning.

Elena Rodríguez es profesora de los Estudios de Informática, Multimedia y Telecomunicación de la UOC y forma parte del proyecto TeSLA, participando en tareas que se centran en el diseño del sistema TeSLA y en el desarrollo de pruebas piloto en la UOC. Licenciada en Informática por la Universitat Politècnica de Catalunya y doctora por la Universidad de Alcalá, sus áreas de conocimiento e investigación incluyen las bases de datos y la ingeniería de ontologías para el desarrollo de sistemas de e-learning basados en estándares.

2 Comments

  1. Gran article!!

    Reply
  2. Gràcies Xavi pel teu comentari! La setmana vinent continuem, veient com instal·lar i començar a “jugar” amb Neo4j 😉

    Reply

Comentar

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Leer entrada anterior
Wikipedia como laboratorio de investigación

Wikipedia es, sin lugar a duda, el mayor esfuerzo colaborativo realizado por la humanidad. Aunque no necesite presentación, podemos destacar...

Cerrar