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 utilizarNeo4j, 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.