1. UNIVERSIDAD SIMON BOL´
´ IVAR
Ingenier´a de Computacion
ı ´
Desarrollo de un optimizador de consultas en SPARQL para la Nube
Enlazada de Datos.
Por
Mireya Gonz´ lez, Jos´ Riera
a e
Proyecto de Grado
Presentado ante la Ilustre Universidad Simon Bol´var
´ ı
como Requerimiento Parcial para Optar el T´tulo de
ı
Ingeniero en Computacion
´
Sartenejas, Mayo de 2011

4. Desarrollo de un optimizador de consultas en SPARQL para la Nube
Enlazada de Datos.
Por
Mireya Gonz´ lez, Jos´ Riera
a e
RESUMEN
La Nube Enlazada de Datos es un gran repositorio de billones de tripletas de datos, en
formato RDF, que est´ n enlazadas entre s´. Debido a la variedad y cantidad de los datos
a ı
almacenados en la Nube, la consulta y an´ lisis de los datos se ha convertido en una tarea
a
rutinaria para un gran numero de usuarios. Dado que el problema de evaluar una consulta
´
depende del tamano de los datos, se hace necesario identificar un plan que permita
˜
ejecutar consultas contra documentos de la Nube Enlazada de Datos, de manera eficiente.
Indiferentemente si el almacenamiento de los datos es en una m´ quina local o en La Nube
a
Enlazada de Datos, el problema de identificar planes eficientes es complejo y costoso. En
este trabajo, se propone desarrollar un optimizador, llamado COneQL, para consultas en
SPARQL, lenguaje para consultar documentos RDF, que produzca planes de ejecucion
´
eficientes, m´ s espec´ficamente para consultas complejas, a nivel local. La complejidad de
a ı
una consulta viene dada por la cantidad de resultados intermedios generados y la cantidad
de patrones que posea la misma. El optimizador implementado recibe una consulta en
SPARQL, la procesa, y a trav´ s de ciclos de generacion de planes iniciales, aplicacion
e ´ ´
de transformaciones y comparacion de costos estimados entre planes, produce un plan
´
de ejecucion eficiente. Para estudiar emp´ricamente la calidad de los planes generados,
´ ı
se llevo a cabo un estudio experimental de dos fuentes de datos, YAGO y LinkedCT,
´
con bancos de prueba que comprenden consultas sencillas y otras m´ s complejas. Los
a
resultados obtenidos demuestran que el optimizador puede producir planes eficientes en
comparacion a otros manejadores existentes.
´
ii

5. Agradecimientos
A mi familia, por ser un apoyo incondicional siempre, sin importar las decisiones que
tome o en el momento en que me encuentre. Gracias.
A la Profesora Mar´a Esther Vidal, por darnos esta enorme oportunidad, la gran gu´a
ı ı
que nos d´a a lo largo de este proyecto y la disposicion que siempre tuvo para ayudarnos
ı ´
en los momentos dif´ciles.
ı
A mi companero Jos´ , por compartir este ano de sacrificio y trabajo conmigo, el cual
˜ e ˜
permitio el realizar un gran trabajo.
´
A mis amigos, por estar conmigo y vivir, no solo este ano, sino toda la carrera a mi
´ ˜
lado d´ ndome animos y compartiendo.
a
A Edgar, por el apoyo que me ha brindado siempre, sin importar la situacion o el
´
momento y por haberme acompanado a lo largo de este camino.
˜
A la Profesora Edna Ruckhaus, por su observaciones y apoyo en estos 12 meses de
trabajo.
Mireya Gonz´ lez Arreaza
a
iii

6. A la Profesora Mar´a Esther Vidal por su extraordinaria guiatura acad´ mica, por su
ı e
gran vocacion profesoral, por su eterna disponibilidad y compromiso a cualquier duda
´
durante el desarrollo de este proyecto y por sus grandes cualidades humanas que siempre
nos brindo.
´
A Mireya Gonz´ lez por su confianza en m´ como companero de trabajo para que,
a ı ˜
hace un ano atr´ s, nos embarc´ ramos en este largo viaje que, con grandes sacrificios, ha
˜ a a
culminado con muchos frutos.
A mi madre, Janette S´ nchez, por su eterno e invaluable apoyo en los momentos
a
dif´ciles y por disfrutar conmigo los buenos momentos. Por nunca dejar creer en m´.
ı ı
A mi padre, Jos´ Riera que empezo f´sicamente conmigo esta aventura y que, a pesar
e ´ ı
de no estar con nosotros, nunca dej´ de sentir sus consejos y palabras de aliento donde
e
sea que est´ .
e
A mis familiares y amigos que directa o indir´ ctamente contribuyeron en mi formacion
e ´
acad´ mica y como persona.
e
A la profesora Edna Ruckhaus por sus siempre oportunas observaciones y contribu-
ciones al crecimiento, evolucion y refinamiento de este trabajo de grado.
´
Al MAC, mi segunda casa durante mis anos en la universidad, y donde me encontr´ y
˜ e
compart´ con muchos amigos decepciones y alegr´as.
ı ı
Jos´ H. Riera
e
iv

7. ´
Indice general
Agradecimientos iii
´
Indice general v
´
Indice de tablas ix
´
Indice de figuras x
Glosario de T´ rminos
e xi
Cap´tulo 1. Introduccion
ı ´ 1
Cap´tulo 2. Marco Teorico
ı ´ 3
2.1. Web Sem´ ntica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
a 3
2.1.1. Universal Resource Identifier . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.2. Resource Description Framework . . . . . . . . . . . . . . . . . . . . 4
2.1.3. SPARQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.4. Nube Enlazada de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.5. Puntos de Acceso de SPARQL . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Componentes para ejecutar consultas contra datos RDF . . . . . . . . . . . . 7
2.2.1. M´ quinas de Ejecucion . . . . . . . . . . . . . . . . . . . . . . . . . . .
a ´ 7
2.2.2. Optimizador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3. Sistemas Manejadores de Documentos RDF . . . . . . . . . . . . . . . . . . . 14
2.3.1. OneQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.2. RDF-3X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.3. Berkeley DB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Cap´tulo 3. An´ lisis del Problema
ı a 18
3.1. Ejemplo Motivador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
v

8. 3.2. Formalizacion del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
´
3.3. Complejidad del Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Cap´tulo 4. Diseno de la Solucion
ı ˜ ´ 22
4.1. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.1. Parser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.2. Optimizador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.3. Modelo de Costos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1.4. Cat´ logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
a
4.1.5. Estructuras para almacenar documentos RDF . . . . . . . . . . . . . 25
4.2. Diseno de COneQL version 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
˜ ´
4.3. Diseno de COneQL version 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
˜ ´
4.4. Diseno de COneQL version 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
˜ ´
4.5. Diseno de COneQL version 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
˜ ´
Cap´tulo 5. Implementacion
ı ´ 31
5.1. COneQL version 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
´
5.2. COneQL version 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
´
5.3. COneQL version 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
´
5.4. COneQL version 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
´
Cap´tulo 6. Experimentacion
ı ´ 39
6.1. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.2. Procedimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.3. M´ tricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
e
6.4. Configuracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
´
6.5. Fuentes de Datos y Bancos de Pruebas . . . . . . . . . . . . . . . . . . . . . . 41
6.6. Experimento I - Cold Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.6.1. Experimentos sobre LinkedCT . . . . . . . . . . . . . . . . . . . . . . 43
vi

