ARQUITECTURA DE UN REPOSITORIO RDF BASADO EN
arriba, tendría la siguiente respuesta: (?X=elPrado, ?Y=localizadoEn) y (?X=wwwInternet2012,
?Y=celebradoEn). Una pregunta más compleja podría estar formada por varios patrones; por ejemplo <?X, rdf:type, Museo> AND <?X, localizadoEn, ?Y >, en los que la igualdad del nombre de una variable representa un equi-join. En este caso la respuesta sería (?X=elPrado, ?Y=madrid).
Aunque los triples RDF pueden almacenarse de forma simple, en una tabla con tres atributos para sujeto, predicado y objeto, se ha constatado que ese almacenamiento adolece de graves problemas de rendimiento ya que el procesamiento de consultas, en general, necesitará de muchas operaciones de auto-join y, además, tendrá problemas de escalabilidad con el crecimiento del tamaño de la tabla. Existen, además de esta, muchas otras aproximaciones para el almacenamiento de datos RDF, que se explican más en detalle en la sección 2.
Entre las existentes nuestra propuesta sigue un enfoque basado en el particionamiento vertical (orientado a la columna) de los datos [Abadi, J. et al, 2009], ya que para el modelo de datos de Cassandra (orientado a la columna) es el más adecuado, además ha demostrado en general uno de los mejores rendimientos.
En Cassandra4 una columna es un par clave: valor. A una colección de columnas, ordenada por clave, se denomina fila y se accede a ella mediante una clave-de-fila. Lo expresamos así: fila: {clave-de-columna: valor}}. Una familia de columnas es un contenedor de filas de la misma clase. En Cassandra, cada familia de columnas recibe un nombre y queda almacenada en un fichero ordenado por clave-de-fila. Un espacio de claves es el contenedor más externo en Cassandra y es una colección de familias de columnas.
Cassandra ofrece, además, una nueva estructura denominada columna compuesta (composite-column), que permite que las claves de fila y las claves de columna puedan estar compuestas de varias partes. Lo expresamos así: {[clave-de-fila1,…, clave-de-filaM]: {[clave-de-columna1,… clave-de-columnaN]: valor}}.
Gracias a eso, es posible realizar búsquedas mediante índices sobre esas partes de las claves.
Las contribuciones de nuestra propuesta son, por tanto, las siguientes:
¾ Un mecanismo de persistencia de datos RDF sobre la base de datos Cassandra, manteniendo las características de escalabilidad y distribución.
¾ Una API para desarrollar las tareas de carga, consulta y manipulación de datos sobre este mecanismo.
¾ Los resultados obtenidos durante las pruebas de nuestro sistema en un cluster de alta prestaciones mediante el benchmark LUBM.
2. TRABAJOS RELACIONADOS
Los sistemas de gestión de datos RDF han ido evolucionando desde simples ficheros de texto, pasando por sistemas de gestión de esquemas/datos relacionales, hasta sistemas distribuidos que gestionan elaboradas estructuras de datos basadas en representación de grafos. A continuación presentamos una clasificación de los mismos en cinco grandes grupos:
• Almacenamiento Triple store: basado en una gran tabla formada por tres columnas, correspondientes a sujeto-predicado-objeto. Muy utilizado en sistemas con persistencia mediante BD relacionales como Sesame [Broekstra, J. et al, 2002]. Otros enfoques más modernos son Hexastore[Weiss, C. et al, 2008] o RDF-3x5, que añaden estructuras de índices.
• Almacenamiento Property Table: agrupan los predicados que tienden a estar definidos sobre la misma clase de sujetos como atributos de una tabla relacional. Jena TDB6 es un ejemplo.
• Almacenamiento Vertical Partitioning: en el que se define una tabla de dos columnas, representando sujeto y objeto, por cada predicado de la fuente de datos. Este sistema fue promovido por Abadi et al [Abadi, J. et al, 2009] y es el utilizado en nuestra propuesta.
• Almacenamiento basado en grafos: basados en estructuras de datos que representan grafos, residentes en memoria principal, que aprovechan las posibilidades de compresión. Por ejemplo BitMat [Atre, M. et al, 2009].
• Aproximaciones híbridas, como puede ser Openlink Virtuoso7, que mezcla RDBMS, ORDBMS y servidores de ficheros o 4Store que es un repositorio RDF distribuido.
4 APACHE CASSANDRA - http://cassandra.apache.org/
5 RDF-3x - http://www.mpi-inf.mpg.de/~neumann/rdf3x/
6 Jena TDB - http://jena.apache.org/documentation/tdb/index.html
7
3. ARQUITECTURA Y MODELO DE DATOS
En la figura 1 mostramos la arquitectura de nuestro sistema. El elemento principal es el mecanismo de persistencia basado en un cluster de Cassandra, que es el que nos ofrece las características de distribución y escalabilidad, las cuales constituyen el principal beneficio de nuestro repositorio frente a otras opciones.
Entre los nodos que lo forman, se distribuyen los diferentes triples que componen el dataset RDF a almacenar. Utilizando el modelo de datos ofrecido por Cassandra, se pueden perfilar diferentes layout de almacenamiento. En nuestro sistema, se ha optado por tres estructuras de almacenamiento formadas mediante columnas compuestas por distintos campos. Cada una de estas estructuras almacena una posible conmutación de los recursos que forman los diferentes triples (SPO, POS, OSP), se ha elegido esta forma de representación debido a que es la que mejor optimiza el rendimiento en la utilización y el acceso a las estructuras propias de Cassandra.
Estas estructuras pueden dar solución a los diferentes patrones simples de preguntas (al referirnos a un patrón simple estamos indicando un triple en el que cualquiera de sus recursos puede ser variable). En el caso de la estructura SPO, adecuado para los patrones <s ?X ?Y> y <s p ?X>, la estructura se muestra también en la figura 1, donde el sujeto es la denominada clave-de-fila, y los predicados y objetos forman la “composite-column” y tienen el papel de claves de columnas. Con esto se consigue un nivel doble de indexación, donde el sujeto es el primer índice y la combinación predicado-objeto compone un segundo índice. En la misma figura 1, describimos las estructuras POS para patrones (<?X p ?Y> y <?X p o>) y OSP para patrones (<?X
?Y o> y <s ?X o>).
Figura 1. Arquitectura Cassandra RDF y estructuras “composite-column”
Por encima del elemento de almacenamiento nos encontramos con una API que gestiona las operaciones de carga, consulta y manipulación, así como la operación de inferencia. Para esta última operación hemos integrado Hadoop (framework para la paralelización) con Cassandra y sobre él hemos ejecutado el algoritmo de inferencia descrito en [Urbani et al. 2010]. El resultado de la inferencia se materializa en las estructuras diseñadas para el almacenamiento en Cassandra. Por último nos encontramos con un módulo destinado a la optimización de las consultas, que se compone de un analizador léxico, planificador y optimizador de consultas. Este módulo está siendo diseñado y desarrollado actualmente y su objetivo es mejorar aún más los tiempos de respuesta obtenidos.
4. RESULTADOS
El entorno de ejecución de las pruebas ha sido el cluster de altas prestaciones Arina8, del que se han utilizado 6 nodos, cada uno de los cuales tiene las siguientes características: dos procesadores con 8 cores de tipo 2.4 GHz Xeon 5645, 48 GB RAM y 250 GB de disco duro. El benchmark LUBM [Guo Y. et al, 2005], esta compuesto por un generador de datos sintéticos y una batería de 14 preguntas SPARQL, ha sido elegido
8 ARINA/EHU - http://www.ehu.es/sgi/recursos/cluster-arina
como dataset sintético por ser uno de los mas comúnmente utilizado, en él se han seleccionado dos preguntas (Q1 y Q3) entre la batería ofrecida, para la medición de tiempos de respuesta en función de la escalabilidad del dataset. Todas las medidas se encuentran en microsegundos.
Tabla 1. Resultados de Cassandra RDF con benchmark LUBM.
Tiempo de respuesta en microsegundos Dataset y nº aprox.
de triples
Lubm1 (103 K )
Lubm5 (646 K)
Lubm10 (1,32 m)
Lubm20 (2,78 m)
Lubm50 (6,89 m) Q1 Cassandra (s) 0,145760 0,364198 0,404731 0,452561 0,675441 Q3 Cassandra (s) 0,206002 0,389476 0,452258 0,509651 0,708752
Los resultados para la preguntas pueden verse en la tabla 1. En relación a las pruebas referentes a la inferencia, podemos indicar que para un dataset de gran tamaño como es Uniprot (850 millones triples) el tiempo necesario ha sido de 20 horas y 40 minutos, duplicando la salida de la inferencia el tamaño del dataset (aprox. 1800 millones de triples inferidos). Se puede observar en las pruebas como nuestra implementación ofrece escalabilidad en un entorno distribuido, siendo capaz de dar respuesta aun tamaño cada vez mayor del dataset, viéndose los tiempos de respuesta poco afectados por el incremento en el tamaño.
5. CONCLUSIÓN Y TRABAJOS FUTUROS
En este artículo hemos presentado brevemente las posibilidades y beneficios de gestionar datos RDF usando una base de datos NoSQL, como Cassandra. Teniendo en cuenta las limitaciones que presentan los sistemas actuales que gestionan datos RDF aportamos un nuevo enfoque, integrando las ventajas de las bases de datos NoSQL a las características de los repositorios RDF ya existentes. Nuestro sistema está diseñado para gestionar datasets RDF de gran tamaño orientados a la consulta de los datos e incorpora además la posibilidad de materializar la inferencia, manteniendo un rendimiento eficiente en tiempos. Como trabajos a futuro, en primer lugar pensamos realizar una comparativa de nuestro sistema con los actuales repositorios RDF existentes en el mercado, utilizando diferentes benchmark (tanto reales como sintéticos), con el objetivo de descubrir nuevos puntos de mejora. Además ya hemos detectado la necesidad de un mecanismo de gestión de preguntas más complejo que incorpore un planificador y optimizador, para entornos en los que sea necesario trabajar con consultas analíticas muy complejas. Estos nuevos desarrollos nos permitirían, en un futuro, poder ofrecer al usuario una herramienta completa y eficiente para cualquier consulta y volumen de datos.
REFERENCIAS
Abadi, J. et al, 2009. SW-Store: a vertically partitioned DBMS for Semantic Web data management. The VLDB Journal
— The International Journal on Very Large Data Bases Volume18 Issue2, Pages 385 - 406
Arias, M. et al, 2011. An empirical Study of Real-World SPARQL Queries. 1st International Workshop on Usage Analysis and the Web of Data (USEWOD2011) in the 20th International World Wide Web Conference (WWW2011).
Hyderabad, India, March 28th, 2011
Atre M. et al, 2009. Bitmat: An in-core rdf graph store for join processing. Rensselaer Polytechnic Ins. Technical Report Berners-Lee T., 2006. Linked Data-Design Issues. http://www.w3.org/DesignIssues/LinkedData.html
Broekstra, J. et al, 2002. Sesame: A Generic Architecture for Storing and Querying RDF and RDF Schema. The Semantic Web — ISWC 2002.Lecture Notes in Computer Science Springer Berlin / Heidelberg
González, M.et al, 2008. Semantic framework for complex knowledge domains. Proceedings of ISWC200, Germany Guo Y. et al, 2005. Lubm: A benchmark for owl knowledge base systems. Web Semantic.3:158-182, October,2005 Ladwig, G. et al, 2011. CumulusRDF: Linked Data Management on Nested Key-Value Stores. In SSWS,2011.
Urbani, J. et al, 2010. OWL Reasoning with WebPIE: Calculating the Closure of 100 Billion Triples. Lecture Notes in Computer Science, Volume 6088/2010
Weiss, C. et al, 2008. Hexastore: sextuple indexing for semantic web data management. Proceedings of the VLDB Endowment Volume 1 Issue 1.Pages 1008-1019