3.2 Bases de Datos de Grafos Distribuidas
3.2.2 Bases de Datos de Grafos Disponibles
Hoy en día, los grafos se utilizan para representar grandes entidades del mundo real (Krepska et al., 2011), tales como mapas y redes sociales. Por ejemplo, OpenStreetMap19, un reposito- rio de datos geográficos abierto mantenido por una comunidad de usuarios enorme, llegó a más de 1800 millones de nodos en el 2013. Por otro lado, Twitter ha experimentado un tremendo crecimiento, según lo informado en su declaración de registro del mercado de valores20, y en la actualidad tiene más de 300 millones de usuarios activos twitteando 500 millones de tweets por día y soporta miles de millones de relaciones de seguidores/seguidos. El amplio interés de alma-
11Página Web de Titan,http://thinkaurelius.github.io/titan/ 12Página Web de HBase,http://hbase.apache.org/
13Página Web de Cassandra,http://cassandra.apache.org/ 14Página Web de Hazelcast,http://www.hazelcast.com/
15Página Web de Blueprints,https://github.com/tinkerpop/blueprints/wiki 16Página Web de OrientDB,http://orientdb.com/orientdb/
17Página Web de ArangoDB,https://www.arangodb.com/
18Página Web de FlockDB,https://github.com/twitter/flockdb 19Página Web de OpenStreetMap,http://www.openstreetmap.org/
A
B
C
D
visitó visitóA
Visitó CompróB
C
D
visitóB
C,D
B
C
compróA
compró compróFigure 3.7: Ejemplo de representación de una base de datos de grafos.
cenar y consultar grandes gráficos ha dado lugar a una amplia gama de bases de datos NoSQL conocidas como orientado a grafos o bases de datos basadas en grafos. Estas bases de datos atacan el problema de almacenar los datos y las relaciones del grafo, permitiendo consultarlo y navegarlo de manera eficiente. De forma similar a lo que sucede con las bases de datos orien- tadas a documento (Apéndice A), no hay ninguna base de datos de grafos que puede ser utilizado como un "diseño de referencia" (a diferencia de las clave-valor o basadas en columnas).
Navegar grafos almacenados en un RDBMS es caro ya que cada movimiento a través de los ejes implica una operación de unión sobre la tabla de adyacencia. Por lo general, las bases de datos de grafos representan los datos y sus relaciones en una forma natural, es decir, usando una estructura que contiene la información del vértice y una lista de punteros a otros vértices. La Figura 3.7 muestra un ejemplo de representación de grafos en la que cada vértice se almacena junto a su lista de adyacencia, es decir, los vértices con los cuales se relaciona. Esta repre- sentación está optimizada para consultas de ejes en la dirección saliente.
Entre las bases de datos de grafos disponibles se puede encontrar a Neo4J21, InfiniteGraph22, InfoGrid23 , Hypergraph (Iordanov, 2010), AllegroGraph (Aasman, 2006) y Blazegraph. Las bases listadas son soluciones de código abierto o bases de datos distribuidas libres, considerando sólo los que prestan algún tipo de mecanismo de persistencia. Las bases analizadas se describen a continuación.
Neo4J es un proyecto de código abierto que utiliza índices de Apache Lucene24para almacenar datos de manera que el acceso a los vértices y las relaciones sea más eficiente. Neo4J también utiliza un mecanismo MVCC con una estrategiaread-commited para incremen- tar la concurrencia de lecturas y escrituras. Estas decisiones permiten el almacenamiento y acceso a millones de vértices en un solo nodo computacional. En Neo4J, el shard- ing de los vértices entre los nodos se realiza manualmente (por el usuario), utilizando los conocimientos y patrones de acceso específicos del dominio (por ejemplo, acceso por país, URL, etc.). Además, una desfragmentación periódica (reubicación de vértices) uti-
21Página Web de Neo4J,http://neo4j.com/
22Página Web de InfiniteGraph,http://www.objectivity.com/products/infinitegraph/ 23Página Web de InfoGrid,http://infogrid.org/
lizando reglas se ha propuesto, pero no implementado. 25. El acceso a un grafo Neo4J se puede realizar a través de una API de Java o lenguajes de consulta de grafos como SPARQL (Prud’Hommeaux and Seaborne, 2008) o Gremlin26. SPARQL es un lenguaje que se utiliza para consultar los datos almacenados en formato RDF (Resource Descrip- tion Framework), un modelo de datos de metadatos originalmente creado por el Consorcio World Wide Web(W3C) para describir los recursos en la Web (es decir, la adición de in- formación semántica). En general, los datos se almacenan como ternas RDF que indican un sujeto, un predicado y un objeto. Intrínsecamente, representan un grafo dirigido y eti- quetado: el vértice fuente, el tipo de relación y el vértice destino. Además de una versión gratuita, Neo4J tiene versiones empresariales que añaden monitoreo, respaldo en línea y clustering de alta disponibilidad. El módulo Neo4J que permite definir una estructura de nodos Maestro-Esclavo sólo está disponible en la versión de pago.
InfiniteGraph tiene su propio soporte de almacenamiento llamada Objectivity/DB. A diferen- cia de Neo4J, cuenta con sharding automático utilizando una "ubicación gestionada" para distribuir el grafo en un clúster. La ubicación gestionada permite al usuario definir re- glas para realizar elshardingy, por ejemplo, mantener vértices relacionados en la misma ubicación. Por desgracia, la licencia gratuita permite almacenar sólo 1 millón de ejes y vértices.
InfoGrid base de datos de grafos que se basa en estructuras conocidas como NetMeshBase, que contienen los vértices del grafo, llamada MeshObjects, y sus relaciones. Infogrid permite persistir la base de datos en un RDBMS como MySQL o PostgreSQL, o el uso de un sistema de archivos distribuido como HDFS o Amazon S3. Si se utiliza un sistema de archivos distribuido como HDFS, se pueden reusar las características de disponibilidad y escalabilidad del sistema. Además, las estructuras NetMeshBase pueden comunicarse entre sí de modo que los grafos se pueden distribuir entre los diferentes grupos.
HyperGraphDB introduce un enfoque diferente para la representación de los datos almacena- dos mediante el uso de hipergrafos. Un hipergrafo define una relación n-aria entre los diferentes vértices de un grafo. Esto reduce el número de conexiones necesarias para conectar los vértices y proporciona una manera más natural de relacionar los nodos en un grafo. Un ejemplo de un hipergrafo es la línea de frontera entre países, donde se pueden añadir nodos como Polonia, Alemania y República Checa. La base de datos sólo requiere una hypergraph que contiene estos vértices para almacenar la relación, mientras que una representación gráfica utiliza tres arcos entre los nodos. Para el almacenamiento, Hy- perGraphDB se basa en BerkeleyDB (Olson et al., 1999), proporcionando dos capas de abstracción sobre ella: una capa primitiva, que incluye un grafo de las relaciones entre los
25On sharding graph databases,http://jim.webber.name/2011/02/on-sharding-graph-databases/ 26Página Web de Gremlin,https://github.com/tinkerpop/gremlin/wiki
vértices, y una capa de modelo, que incluye las relaciones entre las capas primitivas, agre- gando índices y cachés. Estas abstracciones permiten definir diferentes interpretaciones del grafo, incluyendo RDF, OWL (una extensión de RDF que permite crear ontologías en RDF), una API Java y una API Prolog, entre otros.
Blazegraph es una base de datos RDF que escala a un gran número de vértices y aristas. Se basa en un almacenamiento de registros estructurados e índices B+, que se particionan a medida que la cantidad de datos aumenta. Para las configuraciones locales, BlazeGraph puede contener hasta 50 mil millones de vértices o arcos sin sacrificar el rendimiento. Si los vértices se distribuyen, la base de datos proporciona un sencillo mecanismo dinámico de sharding que consiste en particionar índices RDF y distribuirlos a través de diferentes nodos. Además, ofrece la posibilidad de replicar los nodos con el mecanismo maestro- esclavo. BlazeGraph ofrece una API para SPARQL y consultas RDF en C++. Esta última es una extensión de RDFS (Resource Description Framework Schema), un conjunto de clases o descripciones para la definición de ontologías en bases de datos RDF, que tiene como objetivo hacer inferencias acerca de los datos almacenados.
AllegroGraph es un almacén de tuplas RDF que soporta transacciones ACID y que es comer- cializada por una empresa llamada Franz Inc., que ofrece una versión gratuita limitada a 3 millones de ternas RDF. Como HyperGraphDB, esta base de datos tiene una amplia gama de métodos de consulta que incluyen: SPARQL, RDFS, OWL, Prolog y APIs nativas para Java, Python, C# entre otros.
Además de las bases de datos de la lista, hay otras bases de datos de dominio específico que merecen mención. Uno es FlockDB27, una base de datos de grafos desarrollado por Twitter. Se trata de una base de datos con un diseño muy simple ya que sólo almacena la lista de adyacencia de los usuarios, es decir, sus seguidos y seguidores. Entre sus características más importantes se puede mencionar sus capacidades de escalado horizontal y la capacidad de realizar sharding automático.
3. TRAB AJO RELA CION ADO Consulta Neo4J Índices en Disco (Apache Lucene por defecto)
Manual Java Java, HTTP + JSON, bindings in Ruby, Clojure, Python, among others SPARQL (RDF y OWL), Java API, Gremlin
InfiniteGraph Objectivity/DB Basado en reglas C++ C++, Java, Python and C# API para recorridos y Predicate Queries InfoGrid MySQL, HadoopFS, entre otros
Manual Java Java, HTTP + JSON Viewlets, Templates HTML, Java HypergraphDB 2 capas: Primitiva (Datos Crudos) y Modelo (relaciones + caching+ índices)
Manual Java Java Java API,
Prolog, OWL, RDF via Sesame BlazeGraph Índices (árboles B+) Sharding ”Dinámico” (por rango de claves)
Java Java y descubrimiento de servicios utilizando JDNI SPARQL, RDFS++
AllegroGraph Índices Manual Lisp HTTP + JSON y clientes en diferentes lenguajes SPARQL, Prolog, RDFS++, y una API de recorrido de grafos 206 3.2. B ASES DE D A T OS DE GRAFOS DISTRIB UID AS
Una segunda base de datos a destacar es Graphd (Meyer et al., 2010), el soporte de almace- namiento de FreeBase (Bollacker et al., 2008), una base de datos de colaboración que almacena información sobre las películas, las artes y el deporte, entre otros. Cada tupla de la base puede definir un nodo o una relación entre los nodos. Las tuplas no se sobrescriben: cuando se crea una nueva tupla la tupla modificada se marca como eliminada. Índices invertidos se utilizan para acelerar el acceso, yendo directamente a las posiciones de tuplas en la base de datos. MQL (Metaweb Query Language), un lenguaje de FreeBase análogo a SPARQL, se utiliza para con- sultar la base de datos. Graphd es un sistema propietario, por lo tanto, no se incluyó en la comparación. Sin embargo, el acceso a la API de consulta de base de datos está disponible en la Web, a través de FreeBase.
Por último, en (Sakr et al., 2014) los autores proponen una extensión a SPARQL, llamado G-SPARQL, y un enfoque de almacenamiento híbrido en el que la estructura del grafo y sus atributos se almacenan en una base de datos relacional. Las consultas sobre los atributos del gráfico se ejecutan en la base de datos relacional, mientras que las consultas topológicas se ejecutan sobre una representación en memoria. Esta estrategia evita la pérdida de rendimiento debido a la unión recursiva de las tablas, mientras que se beneficia de la eficiencia en la consulta y el almacenamiento de una base de datos relacional. Sin embargo, los autores no mencionan una variante distribuida del enfoque mencionado.
Tabla 3.1 presenta una comparación entre las bases de datos descritas anteriormente: Neo4j, InfiniteGraph, InfoGrid, hypergraph, AllegroGraph y BlazeGraph. Las bases de datos NoSQL gráfico orientada disponibles se analizan y comparan en la Tabla 3.1 a través de las siguientes dimensiones:
• Persistencia: Se refiere al método de almacenamiento de datos en los dispositivos no volátiles o persistentes. Varias alternativas son posibles, por ejemplo, índices, archivos, bases de datos y sistemas de archivos distribuidos. Otra alternativa utilizada en algunos casos es mantener los datos en la RAM y hacer periódicamente instantáneas en soportes persistentes (Malarvannan and Ramaswamy, 2010).
• Sharding: El particionado de datos o sharding es una técnica para dividir un conjunto de datos en diferentes subgrupos. Cada partición se asigna generalmente a un nodo a fin de distribuir la carga de las operaciones. Existen diferentes maneras de implementar el método de sharding. Un ejemplo sería aplicar una función de hash a los datos a almacenar y dividir el espacio dehashingen múltiples rangos, cada uno representando una partición. Otro ejemplo es el uso de un campo particular del esquema de datos para realizar partición. Una base de datos que soporta la gestión automática delshardingpermite desacoplar al desarrollador de los detalles de la topología de la red, incluyendo el soporte para agregar o eliminar nodos de la red. Por lo tanto, elshardingcrea la ilusión de un único nodo, mientras que, de hecho, hay un gran conjunto de nodos. En este análisis, la dimensiónSharding indica si la base de datos admite sharding y cómo se puede configurar. Si el sharding no está integrado en la funcionalidad de base de datos,
el cliente tiene que lidiar con la partición de datos entre nodos.
• Lenguaje de Implementación: Describe el lenguaje de programación la base de datos se implementa con. En algunos casos, puede indicar una preferencia de los desarrolladores de base de datos para una tecnología requerida particular.
• API: Se refiere al tipo de interfaz de programación utilizado para acceder a la base de datos. En general, las bases de datos NoSQL en la era de la Web permiten el acceso a través del protocolo HTTP. Sin embargo, el acceso a una base de datos utilizando un cliente HTTP es engorroso para el desarrollador y, por ello, es común encontrar clientes nativos en ciertos lenguajes de programación. Esta dimensión enumera los lenguajes de programación que tienen los clientes nativos para la base de datos. Además, se indica el formato de mensaje que se utiliza para añadir o modificar los elementos de la base de datos.
• Método de consulta: Se describen los métodos de acceso a la base de datos y se enumeran las diferentes formas de acceder a estos métodos a través de la API. Esta dimensión indica las estrategias o lenguajes de consulta que soporta cada base de datos.