9. 6.6.2. Experimentos sobre YAGO . . . . . . . . . . . . . . . . . . . . . . . . 44
6.7. Experimento II - Warm Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.7.1. Experimentos sobre LinkedCT . . . . . . . . . . . . . . . . . . . . . . 46
6.7.2. Experimentos sobre YAGO . . . . . . . . . . . . . . . . . . . . . . . . 47
6.8. Tiempos de Optimizacion y Total de Ejecucion . . . . . . . . . . . . . . . . . 49
´ ´
6.8.1. Experimento sobre LinkedCT . . . . . . . . . . . . . . . . . . . . . . . 49
6.8.2. Experimento sobre YAGO . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.9. An´ lisis de Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
a
6.10. Ventajas y Desventajas de los Optimizadores . . . . . . . . . . . . . . . . . . 55
6.10.1. COneQL version 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
´
6.10.2. COneQL version 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
´
6.10.3. COneQL version 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
´
6.10.4. COneQL version 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
´
Cap´tulo 7. Conclusiones
ı 57
7.0.5. Aportes Realizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.0.6. Direcciones Futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Bibliograf´a
ı 60
Ap´ ndice A. Detalle del Marco Teorico
e ´ 63
A.1. Web Sem´ ntica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
a
A.1.1. Resource Description Framework (RDF) . . . . . . . . . . . . . . . . . 64
A.1.2. SPARQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
A.1.3. Nube Enlazada de Datos (Linked Data) . . . . . . . . . . . . . . . . . 65
Ap´ ndice B. Reglas de Transformacion
e ´ 68
Ap´ ndice C. Otros Trabajos Relacionados
e 69
C.1. Arquitectura de OneQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
vii

10. C.2. Otros Manejadores de Documentos RDF . . . . . . . . . . . . . . . . . . . . . 69
Ap´ ndice D. Complejidad del Problema
e 71
Ap´ ndice E. Algoritmos Implementados
e 72
E.1. Simulated Annealing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
E.2. Muestreo Adaptativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Ap´ ndice F. Configuracion de experimentos
e ´ 74
F.1. Especificaciones de las M´ quinas de Pruebas . . . . . . . . . . . . . . . . . . 74
a
F.2. Descripcion de Bancos de Pruebas (Benchmarks) . . . . . . . . . . . . . . . . . 74
´
F.3. Consultas en SPARQL de los bancos de prueba . . . . . . . . . . . . . . . . . 77
F.3.1. Consultas del banco de prueba de LinkedCT . . . . . . . . . . . . . . 77
F.3.2. Consultas del banco de prueba de YAGO . . . . . . . . . . . . . . . . 80
F.4. Configuracion Inicial de Experimentacion . . . . . . . . . . . . . . . . . . . . 82
´ ´
Ap´ ndice G. Graficas de resultados experimentales
e 84
G.1. Cold Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
G.1.1. Experimento sobre LinkedCT . . . . . . . . . . . . . . . . . . . . . . . 84
G.1.2. Experimento sobre YAGO . . . . . . . . . . . . . . . . . . . . . . . . . 85
G.2. Warm Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
G.2.1. Experimento sobre LinkedCT . . . . . . . . . . . . . . . . . . . . . . . 86
G.2.2. Experimento sobre YAGO . . . . . . . . . . . . . . . . . . . . . . . . . 88
G.3. Tiempos de Optimizacion y Total de Ejecucion . . . . . . . . . . . . . . . . . 89
´ ´
G.3.1. Experimento sobre LinkedCT . . . . . . . . . . . . . . . . . . . . . . . 89
G.3.2. Experimento sobre YAGO . . . . . . . . . . . . . . . . . . . . . . . . . 92
viii

11. ´
Indice de tablas
6.1. Tiempos de ejecucion en cold cache en LinkedCT . . . . . . . . . . . . . . . . 43
´
6.2. Tiempos de ejecucion en cold cache en YAGO . . . . . . . . . . . . . . . . . . 44
´
6.3. Tiempos de ejecucion en warm cache en LinkedCT . . . . . . . . . . . . . . . 46
´
6.4. Tiempos de ejecucion en warm cache en YAGO . . . . . . . . . . . . . . . . . 48
´
6.5. Tiempos de optimizacion sobre LinkedCT . . . . . . . . . . . . . . . . . . . . 50
´
6.6. Suma de tiempos de optimizacion y ejecucion en LinkedCT . . . . . . . . . 51
´ ´
6.7. Tiempos de optimizacion sobre YAGO . . . . . . . . . . . . . . . . . . . . . . 53
´
6.8. Suma de tiempos de optimizacion y ejecucion en YAGO . . . . . . . . . . . . 54
´ ´
F.1. Especificaciones de las estaciones de experimentacion . . . . . . . . . . . . . 74
´
F.2. Factores de construccion de los benchmarks . . . . . . . . . . . . . . . . . . . 75
´
F.3. Benchmark 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
F.4. Benchmark 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
F.5. Par´ metros Iniciales de Experimentacion . . . . . . . . . . . . . . . . . . . . 82
a ´
F.6. Probabilidades de las reglas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
ix

12. ´
Indice de figuras
2.1. Ejemplo de una tripleta RDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Arquitectura de un Manejador de Base de Datos . . . . . . . . . . . . . . . . 7
2.3. Representacion del arbol logico . . . . . . . . . . . . . . . . . . . . . . . . . .
´ ´ ´ 8
´
2.4. Forma de Arboles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5. Grupo estrella unido por la variable ?A . . . . . . . . . . . . . . . . . . . . . 10
2.6. Formulas usadas en el Sistema R . . . . . . . . . . . . . . . . . . . . . . . . . 12
´
3.1. Consultas optimizadas por RDF-3X y OneQL . . . . . . . . . . . . . . . . . . 19
3.2. Plan de ejecucion RDF-3X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
´
3.3. Plan Optimizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1. Arquitectura del manejador de documentos RDF . . . . . . . . . . . . . . . . 22
4.2. Arquitectura del Parser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3. Esquema de las Bases de Datos de BerkeleyDB . . . . . . . . . . . . . . . . . 25
4.4. Estructuras del optimizador COneQL v1 . . . . . . . . . . . . . . . . . . . . . 26
4.5. Plan inicial, optimizador COneQL v1 . . . . . . . . . . . . . . . . . . . . . . . 27
4.6. Estructuras del optimizador COneQL v3 . . . . . . . . . . . . . . . . . . . . . 29
4.7. Estructuras del optimizador COneQL v4 . . . . . . . . . . . . . . . . . . . . . 30
5.1. Diagrama de clases para la primera solucion . . . . . . . . . . . . . . . . . . 31
´
5.2. Diagrama de clases para tercera solucion . . . . . . . . . . . . . . . . . . . . 36
´
5.3. Diagrama de clases para la ultima solucion . . . . . . . . . . . . . . . . . . . 38
´ ´
5.4. Nueva formacion de grupos estrellas . . . . . . . . . . . . . . . . . . . . . . . 38
´
6.1. Tiempos de ejecucion de consultas complejas en LinkedCT . . . . . . . . . . 43
´
6.2. Tiempo de ejecucion de consultas complejas en YAGO . . . . . . . . . . . . . 45
´
6.3. Tiempo de ejecucion de consultas complejas en LinkedCT . . . . . . . . . . . 47
´
6.4. Tiempo de ejecucion de consultas complejas en YAGO . . . . . . . . . . . . . 48
´
6.5. Tiempo de optimizacion de consultas complejas en LinkedCT . . . . . . . . 50
´
6.6. Tiempo de ejecucion total de consultas complejas en LinkedCT . . . . . . . . 51
´
x

13. 6.7. Tiempo de optimizacion de consultas complejas en YAGO . . . . . . . . . . 53
´
6.8. Tiempo de ejecucion total de consultas complejas en YAGO . . . . . . . . . . 54
´
A.1. Arquitectura de la Web Sem´ ntica [30] . . . . . . . . . . . . . . . . . . . . . . 64
a
A.2. Crecimiento de La Nube de Datos Enlazados [9] . . . . . . . . . . . . . . . . 66
A.3. Nube de Datos Enlazados (actualmente) [9] . . . . . . . . . . . . . . . . . . . 67
C.1. Arquitectura del sistema OneQL . . . . . . . . . . . . . . . . . . . . . . . . . 69
F.1. Consulta q01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
F.2. Consulta q02 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
F.3. Consulta q03 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
F.4. Consulta q04 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
F.5. Consulta q05 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
F.6. Consulta q06 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
F.7. Consulta q07 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
F.8. Consulta q08 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
F.9. Consulta q09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
F.10. Consulta q10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
F.11. Consulta q01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
F.12. Consulta q02 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
F.13. Consulta q03 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
F.14. Consulta q04 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
F.15. Consulta q05 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
F.16. Consulta q06 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
F.17. Consulta q07 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
F.18. Consulta q08 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
F.19. Consulta q09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
G.1. Tiempo de ejecucion de consultas simples . . . . . . . . . . . . . . . . . . . . 84
´
G.2. Tiempo de ejecucion de consultas complejas . . . . . . . . . . . . . . . . . . . 85
´
G.3. Tiempo de ejecucion de consultas simples . . . . . . . . . . . . . . . . . . . . 85
´
xi

14. G.4. Tiempo de ejecucion de consultas complejas . . . . . . . . . . . . . . . . . . . 86
´
G.5. Tiempo de ejecucion de consultas simples . . . . . . . . . . . . . . . . . . . . 87
´
G.6. Tiempo de ejecucion de consultas complejas . . . . . . . . . . . . . . . . . . . 87
´
G.7. Tiempo de ejecucion de consultas simples . . . . . . . . . . . . . . . . . . . . 88
´
G.8. Tiempo de ejecucion de consultas complejas . . . . . . . . . . . . . . . . . . . 89
´
G.9. Tiempo de ejecucion de consultas simples . . . . . . . . . . . . . . . . . . . . 90
´
G.10.Tiempo de ejecucion de consultas complejas . . . . . . . . . . . . . . . . . . . 90
´
G.11.Tiempo de ejecucion total de consultas simples . . . . . . . . . . . . . . . . . 91
´
G.12.Tiempo de ejecucion total de consultas complejas . . . . . . . . . . . . . . . . 91
´
G.13.Tiempo de ejecucion de consultas simples . . . . . . . . . . . . . . . . . . . . 92
´
G.14.Tiempo de ejecucion de consultas complejas . . . . . . . . . . . . . . . . . . . 93
´
G.15.Tiempo de ejecucion total de consultas simples . . . . . . . . . . . . . . . . . 93
´
G.16.Tiempo de ejecucion total de consultas complejas . . . . . . . . . . . . . . . . 94
´
xii

15. Glosario de T´ rminos
e
WWW World Wide Web. Cantidad de documentos interconectados mediante
Internet.
DBMS Database Management System. Conjunto de programas que se encar-
gan de crear, mantener y usar una base de datos. Permite al usuario
controlar los datos de manera eficaz.
SQL Structured Query Language. Lenguaje usado en el ambito de las bases
´
de datos para gestionar datos en manejadores relacionales.
W3C World Wide Web Consortium. Organizacion internacional que establece
´
los est´ ndares para la WWW. Dirigida por Tim Berners-Lee.
a
RDF Resource Description Framework. Conjunto de especificaciones que dic-
tan las reglas para modelacion de datos. Es un est´ ndar formado por
´ a
la W3C.
RDFS Resource Description Framework Schema. Lenguaje para representacion
´
de conocimientos que posee elementos para describir ontolog´as.
ı
xiii

16. Cap´tulo 1
ı
Introduccion
´
La Nube Enlazada de Datos (NED), siguiendo unos est´ ndares de publicacion y los
a ´
principios en los que se fundamenta la Web, permite publicar informacion de cualquier
´
´ndole. El unico requerimiento para acceder a esta informacion es, simplemente, estar
ı ´ ´
interesado en consultarla y tener acceso a Internet. La gran ventaja de que la informacion
´
y las interrelaciones dentro de la NED sigan los formatos de RDF [1] y RDFS [2], es que las
m´ quinas pueden procesar esta informacion y, gracias a su poder de computo, se pueden
a ´ ´
detectar nuevas asociaciones entre distintas fuentes de datos.
Las fuentes de datos que constituyen la NED pueden estar conformadas por millones
de tripletas con billones de interrelaciones entre ellas. Por ejemplo para la enfermedad
del Alzheimer, se tienen laboratorios de investigacion gubernamentales y corporativos
´
trabajando en conjunto publicando una cantidad masiva de informacion relacionada con
´
esta enfermedad, tales como los datos cl´nicos de los pacientes, resultados de ex´ menes,
ı a
entre otros, para facilitar el proceso de investigacion para una cura. Sin embargo, se hace
´
muy dif´cil realizar este proceso ya que se debe acceder un gran volumen de datos y
ı
enlaces de forma r´ pida y eficiente.
a
Para resolver este problema han surgido distintos manejadores tales como RDF-3X
[3], OneQL [4], Jena TDB [5], Nguyen et al. [6], que han logrado reducir los tiempos de
ejecucion de las consultas. En este trabajo se propone un optimizador que utilizando un
´
modelo de costo y t´ cnicas de optimizacion contra documentos RDF produce planes que
e ´
mejoren el tiempo de ejecucion de las consultas.
´
El objetivo general de este trabajo consiste en disenar e implementar un optimizador
˜
de consultas SPARQL para la Nube Enlazada de Datos, llamado COneQL. Para lograr que
el optimizador COneQL pueda desarrollar planes de ejecucion correctos y eficientes, se
´
plantean los siguientes objetivos espec´ficos:
ı
1

17. ´ ´
CAPITULO 1. INTRODUCCION 2
Estudiar modelos de costo para la estimacion del tiempo de ejecucion y la cardina-
´ ´
lidad al evaluar una consulta contra documentos RDF.
Estudiar t´ cnicas de optimizacion en consultas contra documentos RDF.
e ´
Describir el modelo de costo propuesto en [4] y las t´ cnicas de optimizacion.
e ´
Disenar e implementar las t´ cnicas de optimizacion propuestas.
˜ e ´
Estudiar experimentalmente el efecto de la forma de los planes en la calidad de las
t´ cnicas propuestas en comparacion con el manejador de documentos RDF, RDF-3X,
e ´
que representa el estado del arte.
A continuacion se presentan siete cap´tulos en los cuales se explican los detalles con-
´ ı
cernientes al desarrollo de este proyecto. En el cap´tulo 2 , se establecen las bases teoricas
ı ´
necesarias para comprender este proyecto y los trabajos relacionados al trabajo desarro-
llado. En el cap´tulo 3 se presenta el ejemplo motivador, la formalizacion y complejidad
ı ´
del problema a tratar. Luego, se tienen los detalles del diseno e implementacion de las
˜ ´
soluciones propuestas explicados en los cap´tulos 4 y 5. El cap´tulo 6 est´ dedicado al
ı ı a
estudio experimental de las soluciones, y finalmente, las conclusiones y recomendaciones
se encuentran en el cap´tulo 7.
ı

18. Cap´tulo 2
ı
Marco Teorico
´
En este cap´tulo se expone todos aquellos elementos teoricos de inter´ s para desarro-
ı ´ e
llar el argumento de la presente investigacion. Se empieza por dar una explicacion sobre
´ ´
la Web Sem´ ntica y conceptos relacionados con este tema. Luego se muestra los dife-
a
rentes componentes para consultar documentos RDF. Seguidamente se explica qu´ es un
e
optimizador y los elementos que lo conforman y soportan. Por ultimo se mencionar´ n los
´ a
sistemas de RDF existentes.
2.1. Web Sem´ ntica
a
La Web Sem´ ntica [7] es un ente que no est´ separado de la Web sino que es una exten-
a a
sion de la misma. La Web Sem´ ntica consiste en meta-datos que describen el significado
´ a
de los contenidos de una p´ gina web, permitiendo que las m´ quinas realicen busquedas
a a ´
sin intervencion de los usuarios con base en el significado de los datos publicados; para
´
m´ s detalles v´ ase el Ap´ ndice A.
a e e
2.1.1. Universal Resource Identifier (URI)
Un URI representa una forma simple y extensible de identificar un´vocamente un
ı
recurso en la Web [8]. La sintaxis y sem´ ntica se deriva de los conceptos que son nativos
a
a la WWW, que pueden llegar a incluir personas y lugares, o aquellos conceptos m´ s
a
abstractos tales como la nocion de “conocer a otra persona”, “un color en espec´fico”, etc.
´ ı
Las propiedades que permiten a los URIs desempenarse como nombres para un recur-
˜
so, son las siguientes:
1. Proveen una forma simple para crear nombres unicos y globales.
´
2. No solo sirven como nombres, sino tambi´ n como medios de acceso a la informacion
´ e ´
de la entidad identificada.
3

19. ´ ´
CAPITULO 2. MARCO TEORICO 4
Los URIs deben ser le´dos por algun agente; este agente puede ser una persona o
ı ´
una computadora. Dependiendo del agente que est´ en interaccion con los recursos, las
e ´
descripciones de un recurso pueden estar integrados con un HTML o estar representados
en el formato est´ ndar de RDF. La forma en la que el protocolo HTTP reconoce qu´ tipo
a e
de agente est´ requiriendo la informacion, se encuentra en los headers de los paquetes de
a ´
HTTP, que le indican si solicitan una p´ ginas HTML o un documento RDF.
a
2.1.2. Resource Description Framework (RDF)
El W3C se ha encargado de que esta extension de la Web est´ bien estructurada, es por
´ e
eso que esta organizacion ha establecido una serie de est´ ndares en diferentes ambitos,
´ a ´
los cuales son necesarios para la Web Sem´ ntica.
a
Bajo la idea de encontrar nuevos conocimientos, de crear informacion estructurada
´
para que cualquier tipo de agente sea capaz de procesarla, se creo el formato RDF con la
´
finalidad de modelar los datos en la WWW.
Todo elemento de informacion que se desee publicar en la Nube de Datos debe estar
´
estandarizada en RDF, en cualquiera de los diferentes formatos. A pesar, de que existen
formatos distintos de documentos RDF que son aprobados por la W3C, todos se basan en
la misma estructura primaria, tripletas o patrones. Las tripletas son la unidad principal
de cualquier documento RDF.
Una tripleta est´ compuesta por: sujeto, predicado y valor u objeto. Tal como se observa
a
en la Figura 2.1, el sujeto de la tripleta debe ser un URI que describa al recurso a ser
modelado, el objeto puede ser un valor literal o el URI que identifica algun recurso que
´
de alguna manera est´ relacionado con el sujeto, y el predicado es otro URI que indica
a
qu´ relacion existe entre el sujeto y el objeto, este URI viene dado por diferentes ontolog´as
e ´ ı
que ofrecen colecciones de URIs que pueden ser usadas para expresar informacion de
´
distintos dominios.

20. ´ ´
CAPITULO 2. MARCO TEORICO 5
tripleta en formato RDF
http : //www.w3.org/People/Berners − Lee/ f oa f : name “TimBerners − Lee”
sujeto (variable) prefijo propiedad objeto (instanciado)
predicado
Figura 2.1: Ejemplo de una tripleta RDF
Las ventajas de usar RDF como modelo de datos [9] son las siguientes:
1. Usando URIs como un identificador unico y universal para objetos o t´ rminos de un
´ e
vocabulario, el modelo de RDF puede ser usado a escala global.
2. Un cliente puede revisar cualquier URI de una tripleta RDF para obtener mayor
informacion, por lo tanto cada tripleta RDF est´ interrelacionada con alguna otra y
´ a
esto permite que se use como punto de partida para explorar el espacio de datos.
3. La informacion de diferentes fuentes puede ser combinada mezclando dos conjuntos
´
de tripletas a un mismo documento RDF, esto es crucial para lograr interrelacionar
diferentes fuentes de datos y evitar que existan fuentes de datos inalcanzables.
4. RDF permite representar informacion descrita en diferentes tipos de esquemas, por
´
lo que se pueden usar t´ rminos de diferentes vocabularios para definir datos.
e
Para publicar en la Web, la informacion en RDF puede ser serializada en varios forma-
´
tos, los dos formatos m´ s usados son RDF/XML y RDFa. [9]
a
2.1.3. SPARQL
Es un lenguaje de consulta basado en la estructura “SELECT FROM WHERE” y adap-
tado para trabajar con tripletas RDF. SPARQL es el est´ ndar definido por W3C para
a
consultar cualquier documento RDF [10]. Las variables son utilizadas tanto para extraer
informacion de una consulta, como para representar un objeto que une a dos o m´ s fuentes
´ a
de datos distintas; estas pueden aparecer en los tres elementos que conforman las tripletas.
´

21. ´ ´
CAPITULO 2. MARCO TEORICO 6
En SPARQL se pueden denotar las variables ubicando un signo de interrogacion antes de
´
un conjunto de letras; se utiliza para extraer, filtrar o proyectar informacion.
´
2.1.4. Nube Enlazada de Datos
En el contexto de La Nube Enlazada de Datos se han definido un conjunto de pr´ cticas
a
para publicar e interrelacionar datos estructurados en la Web.
Estas pr´ cticas propuestas por Tim Berners-Lee son conocidos como los principios de
a
La Nube Enlazada de Datos [9]. Estos principios son los siguientes:
1. Usar URIs como nombres para conceptos.
2. Integrar los URIs con el protocolo HTTP para que as´ las personas puedan navegar
ı
a trav´ s de ellos.
e
3. Cuando algun agente revisa un URI, este debe proveer informacion coherente usan-
´ ´ ´
do est´ ndares.
a
4. Siempre se deben incluir URIs a otras fuentes para as´ establecer relaciones de
ı
equivalencia entre distintas fuentes de datos.
5. Los datos deben ser accesibles por Internet a trav´ s de ciertos est´ ndares y protocolos.
e a
Basado en estos cinco principios, se puede notar la importancia de los URIs para la
Nube Enlazada de Datos, es por esto que una propiedad importante que debe cumplir todo
URI es que pueda ser desreferenciado1 , esa es la manera como algun agente puede obtener
´
informacion y relacionar dos conceptos diferentes, navegando entre los diferentes URIs.
´
Esta Nube Enlazada utiliza una estrategia para redireccionar y obtener diferentes URIs,
basada en codigos del protocolo HTTP; si se est´ referenciando un objeto del mundo real,
´ a
este no puede ser referenciado y se devuelve directamente el objeto. Si no es un objeto
´
tangible sino m´ s bien, un concepto abstracto, entonces el protocolo de HTTP retorna
a
el codigo 303 que le indica que el URI es una descripcion de un objeto y por lo tanto
´ ´
ser´ desreferenciado hacia otro URI. Para m´ s detalles v´ ase el Ap´ ndice A.
a a e e
1
significa obtener los documentos RDF identificados por un URI y almacenarlos de manera local

22. ´ ´
CAPITULO 2. MARCO TEORICO 7
2.1.5. Puntos de Acceso de SPARQL
Los puntos de acceso son protocolos de servicios que permiten que algun agente, con-
´
sulte una base de conocimientos espec´fica utilizando el lenguaje SPARQL, generalmente
ı
los resultados est´ n en algun formato procesable por una m´ quina. De esta forma los
a ´ a
puntos de acceso pueden ser vistos como una interfaz sobre una fuente de datos, tanto en
la formulacion de la consulta como en la presentacion de los resultados de manera legible
´ ´
para los humanos. La ejecucion de una consulta a trav´ s de los puntos de acceso puede
´ e
ser extremadamente costosa, debido a la falta de planificacion de la misma.
´
2.2. Componentes para ejecutar consultas contra datos RDF
Un manejador de documentos RDF est´ compuesto principalmente por dos modulos:
a ´
el optimizador de consultas y la m´ quina de ejecucion, tal como se muestra en la Figura
a ´
2.2.
DBMS
OPTIMIZADOR
CONSULTA EN SQL MANEJADOR DE ARCHIVOS
MÁQUINA DE
BD
EJECUCIÓN
Figura 2.2: Arquitectura de un Manejador de Base de Datos
2.2.1. M´ quinas de Ejecucion
a ´
La m´ quina de ejecucion es la encargada de ejecutar las instrucciones de alto nivel
a ´
obtenidas por el optimizador, por ejemplo operadores logicos, y traducirlas a bajo nivel,
´
por ejemplo operadores f´sicos. Dependiendo de la m´ quina de ejecucion existe m´ s de
ı a ´ a
una forma de implementar un operador logico. Los operadores logicos son parte del arbol
´ ´ ´
logico que usa el manejador de base de datos, mientras que el arbol f´sico es la estructura
´ ´ ı
de entrada de la propia m´ quina de ejecucion.
a ´

23. ´ ´
CAPITULO 2. MARCO TEORICO 8
´
2.2.1.1. Arbol Logico
´
Es una estructura abstracta que corresponde a un arbol binario con nodos internos
´
que corresponden a los operadores del algebra relacional y las hojas corresponden a
´
subconjuntos de tripletas, tal como se muestra en la Figura 2.3.
OPERADOR
LÓGICO
OPERADOR OPERADOR
LÓGICO LÓGICO
Figura 2.3: Representacion del arbol logico
´ ´ ´
´
2.2.1.2. Arbol F´sico
ı
Es una estructura interna del optimizador, este es estructuralmente equivalente al arbol
´ ´
logico pero en lugar de poseer operadores del algebra relacional, se tienen operadores
´ ´
f´sicos disponibles por el optimizador.
ı
2.2.1.3. Planes de Ejecucion
´
Un plan de ejecucion representa los pasos que la m´ quina de evaluacion deber´ seguir
´ a ´ a
para responder una consulta. Tales pasos representan las distintas subconsultas en las que
la consulta original se puede dividir. La forma que estos planes se pueden obtener var´an
ı
segun el optimizador de consultas del manejador.
´
Planes Lineales Izquierdos: los planes lineales izquierdos son aquellos donde para cada
operador su hijo derecho es una hoja y su hijo izquierdo es un sub´ rbol, esta forma
a
es mostrada en la Figura 2.4(a). Estos planes pueden ser formados por algunos
optimizadores (por ejemplo RDF-3X).

24. ´ ´
CAPITULO 2. MARCO TEORICO 9
Planes Arbustos: los planes arbustos son aquellos que pueden tomar cualquier forma, es
decir, no tienen ninguna restriccion definida con respecto a la forma de los hijos de
´
un nodo del arbol (puede crecer hacia la izquierda o derecha), resultando de esta
´
forma aleatorios. Un ejemplo de esto se muestra en la Figura 2.4(b)
´
(a) lineal izquierdo (b) arbusto
´
Figura 2.4: Forma de Arboles
2.2.1.4. Grupos Estrella
Un grupo estrella es un conjunto de tripletas o patrones de una consulta que cumplen
la caracter´stica de tener exactamente una variable en comun entre ellas. Es importante
ı ´
recalcar que la primera tripleta del grupo estrella debe ser la m´ s selectiva de todo el
a
grupo.
La definicion formal de un grupo estrella viene dado por lo siguiente:
´
?X∗ -BGP es un grupo estrella, si ocurre que para cada tripleta o patron s p o, que puede
´
ser de la forma s p ?X o de la forma ?X p o, tal que s ?X, p ?X y o ?X. Si para los
conjuntos de tripletas P y P tenemos que var(P) ∩ var(P ) = ?X, entonces se cumple que P
∪ P es un ?X∗ -BGP. [11]
La forma de evaluar esta estructura para aprovechar sus caracter´sticas es empezar
ı
con la evaluacion del primer patron del grupo estrella e identificar las instanciaciones
´ ´
de la variable compartida. Estas instanciaciones son utilizadas para extraer los dem´ s
a
resultados del resto de las tripletas pertenecientes al grupo estrella para que tenga una
baja cardinalidad.

25. ´ ´
CAPITULO 2. MARCO TEORICO 10
La propuesta para este trabajo se basa en la formacion de grupos estrellas y en aprove-
´
char las ventajas de esta forma de agrupacion de los patrones de tripletas de una consulta,
´
con respecto a la disminucion del tamano de los resultados intermedios generados en la
´ ˜
ejecucion de un plan.
´
A continuacion, en la Figura 2.5 se muestra un ejemplo de un grupo estrella.
´
?A <http://mpii.de/yago/resource/hasFamilyName> ?fn
?A <http://mpii.de/yago/resource/hasGivenName> ?ln
?person <http://mpii.de/yago/resource/influences> ?A
Figura 2.5: Grupo estrella unido por la variable ?A
2.2.1.5. Operadores F´sicos
ı
En OneQL [4], sistema manejador de documentos RDF, se hace referencia a dos ope-
radores creados para la manipulacion de los datos, estos son:
´ ´
Index Nested-Loop Join: Para cada tripleta del primer patron, se extraen todas las triple-
´
tas coincidentes a esta del segundo patron, es decir, las variables en comun entre los
´ ´ ´
dos patrones se instancian en el segundo patron.
´
Group Join: La idea principal de este operador es aprovechar la pequena cardinalidad
˜
que se puede obtener por los grupos estrellas, y evaluar estos de forma independiente
´
para luego obtener los resultados coincidentes. Una de las ventajas del uso de este
operador es que en el caso en que los resultados de ambas estrellas sean muy
pequenos, se podr´ mantener en memoria principal los resultados intermedios y
˜ a
evitar accesos a disco.
2.2.2. Optimizador
El optimizador es el responsable de obtener un plan de ejecucion correcto y eficiente.
´
Los dos enfoques m´ s comunes son: basado en heur´sticas y basado en costos. Particu-
a ı
larmente en este trabajo se utiliza el enfoque basado en costos, donde a trav´ s del uso de
e

26. ´ ´
CAPITULO 2. MARCO TEORICO 11
un modelo de costo h´brido y una t´ cnica de optimizacion adaptada a documentos RDF
ı e ´
(Simulated Annealing), se realiza una exploracion en un universo de planes de ejecucion,
´ ´
en busqueda del plan con menor costo.
´
2.2.2.1. Modelo de Costo H´brido
ı
´
Un modelo de costo juega un papel importante para el optimizador de consultas. Este
se encarga de estimar y predecir el desempeno de un plan bas´ ndose en el an´ lisis de
˜ a a
estad´sticas sobre los datos. El desempeno es valorado como el costo de evaluar un plan
ı ˜
segun una m´ trica, la cual mide el consumo de algun recurso computacional, como la
´ e ´
cantidad de operaciones de entrada y salida (I/O), resultados intermedios, etc.
Para el c´ lculo de la cardinalidad y costo de ciertos patrones se puede utilizar el
a
Muestreo Adaptativo [4], mientras que para el c´ lculo de los operadores f´sicos se utiliza
a ı
un modelo similar al Sistema R [4], debido a la semejanza que existe con las formulas
´
relacionales. Ambos modulos son implementados en este proyecto y se detallar´ n en el
´ a
Cap´tulo 4.
ı
El Sistema R es el primer manejador de base de datos relacional experimental desa-
rrollado por la IBM con una interfaz de datos de alto nivel. Lo interesante de este sistema
es el modelo de costo que utiliza para optimizar sus planes de ejecucion. Este modelo se
´
basa en dos suposiciones.
Uniformidad: todos los valores de un atributo son igualmente probables.
Independencia: los valores de un atributo son independientes de los valores de otros
atributos.
De manera similar a como funciona el modelo de costo del Sistema R, en este trabajo
se almacenan estad´sticas sobre cualquier componente de la tripleta. En la Figura 2.6 se
ı
muestran las formulas de este sistema, las cuales son similares a los operadores f´sicos en
´ ı
consultas relacionales.

27. ´ ´
CAPITULO 2. MARCO TEORICO 12
D ≡ tiempo promedio de lectura y escritura sobre un bloque de disco
M ≡ tamano de la tabla R en numero de bloques
˜ ´
N ≡ tamano de la tabla S en numero de bloques
˜ ´
´
SELECCION(R): M × D para una organizacion heap
R NJOIN S: (M × D) + (cardinalidad(R) × N × D)
R GJOIN S: (M × D) + (N × D) + cardinalidad(R) + cardinalidad(S)
Figura 2.6: Formulas usadas en el Sistema R
´
El Muestreo Adaptativo, a diferencia de otras t´ cnicas de muestreo tradicional, se basa
e
en consultar los datos y calcular din´ micamente, segun el tamano de estos, la cantidad de
a ´ ˜ ´
muestras que se van a tomar. Para este trabajo se adapto este algoritmo.
´
El problema principal con los algoritmos de muestreo tradicionales es que determinan
est´ ticamente la cantidad de muestras que van a ser tomadas para una precision deseada.
a ´
Esto funciona bien cuando el tiempo de tomar una muestra es pequeno y no var´a mucho,
˜ ı
como es el caso normal de las consultas en bases de datos tradicionales. M´ s, si el costo
a
de computar una muestra var´a mucho y puede ser muy grande, entonces los algoritmos
ı
tradicionales pueden tomar un tiempo de ejecucion muy elevado.
´
El Muestreo Adaptativo consiste primero en elegir aleatoriamente, segun una cota, ele-
´
mentos de una poblacion hasta conseguir aqu´ l que posea la mayor cardinalidad o costo.
´ e
Luego la cardinalidad o costo m´ ximo obtenido es utilizado como cota superior para el
a
c´ lculo de la cardinalidad y costo estimado total de la consulta o subconsulta.
a
Este algoritmo presenta dos ventajas. La primera ventaja es que al ser la estimacion en
´
funcion del tamano, se tiende a tener un algoritmo que se ejecuta en un tiempo constante,
´ ˜
m´ s que en una cantidad de muestras [12]. La segunda es que al estimar constantemente el
a
costo de los datos, en lugar de hacer suposiciones sobre estos, se obtienen din´ micamente
´ a
las caracter´sticas de estos datos.
ı

28. ´ ´
CAPITULO 2. MARCO TEORICO 13
2.2.2.2. Simulated Annealing
Simulated Annealing es el algoritmo principal que usa el optimizador desarrollado en
´
este trabajo para buscar los mejores planes [4]. Este es un algoritmo de busqueda por
´
meta-heur´sticas, que cumple el siguiente patron: dado un plan perteneciente al universo
ı ´
de planes, obtenido a trav´ s de una generacion aleatoria para una consulta espec´fica, se
e ´ ı
mueve a un plan vecino y comprueba si este vecino es una mejor solucion que el, siendo
´ ´
un plan vecino aquel que est´ a una transformacion de distancia; en caso de que el plan
a ´
vecino sea mejor que el plan inicial, entonces se toma este como su nuevo punto de partida
´
para iniciar otra vez el mismo proceso; si no es mejor, entonces se regresa a su punto inicial
y toma otro vecino, y as´ sucesivamente. Para determinar si un plan es mejor que otro,
ı
se utiliza una funcion de costos que, bas´ ndose en ambos planes, decide cu´ l es la mejor
´ a a
opcion. Una adaptacion de este algoritmo es el usado en este proyecto.
´ ´
El algoritmo contiene una temperatura que define la cantidad de iteraciones a realizar.
Para cada iteracion se ejecutan varios escenarios, cada uno de los escenarios representan
´
una transformacion a realizar. Se empieza con una temperatura inicial T, siendo T>0; en
´
cada iteracion de temperatura se realizan cierta cantidad de escenarios (transformacio-
´
nes), al terminar la cantidad de escenarios se reduce la temperatura y se continua con
´
la siguiente iteracion. As´ cuando el algoritmo llega a tener 0 de temperatura o cuando
´ ı
llega a un resultado suficientemente bueno, el algoritmo se detiene. Espec´ficamente para
ı
este optimizador, no se tomo en cuenta ningun c´ lculo para determinar una cota para ese
´ ´ a
“resultado suficientemente bueno” sino que la unica condicion de parada es cuando la
´ ´
temperatura llegue a cero.
El recorrido por el espacio de planes se lleva a cabo a trav´ s de la aplicacion de
e ´
una transformacion a un plan, siendo una transformacion la ejecucion de alguna regla
´ ´ ´
axiom´ tica. En el Ap´ ndice B se pueden consultar las reglas para SPARQL propuestas en
a e
[11].
Adem´ s se debe senalar que esta implementacion permite elegir un plan m´ s costoso al
a ˜ ´ a
elegido anteriormente. Esto es una t´ cnica comun de un Simulated Annealing para evitar
e ´

29. ´ ´
CAPITULO 2. MARCO TEORICO 14
quedarse estancado en un m´nimo local. Tambi´ n se aumenta el numero de escenarios en
ı e ´
cada temperatura para obtener mayor cantidad de transformaciones a medida que baja la
temperatura.
2.3. Sistemas Manejadores de Documentos RDF
En el ambito de la Web Sem´ ntica existen manejadores desarrollados para manipular
´ a
documentos RDF de forma eficiente, como: Sesame [13], AllegroGraph [14], Fletcher et
al [15], McGlothlin [16], Abadi [17] [18], BitMat [19], Nguyen [6], Harth [20], Li &
Heflin [21], Urhan [22] [23], Bernstein [24], Jena [25], etc. Lo m´ s importante de estos
a
manejadores son las distintas t´ cnicas y estrategias que utilizan para ejecutar una consulta;
e
v´ ase el Ap´ ndice C. Adem´ s de los trabajos ya mencionados existen otros manejadores
e e a
como son OneQL [4] y RDF-3X [3] que se explicar´ n a continuacion, adem´ s de Berkeley
a ´ a
DB. Ninguna de estas soluciones nombradas, logran escalar para consultas de cualquier
tipo de complejidad.
2.3.1. OneQL
El sistema OneQL [4], basado en ontolog´as, provee varias t´ cnicas de optimizacion y
ı e ´
ejecucion de consultas SPARQL, escalables a un gran grupo de documentos RDF/RDFS
´
y consultas complejas. OneQL utiliza un hipergrafo dirigido para almacenar e indexar
las ontolog´as de los documentos RDF, y una base de datos deductiva cuyos predicados
ı
representan el conocimiento expl´citamente expresado en la ontolog´a.
ı ı
´
Lo m´ s relevante de este sistema para este trabajo es el optimizador de consultas. Este
a
se enfoca en dos ideas, la primera es la utilizacion de un modelo de costo h´brido, basado
´ ı
en el sistema R y la t´ cnica de Muestreo Adaptativo, que estima el tiempo de ejecucion de
e ´
un posible plan; y la segunda es la realizacion de una busqueda dentro del espacio de
´ ´
planes para conseguir aquellos que presenten una forma particular (planes arbustos).
Las limitaciones de este sistema vienen dadas principalmente por el lenguaje en el que
se desarrollo, Prolog. Al basarse en un lenguaje interpretado tarda un tiempo considerable
´

30. ´ ´
CAPITULO 2. MARCO TEORICO 15
en optimizar y evaluar una consulta. Tampoco es escalable a grandes volumenes de datos.
´
La arquitectura de este sistema est´ comprendida por un cat´ logo de ontolog´as, un
a a ı
planificador de consultas, un hipergrafo denominado Bhyper y un motor de consultas y
razonamiento, tal como se muestra en el Ap´ ndice C.
e
El cat´ logo de ontolog´as est´ conformado por una base de datos deductiva con la
a ı a
modelacion de todas ontolog´as, en este cat´ logo se almacenan los costos de inferir hechos
´ ı a
intensionales, las cardinalidades de distintos hechos, y el numero de valores de sujetos y
´
objetos para cada propiedad.
El planificador de consultas est´ conformado por dos componentes, un modelo de
a
costo h´brido y una estrategia de doble optimizacion para identificar planes arbustos. El
ı ´
modelo de costo h´brido c´ lcula de forma distinta los costos y cardinalidades de los hechos
ı a
intensionales y extensionales, utilizando respectivamente el Muestreo Adaptativo y un
modelo de costo de base de datos tradicionales basado en el Sistema R. Por otra parte,
la estrategia de doble optimizacion consiste en una primera fase de optimizacion basada
´ ´
en costos utilizando uno de dos algoritmos, dependiendo de la cantidad de patrones en
la cl´ usula WHERE. Un algoritmo de programacion din´ mica que se enfoca en conseguir
a ´ a
planes lineales izquierdos para consultas con una pequena cantidad de patrones, y en el
˜
otro caso, uno de programacion aleatoria que realiza recorridos aleatorios sobre un espacio
´
de busqueda de planes arbustos; la segunda fase consiste en la aplicacion de t´ cnicas de
´ ´ e
reescritura de Magic Sets al plan obtenido en la primera fase.
Luego est´ la estructura Bhyper, basada en un hipergrafo, utilizada para indexar los
a
predicados de la base de datos deductivas y as´ acelerar las tareas del procesador de
ı
consultas y razonamiento.
Finalmente est´ el motor de consultas y razonamiento, en donde se implementan
a
dos operadores f´sicos, definidos para extraer y combinar hechos de la ontolog´a; ambos
ı ı
operadores utilizan los accesos directos provistos por las estructuras de Bhyper.

31. ´ ´
CAPITULO 2. MARCO TEORICO 16
2.3.2. RDF-3X
El motor de ejecucion de consultas RDF-3X [3] se basa en una arquitectura de tipo
´
RISC, en la cual se trata de identificar las caracter´sticas m´ s comunes y simples, y trata
´ ı a
de ejecutarlas lo m´ s r´ pido posible.
a a
Este sistema est´ enfocado en un sistema de ´ndices, basado en las diferentes permu-
a ı
taciones de los tres componentes de una tripleta RDF, tal que las t´ cnicas de optimizacion
e ´
desarrolladas exploren solo el espacio de planes que salen beneficiados por estos ´ndices.
´ ı
Debido a que utiliza un algoritmo de programacion din´ mica, basada en la enumeracion
´ a ´
de planes lineales izquierdos, RDF-3X escala a espacios de busqueda pequenos limitando
´ ˜
as´, el tamano de las consultas que pueden ser optimizadas y evaluadas. RDF-3X se basa
ı ˜
en los siguientes tres principios:
El diseno f´sico es independiente de la carga de trabajo del motor. RDF-3X ha elimi-
˜ ı
nado la necesidad de entonacion del diseno f´sico al crear la suficiente cantidad de
´ ˜ ı
´ndices, los cuales gracias a la compresion pueden llegar a pesar menos que la base
ı ´
de datos principal.
El procesador de consultas es del estilo RISC, y se basa m´ s en la formacion de grupos
a ´
estrellas utilizando su Merge Join, que en la busqueda por los ´ndices ordenados. El
´ ı
procesamiento del Merge Join se lleva a cabo utilizando solamente los ´ndices.
ı
El optimizador de consultas se basa en la programacion din´ mica para la enume-
´ a
racion de planes y tiene un modelo de costo que trabaja con estad´sticas espec´ficas
´ ı ı
para RDF; se enfoca principalmente en el orden de los joins para la generacion de
´
planes de ejecucion.
´
2.3.3. Berkeley DB
Es un manejador de archivos de libre distribucion, distribuida por Oracle Corporation,
´
escrito en lenguaje C, con soporte para diferentes lenguajes. Trabaja bajo el esquema de
clave/valor, el cual posee un alto rendimiento para grandes volumenes de datos debido a
´

32. ´ ´
CAPITULO 2. MARCO TEORICO 17
su delegacion de verificaciones a las aplicaciones que las usan, como la de integridad de
´
datos, claves for´ neas, entre otras. Otra caracter´stica de este tipo de esquema es que, a
a ı
diferencia de los esquemas tradicionales, acepta cualquier cantidad de pares clave-valor
con duplicados, en caso de que la aplicacion lo necesite.
´
Berkeley DB no ofrece el modo cliente-servidor, as´ que toda instancia del manejador
ı
debe ser local a la estacion de trabajo. La comunicacion entre los usuarios y los datos no es
´ ´
a trav´ s de consultas en SQL sino con la ayuda de un API para cualquiera de los lenguajes
e
que soporta. Esto elimina las ventajas de usar un lenguaje de consultas estandarizado, pero
tambi´ n permite al programador acceder o modificar los datos y tomar ciertas decisiones
e
de diseno para optimizaciones.
˜
Berkeley DB permite la creacion de ´ndices, pero cualquier actualizacion que se quiera
´ ı ´
realizar sobre estos debe ser realizada manualmente por los programadores. Berkeley DB
´
ofrece la posibilidad de crear las bases de datos e ´ndices con dos tipos de estructuras, una
ı
tipo arbol B+ y otra de tipo Hash.
´

33. Cap´tulo 3
ı
An´ lisis del Problema
a
En este cap´tulo se ilustrar´ la importancia de encontrar una solucion al problema de
ı a ´
ejecucion de consultas mediante un ejemplo pr´ ctico que puede ser usado en la vida coti-
´ a
diana, luego se mostrar´ una definicion formal del problema, por ultimo se indicar´ una
a ´ ´ a
formula para acotar el tamano del espacio del problema.
´ ˜
3.1. Ejemplo Motivador
Uno de los campos expuestos en La Nube Enlazada de Datos (NED) es la ciencia
m´ dica, con fuentes de datos abiertas que proveen informacion sobre ensayos cl´nicos
e ´ ı
realizados sobre distintas enfermedades. Una fuente de datos espec´fica es la llamada
ı
LinkedCT (Linked Data Space for Clinical Trials), en la cual se asocian no solo los ensayos
´
cl´nicos, sino tambi´ n las drogas utilizadas en cada uno, los efectos secundarios provoca-
ı e
dos por las respectivas drogas, la ubicacion geogr´ fica donde fue realizado dicho estudio,
´ a
entre otros datos relevantes.
Suponga que existe alguien interesado en consultar la informacion de los ensayos
´
cl´nicos en donde las enfermedades de C´ ncer de Senos, de Ovarios, de Pulmon y de
ı a ´
Colorectal fueron tratados con drogas. Bajo el escenario descrito, la persona interesada
se enfrentar´a a uno de los problemas claves en el area de la Web Sem´ ntica: el poder
ı ´ a
consultar de forma eficaz la informacion que se encuentra en la NED. Lo m´ s probable, si
´ a
la persona tiene conocimiento previo en busquedas sobre fuentes de datos de la NED, es
´
que utilice el manejador de documentos RDF, RDF-3X, el cual, actualmente, es el de mejor
rendimiento. En dicho caso, la consulta SPARQL ser´a un plan lineal izquierdo que lucir´a
ı ı
como en la Figura 3.1(a).
18

34. ´ ´
CAPITULO 3. ANALISIS DEL PROBLEMA 19
PREFIX foaf:<http://xmlns.com/foaf/0.1/>
PREFIX foaf:<http://xmlns.com/foaf/0.1/> PREFIX linkedct:<http://data.linkedct.org/resource/linkedct/>
PREFIX linkedct:<http://data.linkedct.org/resource/linkedct/> SELECT DISTINCT ?fn1 ?fn3 ?fn5 ?fn7 ?I
SELECT DISTINCT ?fn1 ?fn3 ?fn5 ?fn7 ?I WHERE {
WHERE { {{{?A3 foaf:page ?fn3 .}gjoin
?A1 foaf:page ?fn1. {?A4 linkedct:condition name “Breast Cancer” .
?A1 linkedct:intervention ?I. ?A3 linkedct:condition ?A4 .}}gjoin
?A3 linkedct:intervention ?I. {{{?A6 linkedct:condition name “Ovarian Cancer” .}.
?A3 foaf:page ?fn3. {{{{?A5 linkedct:intervention ?I .
?A5 linkedct:intervention ?I. ?A5 foaf:page ?fn5 .
?A5 foaf:page ?fn5. ?A5 linkedct:condition ?A6 .}gjoin
?A7 linkedct:intervention ?I. {?A1 linkedct:intervention ?I .
?A7 foaf:page ?fn7. ?A1 foaf:page ?fn1 .}}gjoin
?A1 linkedct:condition ?A2. {?A2 linkedct:condition name “Colorectal Cancer” .
?A2 linkedct:condition name “Colorectal Cancer”. ?A1 linkedct:condition ?A2 .}}gjoin
?A3 linkedct:condition ?A4. {{?I linkedct:intervention type “Drug” .
?A4 linkedct:condition name “Breast Cancer”. ?A3 linkedct:intervention ?I .}gjoin
?A5 linkedct:condition ?A6. {{?A8 linkedct:condition name “Lung Cancer” .}gjoin
?A6 linkedct:condition name “Ovarian Cancer”. {?A7 linkedct:intervention ?I .
?A7 linkedct:condition ?A8. ?A7 foaf:page ?fn7 .
?A8 linkedct:condition name “Lung Cancer”. ?A7 linkedct:condition ?A8 .}}}}}gjoin
?I linkedct:intervention type “Drug” {?A4 linkedct:condition name “Breast Cancer” .
} ?A3 linkedct:condition ?A4 .}}} }
(a) Consulta optimizada por RDF-3X (b) Consulta optimizada por OneQL
Figura 3.1: Consultas optimizadas por RDF-3X y OneQL
Sin embargo, si se ejecuta el optimizador presentado en OneQL sobre la misma consulta
que el investigador desea realizar, se obtiene el plan mostrado en la Figura 3.1(b). Se puede
observar que, a diferencia de RDF-3X, el optimizador busca agrupar de cualquier forma
los patrones, es decir, producir un plan arbusto.
Luego de ejecutar cada plan en una m´ quina Sun Fire x4100 con dos procesadores
a
AMD Opteron de la serie 2000, con 1 Mb de cache por nucleo y 10 Gb de RAM, bajo un
´
sistema operativo Linux/CentOS 5.4 de 64 bits, se observa que el plan de RDF-3X tarda 95
minutos y 57.5 segundos, mientras que el plan optimizado tarda 1.5 segundos logrando
disminuir el tiempo de ejecucion en un 94 % con respecto a la consulta original.
´
La razon de que exista tal diferencia entre los tiempos de ejecucion de ambas consultas
´ ´
se debe a que en las fuentes de datos RDF, el tiempo de ejecucion es proporcional a la
´
cantidad de tripletas RDF que son le´das en la evaluacion de la consulta, es decir, la can-
ı ´
tidad de resultados intermedios. Esto sucede por dos razones. La primera, mostrada en
[11], es que los planes lineales izquierdos no siempre son la mejor solucion para consultas
´
RDF. La segunda es que el optimizador est´ disenado para la formacion de grupos estre-
a ˜ ´

35. ´ ´
CAPITULO 3. ANALISIS DEL PROBLEMA 20
llas (que disminuyen la cantidad de resultados intermedios) y la identificacion de planes
´
arbusto, que representan un espacio mayor de posibilidades que el de los planes izquierdos.
7
HASHJOIN
244435
condition_name
HASHJOIN
147936 "Colorectal Cancer".
condition
HASHJOIN foaf:page
1472569
HASHJOIN condition_name
15846
"Breast Cancer".
HASHJOIN intervention
116105 condition
foaf:page
HASHJOIN condition_name
1712 "Lung Cancer".
intervention
HASHJOIN
condition
426 foaf:page
HASHJOIN
intervention
intervention_type "Drug"
113613
intervention
condition_name
condition
"Ovarian Cancer".
foaf:page
Figura 3.2: Plan de ejecucion RDF-3X
´
Si se analiza el plan de ejecucion de la consulta original (Figura 3.2), se puede observar
´
que se genero un total de 2.112.649 resultados intermedios. En contraste, si se analiza el
´
plan de ejecucion de la consulta optimizada (Figura 3.3), se observa que las agrupaciones
´
en estrella logran, en efecto, reducir el tamano de los resultados intermedios a 1.044.361.
˜
Notese que en ambos casos las consultas producen las mismas 7 tripletas como respuesta
´
final.
Por todo esto, el problema de consultar eficientemente datos y relaciones en la CLD
toma gran relevancia, y es el objetivo del optimizador desarrollado en este trabajo.
3.2. Formalizacion del problema
´
Dado un plan aleatorio inicial P perteneciente a una expresion SPARQL Q y una
´
funcion de costos F, se quiere obtener, mediante una secuencia de transformaciones, un
plan P donde el costo estimado de este plan, mediante F, es menor al del plan inicial P.

36. ´ ´
CAPITULO 3. ANALISIS DEL PROBLEMA 21
7
GJOIN
438
70
NJOIN
GJOIN
4737
GJOIN 883
1
11038 GJOIN
condition_name
GJOIN
"Ovarian Cancer"
1 128363 883
intervention_type- 2274 foaf:page condition_name-
1094
-"Drug" -"Colorectal Cancer"
321958 GJOIN
GJOIN intervention condition
GJOIN
intervention 2274
1094 128363 condition_name-
113613 128363
foaf:page 76512 -"Breast Cancer"
NJOIN intervention foaf:page condition
1 intervention
foaf:page
122397 condition
condition_name-
-"Lung Cancer" condition
Figura 3.3: Plan Optimizado
3.3. Complejidad del Problema
A continuacion se presentar´ una formula que dar´ una idea sobre la complejidad
´ a ´ a
del problema tomando en cuenta el tamano del universo de planes de ejecucion para
˜ ´
una consulta de SPARQL, la formula se propone en [26] y su an´ lisis se encuentra en el
´ a
Ap´ ndice D.
e
2(n−1)
S= n−1
× (n − 1)! × 2(n−1)
Donde S es el tamano del espacio de planes a calcular y n es el numero de tripletas que
˜ ´
contiene la consulta. Esta formula considera dos operadores f´sicos.
´ ı

37. Cap´tulo 4
ı
Diseno de la Solucion
˜ ´
En este cap´tulo se muestran los diferentes disenos propuestos durante el desarrollo
ı ˜
de este trabajo de grado. Primero se detallar´ n los componentes pertenecientes a la ar-
a
quitectura de un manejador de documentos RDF, desarrollados en este trabajo. Luego
se mostrar´ n distintas versiones del optimizador desarrollado, llamado COneQL, y para
a
cada una los costos y sus debilidades que obligaron a buscar mejores soluciones.
4.1. Arquitectura
A continuacion se mostrar´ en la Figura 4.1 una arquitectura b´ sica de un manejador de
´ a a
documentos RDF basada en la solucion propuesta por OneQL. Los componentes enmar-
´
cados por la l´nea punteada y sombreados son aquellos que se disenaron e implementaron
ı ˜
durante el desarrollo de este trabajo, siendo la m´ quina de ejecucion un componente ex-
a ´
terno a nuestra implementacion. Estos ser´ n explicados a continuacion y son comunes a
´ a ´
todas las soluciones descritas en este cap´tulo.
ı
CONSULTA
EN
SPARQL
PARSER
Representación
Interna del
CATÁLOGO Árbol Lógico
MODELO
DE OPTIMIZADOR
COSTOS
Árbol Físico
DOCUMENTOS
RDF
MÁQUINA
DE
EJECUCIÓN
Figura 4.1: Arquitectura del manejador de documentos RDF
22

38. ´ ˜ ´
CAPITULO 4. DISENO DE LA SOLUCION 23
4.1.1. Parser
El primer paso necesario para la optimizacion de una consulta es analizarla y trans-
´
formarla en estructuras que puedan ser manejadas por el optimizador. Por este motivo
el parser fue disenado para recibir consultas SPARQL y extraer la informacion necesaria
˜ ´
de estas, es decir, extraer los patrones que conforman la cl´ usula WHERE de la consulta
´ a
y la cl´ usula SELECT. Todo esto es necesario para generar una consulta optimizada que
a
produzca los mismos resultados que la consulta original.
El parser luego de separar los elementos del SELECT y los patrones, los almacena segun
´
el caso. Para el caso del SELECT almacena la cl´ usula completa, ya que esta luego va a
a ´
ser anadida a la consulta optimizada que se genere. En el caso de los patrones, estos son
˜ ´
analizados y transformados en una estructura definida para representar las tripletas RDF.
Dicha estructura consiste en tres campos de texto, que representan sujeto, predicado y
valor respectivamente. De forma simult´ nea se construye un diccionario, que es utilizado
a
´
para la generacion de planes. Esto se puede observar de forma general en la Figura 4.2.
´
DICCIONARIO
WHERE DE
(String) TRIPLETAS
(Estructura)
CONSULTA
PARSER
SPARQL
AÑADIDO LUEGO
SELECT
A LA CONSULTA
(String)
RESULTANTE
Figura 4.2: Arquitectura del Parser
4.1.2. Optimizador
La entrada del optimizador es una representacion interna que simboliza un arbol logico
´ ´ ´
obtenido del parser sobre la consulta original. Esta representacion es un diccionario que
´
almacena todos los patrones que conforman a la consulta.
El optimizador de consultas, componente vital de todo manejador de documentos RDF,
se basa en una adaptacion del Simulated Annealing para consultas SPARQL. Este algoritmo
´
es el encargado de recorrer el universo de planes y realizar las transformaciones necesarias,
asegur´ ndose en todo momento de evitar la formacion de productos cartesianos. En el
a ´