• Save
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Upcoming SlideShare
Loading in...5
×
 

Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica

on

  • 697 views

 

Statistics

Views

Total Views
697
Views on SlideShare
697
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica Document Transcript

  • 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
  • Desarrollo de un optimizador de consultas en SPARQL para la Nube Enlazada de Datos. Por Mireya Gonz´ lez, Jos´ Riera a e RESUMENLa Nube Enlazada de Datos es un gran repositorio de billones de tripletas de datos, enformato 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 arutinaria 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 aEnlazada de Datos, el problema de identificar planes eficientes es complejo y costoso. Eneste trabajo, se propone desarrollar un optimizador, llamado COneQL, para consultas enSPARQL, 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 cantidadde patrones que posea la misma. El optimizador implementado recibe una consulta enSPARQL, 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 aresultados obtenidos demuestran que el optimizador puede producir planes eficientes encomparacion a otros manejadores existentes. ´ ii
  • Agradecimientos A mi familia, por ser un apoyo incondicional siempre, sin importar las decisiones quetome 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 detrabajo. Mireya Gonz´ lez Arreaza a iii
  • A la Profesora Mar´a Esther Vidal por su extraordinaria guiatura acad´ mica, por su ı egran vocacion profesoral, por su eterna disponibilidad y compromiso a cualquier duda ´durante el desarrollo de este proyecto y por sus grandes cualidades humanas que siemprenos 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 aculminado con muchos frutos. A mi madre, Janette S´ nchez, por su eterno e invaluable apoyo en los momentos adif´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 esea 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 ˜ ecompart´ con muchos amigos decepciones y alegr´as. ı ı Jos´ H. Riera e iv
  • ´Indice generalAgradecimientos iii´Indice general v´Indice de tablas ix´Indice de figuras xGlosario de T´ rminos e xiCap´tulo 1. Introduccion ı ´ 1Cap´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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Cap´tulo 3. An´ lisis del Problema ı a 18 3.1. Ejemplo Motivador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 v
  • 3.2. Formalizacion del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 ´ 3.3. Complejidad del Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Cap´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
  • 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Bibliograf´a ı 60Ap´ 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) . . . . . . . . . . . . . . . . . 65Ap´ ndice B. Reglas de Transformacion e ´ 68Ap´ ndice C. Otros Trabajos Relacionados e 69 C.1. Arquitectura de OneQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 vii
  • C.2. Otros Manejadores de Documentos RDF . . . . . . . . . . . . . . . . . . . . . 69Ap´ ndice D. Complejidad del Problema e 71Ap´ ndice E. Algoritmos Implementados e 72 E.1. Simulated Annealing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 E.2. Muestreo Adaptativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Ap´ 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
  • ´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
  • ´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
  • 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 aA.2. Crecimiento de La Nube de Datos Enlazados [9] . . . . . . . . . . . . . . . . 66A.3. Nube de Datos Enlazados (actualmente) [9] . . . . . . . . . . . . . . . . . . . 67C.1. Arquitectura del sistema OneQL . . . . . . . . . . . . . . . . . . . . . . . . . 69F.1. Consulta q01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77F.2. Consulta q02 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77F.3. Consulta q03 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78F.4. Consulta q04 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78F.5. Consulta q05 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78F.6. Consulta q06 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78F.7. Consulta q07 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79F.8. Consulta q08 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79F.9. Consulta q09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79F.10. Consulta q10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79F.11. Consulta q01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80F.12. Consulta q02 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80F.13. Consulta q03 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80F.14. Consulta q04 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80F.15. Consulta q05 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81F.16. Consulta q06 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81F.17. Consulta q07 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81F.18. Consulta q08 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81F.19. Consulta q09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82G.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
  • 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
  • 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
  • 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 lasm´ 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 millonesde tripletas con billones de interrelaciones entre ellas. Por ejemplo para la enfermedaddel 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, ı aentre 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 deejecucion 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 queel optimizador COneQL pueda desarrollar planes de ejecucion correctos y eficientes, se ´plantean los siguientes objetivos espec´ficos: ı 1
  • ´ ´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 ı ı aestudio experimental de las soluciones, y finalmente, las conclusiones y recomendacionesse encuentran en el cap´tulo 7. ı
  • Cap´tulo 2 ı Marco Teorico ´ En este cap´tulo se expone todos aquellos elementos teoricos de inter´ s para desarro- ı ´ ellar 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- arentes componentes para consultar documentos RDF. Seguidamente se explica qu´ es un eoptimizador y los elementos que lo conforman y soportan. Por ultimo se mencionar´ n los ´ asistemas 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 asion de la misma. La Web Sem´ ntica consiste en meta-datos que describen el significado ´ ade 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 e2.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 aa la WWW, que pueden llegar a incluir personas y lugares, o aquellos conceptos m´ s aabstractos 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
  • ´ ´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 representadosen el formato est´ ndar de RDF. La forma en la que el protocolo HTTP reconoce qu´ tipo a ede 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. a2.1.2. Resource Description Framework (RDF) El W3C se ha encargado de que esta extension de la Web est´ bien estructurada, es por ´ eeso 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 existenformatos distintos de documentos RDF que son aprobados por la W3C, todos se basan enla misma estructura primaria, tripletas o patrones. Las tripletas son la unidad principalde cualquier documento RDF. Una tripleta est´ compuesta por: sujeto, predicado y valor u objeto. Tal como se observa aen la Figura 2.1, el sujeto de la tripleta debe ser un URI que describa al recurso a sermodelado, 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 aqu´ 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.
  • ´ ´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] a2.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 aconsultar cualquier documento RDF [10]. Las variables son utilizadas tanto para extraerinformacion de una consulta, como para representar un objeto que une a dos o m´ s fuentes ´ ade datos distintas; estas pueden aparecer en los tres elementos que conforman las tripletas. ´
  • ´ ´CAPITULO 2. MARCO TEORICO 6En 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 apara publicar e interrelacionar datos estructurados en la Web. Estas pr´ cticas propuestas por Tim Berners-Lee son conocidos como los principios de aLa 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 laNube Enlazada de Datos, es por esto que una propiedad importante que debe cumplir todoURI 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, ´ aeste 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 ael 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
  • ´ ´CAPITULO 2. MARCO TEORICO 72.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 ´ apuntos de acceso pueden ser vistos como una interfaz sobre una fuente de datos, tanto enla 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 ´ eser 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 Datos2.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 ´ auna 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 ´
  • ´ ´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 ´ apara responder una consulta. Tales pasos representan las distintas subconsultas en las quela 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).
  • ´ ´CAPITULO 2. MARCO TEORICO 9Planes 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 Arboles2.2.1.4. Grupos Estrella Un grupo estrella es un conjunto de tripletas o patrones de una consulta que cumplenla 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 agrupo. 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 losconjuntos 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 aresultados del resto de las tripletas pertenecientes al grupo estrella para que tenga unabaja cardinalidad.
  • ´ ´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 ?A2.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
  • ´ ´CAPITULO 2. MARCO TEORICO 11un 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. Estese encarga de estimar y predecir el desempeno de un plan bas´ ndose en el an´ lisis de ˜ a aestad´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 aMuestreo 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 ´ aCap´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 sistemaes 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 trabajose 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.
  • ´ ´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 een 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 determinanest´ 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 ade 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. ´ eLuego la cardinalidad o costo m´ ximo obtenido es utilizado como cota superior para el ac´ 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 acosto de los datos, en lugar de hacer suposiciones sobre estos, se obtienen din´ micamente ´ alas caracter´sticas de estos datos. ı
  • ´ ´CAPITULO 2. MARCO TEORICO 132.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 inicialy 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 aopcion. 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 ˜ ´ aelegido anteriormente. Esto es una t´ cnica comun de un Simulated Annealing para evitar e ´
  • ´ ´CAPITULO 2. MARCO TEORICO 14quedarse 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 latemperatura.2.3. Sistemas Manejadores de Documentos RDF En el ambito de la Web Sem´ ntica existen manejadores desarrollados para manipular ´ adocumentos RDF de forma eficiente, como: Sesame [13], AllegroGraph [14], Fletcher etal [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 amanejadores son las distintas t´ cnicas y estrategias que utilizan para ejecutar una consulta; ev´ ase el Ap´ ndice C. Adem´ s de los trabajos ya mencionados existen otros manejadores e e acomo son OneQL [4] y RDF-3X [3] que se explicar´ n a continuacion, adem´ s de Berkeley a ´ aDB. Ninguna de estas soluciones nombradas, logran escalar para consultas de cualquiertipo 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 indexarlas 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 ase 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 quese desarrollo, Prolog. Al basarse en un lenguaje interpretado tarda un tiempo considerable ´
  • ´ ´CAPITULO 2. MARCO TEORICO 15en 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 yrazonamiento, 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 ı amodelacion de todas ontolog´as, en este cat´ logo se almacenan los costos de inferir hechos ´ ı aintensionales, 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 acosto 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 ı aintensionales y extensionales, utilizando respectivamente el Muestreo Adaptativo y unmodelo 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 enla cl´ usula WHERE. Un algoritmo de programacion din´ mica que se enfoca en conseguir a ´ aplanes 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 ´ ´ ereescritura de Magic Sets al plan obtenido en la primera fase. Luego est´ la estructura Bhyper, basada en un hipergrafo, utilizada para indexar los apredicados 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 ados 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.
  • ´ ´CAPITULO 2. MARCO TEORICO 162.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 ´ ı ade 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 declave/valor, el cual posee un alto rendimiento para grandes volumenes de datos debido a ´
  • ´ ´CAPITULO 2. MARCO TEORICO 17su 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-valorcon 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 eque soporta. Esto elimina las ventajas de usar un lenguaje de consultas estandarizado, perotambi´ n permite al programador acceder o modificar los datos y tomar ciertas decisiones ede 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. ´
  • 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- ´ adiana, luego se mostrar´ una definicion formal del problema, por ultimo se indicar´ una a ´ ´ aformula 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 cienciam´ 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- ı edos por las respectivas drogas, la ubicacion geogr´ fica donde fue realizado dicho estudio, ´ aentre 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 interesadase enfrentar´a a uno de los problemas claves en el area de la Web Sem´ ntica: el poder ı ´ aconsultar de forma eficaz la informacion que se encuentra en la NED. Lo m´ s probable, si ´ ala 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 mejorrendimiento. En dicho caso, la consulta SPARQL ser´a un plan lineal izquierdo que lucir´a ı ıcomo en la Figura 3.1(a). 18
  • ´ ´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 ?ISELECT 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 consultaque el investigador desea realizar, se obtiene el plan mostrado en la Figura 3.1(b). Se puedeobservar que, a diferencia de RDF-3X, el optimizador busca agrupar de cualquier formalos patrones, es decir, producir un plan arbusto. Luego de ejecutar cada plan en una m´ quina Sun Fire x4100 con dos procesadores aAMD 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 95minutos y 57.5 segundos, mientras que el plan optimizado tarda 1.5 segundos lograndodisminuir 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 ˜ ´
  • ´ ´CAPITULO 3. ANALISIS DEL PROBLEMA 20llas (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 CLDtoma 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, unplan P donde el costo estimado de este plan, mediante F, es menor al del plan inicial P.
  • ´ ´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 Optimizado3.3. Complejidad del Problema A continuacion se presentar´ una formula que dar´ una idea sobre la complejidad ´ a ´ adel 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 ´ aAp´ 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. ´ ı
  • 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- aquitectura de un manejador de documentos RDF, desarrollados en este trabajo. Luegose mostrar´ n distintas versiones del optimizador desarrollado, llamado COneQL, y para acada 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 adocumentos 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
  • ´ ˜ ´CAPITULO 4. DISENO DE LA SOLUCION 234.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 motivoel 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 ´ ay la cl´ usula SELECT. Todo esto es necesario para generar una consulta optimizada que aproduzca 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 yvalor 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 Parser4.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 ´
  • ´ ˜ ´CAPITULO 4. DISENO DE LA SOLUCION 24Ap´ ndice E se muestra un pseudocodigo de como funciona la adaptacion del Simulated e ´ ´Annealing realizada para este trabajo. La seleccion de cu´ l transformacion aplicar se basa en las probabilidades planteadas ´ a ´en [11]. La forma de elegir una regla es generando un numero aleatorio p, tal que 0 < p ≤ ´ n i=1 pi , donde n es la cantidad de reglas y pi es la probabilidad de la i-´ sima regla. Este em´ todo es conocido como “Seleccion Proporcional a su Probabilidad” [27]. e ´4.1.3. Modelo de Costos El modelo de costos es un h´brido conformado por un modelo de costos tradicional ıbasado en el Sistema R y en el algoritmo de Muestreo Adaptativo. Fue necesario considerarun algoritmo de estimacion din´ mica para lograr estimaciones sobre los grupos estrellas, ´ adebido a que pequenas alteraciones en estos grupos afectan su costo y cardinalidad. ˜4.1.3.1. Modelo basado en el Sistema R El modelo de costos tradicional se basa principalmente en las estad´sticas y formulas ı ´para calcular el costo de un plan de ejecucion. Existen dos tipos de estad´sticas utilizadas ´ ıpor este modelo, el primer tipo son aproximaciones tomadas de un cat´ logo. Las formulas a ´utilizadas para calcular el costo de los operadores f´sicos se basan en las formulas de los ı ´modelos tradicionales, con la adaptacion para el operador GJOIN, ya que este representa ´ ´una nueva forma de realizar el join entre dos arboles. ´ Este modelo usa un cat´ logo para consultar las estad´sticas que necesite sobre las a ıcardinalidades de las tripletas. Este modelo ser´ explicado en detalle en la seccion 4.1.4. a ´4.1.3.2. Muestreo Adaptativo El algoritmo presentado en el Ap´ ndice E es la implementacion del Muestreo Adaptativo e ´para el optimizador presentado en este trabajo. Se decide modificar la forma como se ´instancia un valor en la tripleta y se calcula la cardinalidad m´ xima de las instancias; en avez de realizar las dos actividades por separado, se realizan en un solo paso, es decir,se instancia y calcula la cardinalidad m´ xima simult´ neamente. Con esta modificacion a a ´
  • ´ ˜ ´CAPITULO 4. DISENO DE LA SOLUCION 25solamente se instancia el 2 % de la poblacion de la tripleta pivote y, por esto mismo, se ´disminuye el tiempo de ejecucion del muestreo al disminuir los accesos a disco. Este ´diseno es utilizado por todas nuestras soluciones. ˜4.1.4. Cat´ logo a El cat´ logo es una estructura para almacenar las estad´sticas para que puedan ser a ı a ´accedidas r´ pidamente. Este se genera mediante la ejecucion de un script que recolecta ´toda la informacion necesaria de una base de datos en espec´fico en una m´ quina local. ´ ı aSu diseno est´ constituido por dos diccionarios que utilizan como clave los distintos ˜ apredicados, y donde, respectivamente, en uno se almacenan las cardinalidades de lossujetos y en el otro las cardinalidades de los objetos.4.1.5. Estructuras para almacenar documentos RDF Los datos RDF de un documento se almacenan en una base de datos de BerkeleyDB.Cada base de datos est´ conformada tal como se muestra en la Figura 4.3. Estas bases de adatos se acceden utilizando el API proporcionado por el mismo BerkeleyDB en C++. ÍNDICES BASE DE DATOS SUJETO-PREDICADO VALOR PRINCIPAL IDENTIFICADOR VALOR PREDICADO VALOR PREDICADO-VALOR VALOR Figura 4.3: Esquema de las Bases de Datos de BerkeleyDB Debido a que se incurr´a en accesos directos a claves, y no por rango, se decide crear ıuna base de datos con la estructura tipo Hash, que es m´ s eficiente para este caso. Junto acon la base de datos principal se construyeron tres tipos distintos de ´ndices, basados en las ıposibles combinaciones de los roles instanciados que se observaron en los patrones dentro
  • ´ ˜ ´CAPITULO 4. DISENO DE LA SOLUCION 26de las consultas. Las claves para dichos ´ndices fueron las combinaciones de predicado, ısujeto-predicado y predicado-valor.4.2. Diseno de COneQL version 1 ˜ ´ El elemento fundamental de este diseno fue la definicion de las estructuras logicas y ˜ ´ ´f´sicas. En cuanto al arbol logico, solo se manejan las hojas que lo conforman, representadas ı ´ ´ ´a trav´ s de un diccionario de los patrones que forman la consulta. Es el optimizador el eencargado de generar, a partir de este diccionario, el arbol f´sico inicial al que se le ´ ıaplican las t´ cnicas de optimizacion. Para el arbol f´sico, se disenan nodos que manejan la e ´ ´ ı ˜informacion necesaria tal como el tipo de nodo, el cual var´a si este es una hoja o no. ´ ´ ı ´ Se construye un diccionario, donde se guardan todos los nodos y para cada uno se tieneel identificador del nodo y su posicion en el arbol para localizarlo al recorrer el mismo. ´ ´Para el momento de ejecutar el algoritmo Simulated Annealing y escoger a qu´ nodo se le eaplicar´ una transformacion, se aplica una pol´tica donde se selecciona sobre el diccionario a ´ ıde nodos cualquier tipo de nodo, incluyendo nodos tipo hoja, a los cuales no es logico ´seleccionar para aplicar algunas transformaciones. Diccionario de Nodos Diccionario de Tripletas OPERADOR LÓGICO OPERADOR LÓGICO Figura 4.4: Estructuras del optimizador COneQL v1 En la Figura 4.4 se muestran las distintas estructuras creadas para el optimizadorCOneQL v1. La generacion del plan inicial del cual se partir´ el recorrido por el universo de planes ´ a
  • ´ ˜ ´CAPITULO 4. DISENO DE LA SOLUCION 27es generado totalmente aleatorio, esto unido a la naturaleza de la construccion del plan, ´ ´genera arboles que tienden a planes donde en la mayor´a de sus hijos izquierdos son ´ ıgrupos estrellas, tal como se muestra en la Figura 4.5. Un detalle de la generacion del ´plan inicial es que la estructura arbol generada est´ basada en el tipo b´ sico String lo cual ´ a aobliga a diferentes transformaciones entre un String y el tipo abstracto de datos Tripleta,lo que ralentiza el desempeno del optimizador. ˜ Figura 4.5: Plan inicial, optimizador COneQL v1 La pol´tica de seleccion de nodos al momento de aplicar una regla es aleatoria, y por ser ı ´tan simple muchas veces ocurre que para dicha regla no aplica el nodo seleccionado. Altener poca eficacia en la aplicacion de transformaciones, adem´ s de la forma de los planes ´ ainiciales obtenidos, se tiene que, muchas veces los planes resultantes del optimizadortienden a ser poco balanceados, al igual que el plan inicial.4.3. Diseno de COneQL version 2 ˜ ´ Este diseno busca mejorar al optimizador v1 en el problema de la pol´tica de selec- ˜ ıcion de nodos para as´ directamente mejorar la eficacia de aplicacion de las reglas. La ´ ı ´solucion se basa en inicializar el diccionario por cada regla, en donde solo se listan los ´ ´nodos que cumplan con las condiciones necesarias para aplicarle dicha regla. Esto mejoraenormemente la probabilidad de aplicacion de una regla. ´ Adem´ s de esta estrategia para enfrentar el problema en la seleccion de los nodos, a ´tambi´ n se agrega un numero de intentos para conseguir un nodo al que se le pudiera e ´
  • ´ ˜ ´CAPITULO 4. DISENO DE LA SOLUCION 28aplicar la regla. Con estas t´ cnicas se observa emp´ricamente, que se aumenta la cantidad de reglas e ıaplicadas de manera efectiva a un plan de ejecucion, pero estos cambios tambi´ n afectan ´ edirectamente el tiempo de ejecucion del optimizador al tener que hacer m´ s verificaciones ´ aen la creacion del diccionario de nodos. Las estructuras auxiliares del optimizador v2 son ´las mismas al del optimizador v1, por lo tanto el diseno es equivalente al de la Figura 4.4. ˜4.4. Diseno de COneQL version 3 ˜ ´ Con el problema de seleccion de nodos resuelto por el optimizador v2 se disena el ´ ˜optimizador v3 para no realizar constantes c´ lculos sobre informacion de los sub´ rboles a ´ aque pueden almacenarse y modificarse solo cuando es necesario. Es por esto que se ´decide modificar la estructura que representa el arbol f´sico, y agregarle m´ s informacion ´ ı a ´a la estructura Nodo, para lograr disminuir la cantidad de c´ lculos necesarios para las averificaciones y la aplicacion de reglas. La informacion que se agrega son las variables que ´ ´proyecta el sub´ rbol y las variables utilizadas por el operador: en caso de ser un grupo aestrella ser´a la variable en comun; en caso de ser un join ser´an las variables por las cuales ı ´ ılos dos sub´ rboles hacen join. a Adem´ s de agregar informacion al arbol se crean dos estructuras auxiliares, la primera a ´ ´es una mejora al diccionario de nodos del optimizador v1, donde para cada identificador denodo se indexa un apuntador a cada nodo; la segunda estructura es un nuevo diccionariode variables, que almacena por variable los patrones que la usan, para as´ facilitar la ıgeneracion de planes. Esta segunda estructura provee informacion al optimizador para ´ ´formar arboles f´sicos aleatorios y m´ s eficientes del arbol logico. ´ ı a ´ ´ En la Figura 4.6 se muestran las distintas estructuras creadas para el optimizadorCOneQL v3.
  • ´ ˜ ´CAPITULO 4. DISENO DE LA SOLUCION 29 Diccionario Diccionario de Nodos de Tripletas Diccionario OPERADOR LÓGICO de Variables OPERADOR OPERADOR LÓGICO LÓGICO Figura 4.6: Estructuras del optimizador COneQL v3 En este nuevo diseno, se replantea la estrategia sobre la construccion del plan inicial, ˜ ´intentando lograr mayor aleatoriedad con el proposito de conseguir mejores planes. Esta ´nueva estrategia se basa en tomar como hojas iniciales los grupos estrellas. Estos gruposestrellas se forman primero eligiendo aleatoriamente alguna tripleta y luego formando elgrupo estrella con m´ s patrones. La estrategia del plan inicial se basa en unir pares de anodos de una lista hasta que solo queda un nodo, el cual representara el nodo ra´z del arbol ´ ı ´inicial. La aleatoridad se da al elegir no determin´sticamente los pares y el operador por ıel cual se van a unir. Con este cambio se logra disminuir las constantes transformacionesentre el tipo String y el tipo compuesto Tripleta para que trabaje directamente con Tripletay el tipo Nodo, logrando un mejor rendimiento del programa.4.5. Diseno de COneQL version 4 ˜ ´ Los optimizadores v1, v2 y v3 no realizan un manejo correcto de la memoria cach´ del edisco por la gran cantidad de resultados que genera una consulta. Por esta razon, se anade ´ ˜el optimizador v4, el cual agrega una estructura que trabaja como una memoria cach´ . eLa primera estimacion de un grupo estrella se realiza mediante Muestreo Adaptativo y ´los resultados obtenidos son almacenados en esta estructura, para luego ser reutilizadacuando el grupo estrella se estime nuevamente. Tambi´ n se decide crear dos estructuras extras que dividen a los nodos segun la altura e ´
  • ´ ˜ ´CAPITULO 4. DISENO DE LA SOLUCION 30que posean. De esta manera se tiene un filtro extra al momento de seleccionar qu´ nodo ecorresponde a cada regla segun su altura. ´ Otra modificacion realizada en el diseno del optimizador v4, es mejorar la formacion ´ ˜ ´de los grupos estrellas en la generacion del plan inicial. En lugar de simplemente buscar ´una tripleta por la cual formar un grupo estrella, se decide buscar aleatoriamente entrelas tripletas con m´ s variables instanciadas y realizar la formacion del grupo estrella con a ´alguna de estas como pivote. En la Figura 4.7 se muestran las distintas estructuras creadas ´para este optimizador COneQL v4. Diccionario Diccionario de Nodos para de Tripletas subnivel = 1 Diccionario de Nodos para subnivel > 1 Diccionario OPERADOR LÓGICO de Variables OPERADOR OPERADOR LÓGICO LÓGICO Estructura tipo Caché Figura 4.7: Estructuras del optimizador COneQL v4
  • Cap´tulo 5 ı Implementacion ´ En este cap´tulo se describen todos los detalles relevantes a la implementacion de ı ´los optimizadores basado en cap´tulo 4. Se explicar´ a un nivel m´ s t´ cnico, como se ı a a e ´implementaron las soluciones discutidas en el cap´tulo anterior. ı5.1. COneQL version 1 ´ Esta version del optimizador crea las bases de Berkeley DB por medio del API de ´C++, tomando en consideracion las distintas caracter´sticas y ventajas del lenguaje. En el ´ ıdiagrama de clases de la Figura 5.1 se muestran las clases implementadas y sus contenidosm´ s importantes. a Parser Arbol +raiz: Nodo +extraer_select_y_where(): String +cardinalidad: double +transformar_a_tripleta(): map<Tripleta> +costo: double +actual: Nodo Simulated Annealing +gen_plan_inicial(): Arbol Nodo +simetria(a:Arbol): Arbol +id: int +asociatividad(a:Arbol): Arbol +tipo: char +distributividad(a:Arbol): Arbol +izq: Nodo +agrupacion(a:Arbol): Arbol +der: Nodo +union(a:Arbol): Arbol +sub_niv: int +desunion(a:Arbol): Arbol +comparar_planes(old:Arbol,new:Arbol): bool Tripleta +sujeto: String Modelo de Costo +predicado: String Muestreo Adaptativo +valor: String +calcular_costo(): double +indice: MiBD +calcular_card(): double +grupo_estrella: vector<Tripleta> 1 contiene +catalogo: Catalogo 1 4 Sistema R 4 posee 1 MiBD +indice: MiDB +catalogo: Catalogo 1 consulta 1 Catalogo utiliza 1 +card_sujeto: map<int> +card_valor: map<int> Figura 5.1: Diagrama de clases para la primera solucion ´ 31
  • ´ ´CAPITULO 5. IMPLEMENTACION 32 ´ La primera clase que se invoca cuando comienza el optimizador es la clase Parser. Estacumple con la funcionalidad de leer y extraer los patrones que conforman la consulta yla cl´ sula SELECT. El parser primero separa la cl´ usula SELECT y la WHERE, para luego a aprocesar y analizar esta ultima y as´ producir los distintos patrones que conforman la ´ ıconsulta. Simult´ neamente, estos patrones son almacenados en el diccionario de tripletas, arepresentado en C++ mediante un map de tipo Tripleta para as´ facilitar el acceso directo ıy las verificaciones y evitar patrones repetidos. El componente m´ s importante para la representacion y manejo de documentos RDF a ´es la tripleta. La clase Tripleta contiene tres Strings para representar cada uno de los rolesde una tripleta RDF: sujeto, predicado y valor. Los objetos de tipo Tripleta son almacenados dentro del arbol f´sico en una instancia de ´ ıla clase Nodo. Esta clase est´ compuesta por un identificador de tipo entero, un tipo para aidentificar si es un nodo interno (que representa un operador) o si es un nodo externo(que posee un conjunto de tripletas), la cantidad de subniveles que lo separa de los nodoshoja, y por ultimo dos apuntadores a sus repectivos hijos, izq y der. ´ Un conjunto de objetos de la clase Nodo forman un objeto de la clase Arbol, clase quealmacena la cardinalidad y costo del plan que representa en forma de double, adem´ s ade poseer una referencia al nodo ra´z del arbol y otra referencia al nodo en el que se ı ´est´ posicionado en el arbol. Un objeto Arbol es generado por el Simulated Annealing a a ´trav´ s del m´ todo gen plan inicial(). En este m´ todo se verifica constantemente que para e e ecada operador f´sico se cumplan las siguientes condiciones: ıGJOIN Solo se puede utilizar este operador en caso de que sus dos hijos sean una com- ´ binacion de sub´ rbol o grupo estrella. ´ aNJOIN Puede ser utilizado con cualquier combinacion de nodos, sean estos un sub´ rbol, ´ a grupo estrella o tripleta El m´ todo gen plan inicial() realiza la eleccion aleatoria de una tripleta y un operador e ´(f´sico o formacion de grupo estrella), verificando que para el operador f´sico se cumplan ı ´ ı
  • ´ ´CAPITULO 5. IMPLEMENTACION 33las condiciones explicadas anteriormente, y que para el grupo estrella exista un patron ´con el que se pueda formar el conjunto. Al basarse en el tipo String, es necesario lacontinua transformacion entre este tipo y la clase Tripleta, y una vez formado el plan, la ´conversion de este al tipo Nodo. Por la forma en que se realiza dicha conversion, los planes ´ ´ ´generados tienen la forma explicada en el Cap´tulo 4. El arbol resultante de este m´ todo ı ´ ede generacion de planes representa la semilla a la que se le va a aplicar de forma aleatoria ´las 6 posibles transformaciones en cierta cantidad de escenarios, siempre comparando, atrav´ s del m´ todo comparar planes(), si el plan obtenido de la transformacion aplicada es e e ´mejor al plan antes de dicha aplicacion, para as´ decidir si el optimizador continua con el ´ ınuevo plan o con el plan anterior. Aleatoriamente, bas´ ndose en el mecanismo de seleccion por probabilidades, se elige a ´la regla de transformacion que se va a aplicar. Una vez seleccionada la regla, se procede ´a elegir aleatoriamente el nodo del arbol al que se le va a aplicar dicha regla, y en caso ´de que cumpla con las condiciones espec´ficas para esa regla, se procede a modificar el ıarbol a partir del nodo elegido. A falta de informacion provista por las estructuras, es´ ´necesario el c´ lculo constante de informacion que resulta necesaria para la aplicacion de a ´ ´las reglas, tal como la variable en comun de un grupo estrella. Igualmente, debido a la ´ ´poca informacion que se maneja en la clase Nodo, realizar las modificaciones necesarias ´para aplicar una regla es mucho m´ s sencillo de efectuar, ya que no existen referencias acruzadas entre los nodos o estructuras que rellenar y modificar constantemente. La forma como se implementa la seleccion de los nodos una vez elegida una regla, es a ´ ´trav´ s de un diccionario de tipo Nodo, mediante la estructura map de C++. Esta almacena eun identificador por nodo y una cadena de caracteres que representa el camino a recorreren el arbol para poder alcanzar dicho nodo, en otras palabras, indica si tiene que ir por ´el hijo izquierdo o derecho y en qu´ orden, para llegar al nodo deseado. La decision de e ´escoger un map como solucion se debe a las facilidades que ofrece este tipo de estructura ´para ordernar sus objetos mediante la clave del diccionario y por su flexibilidad parainsertar nuevos elementos a la estructura. Este diccionario se genera cada vez que se va a
  • ´ ´CAPITULO 5. IMPLEMENTACION 34aplicar una regla. La clase Simulated Annealing representa el esqueleto del algoritmo de optimizacion. A ´partir de ella se realizan las llamadas principales a los diferentes modulos del optimizador. ´Adem´ s de la implementacion de las reglas y otros m´ todos, la clase se encarga de la a ´ eactualizacion de la temperatura al terminar cada iteracion y la seleccion aleatoria de las ´ ´ ´reglas probabil´sticamente, entre otras funcionalidades. ı El Modelo de Costo es una superclase compuesta por dos subclases: Muestreo Adaptativoy Sistema R, que constituyen un modelo de costo h´brido. La clase Modelo de Costo recibe ıun plan de ejecucion como par´ metro y se encarga de dividir este, en las subconsultas ´ a ´pertinentes para cada subclase, para que estas calculen los costos y cardinalidades. ´ Las subclases Muestreo Adaptativo y Sistema R usan a la clase MiBD para comunicarsecon los datos almacenados a trav´ s de BerkeleyDB. Esta clase es la encargada de abrir y eacceder tanto a la base de datos como a los ´ndices; sirve como una capa de interfaz entre ıel optimizador y los datos que se quiere acceder. La subclase Muestreo Adaptativo es la encargada de realizar los c´ lculos de los costos asobre los grupos estrellas. Esta clase posee tres atributos importantes: los ´ndices de tipo ıMiBD, una instancia de Catalogo, que permite la obtencion r´ pida de la cardinalidad ´ apara aquellas tripletas pivote que solo tienen instanciado el predicado, y por ultimo un ´ ´vector<Tripleta> que almacena el grupo estrella al cual se le realizar´ n los c´ lculos. a a Este algoritmo se puede dividir en dos etapas. La primera consiste en el c´ lculo de ala cardinalidad m´ xima. Para esto se extrae y se almacena en un map una instancia de ala variable comun del grupo estrella de la tripleta pivote, y se instancia para el resto del ´grupo. Luego, a trav´ s de la funcion count() de Berkely DB, se busca la cardinalidad total en e ´base a la cardinalidad de cada patron. Este procedimiento se repite hasta obtener el 2 % de ´la poblacion de la tripleta pivote y se guarda la mayor cardinalidad obtenida. De acuerdo ´al tipo de tripleta instanciada se obtiene el tamano de la poblacion mediante la instancia ˜ ´de Catalogo solo cuando est´ instanciado el predicado o mediante la misma funcion count() ´ a ´de BerkeleyDB solo cuando existen dos elementos de la tripleta instanciados. ´
  • ´ ´CAPITULO 5. IMPLEMENTACION 35 La siguiente etapa del algoritmo consiste en utilizar como cota la cardinalidad m´ xima aobtenida en la primera parte, para ir seleccionando aleatoriamente una instancia alma-cenada en el map, e ir sumando las cardinalidades resultantes de instanciar en el grupoestrella dicha instancia. El Sistema R [28] es la clase encargada de realizar los c´ lculos sobre los operadores af´sicos de ejecucion. Estos c´ lculos se basan en las estad´sticas de la clase Catalogo y en las ı ´ a ıestad´sticas calculadas con la funcion count() de BerkeleyDB, y las formulas a utilizar son ı ´ ´implementadas en C++ siguiendo las formulas del modelo relacional. ´ La clase Catalogo almacena las estad´sticas de los datos. Mediante la ejecucion de un ı ´script se calculan cotas inferiores y superiores por predicado, para cada sujeto y valorencontrado en la fuente de datos. Estas cardinalidades de los sujetos y de los valores obte-nidas por dichos c´ lculos se almacenan en dos map propios de C++ llamados card sujeto ay card valor, respectivamente.5.2. COneQL version 2 ´ La mejora del optimizador v2 sobre el v1 es la forma en la que se construye el diccionariode los nodos pertenecientes a un arbol. Por lo tanto las clases son iguales al optimizador ´v1 y equivalentes al diagrama de la Figura 5.1. El diccionario de nodos es modificado para que liste para cada regla solo aquellos nodos ´que son pertinentes, tal que la seleccion aleatoria de un nodo que se realiza para una regla ´sea m´ s efectiva. Esta modificacion no altera la forma en la que las clases se relacionan a ´entre ellas, ni como funciona una instancia del Simulated Annealing, pero si logra mejorar ´la probabilidad de aplicacion de las reglas y, en consecuencia, los planes de ejecucion ´ ´producidos por el optimizador. Sin embargo, como la generacion del diccionario se realiza ´constantemente, las modificaciones realizadas tambi´ n traen como consecuencia que el eoptimizador tarde el doble de tiempo en optimizar un plan, debido a las verificacionesque se tienen que hacer en la generacion del diccionario. ´
  • ´ ´CAPITULO 5. IMPLEMENTACION 365.3. COneQL version 3 ´ Esta tercera version del optimizador agrega mayor informacion a los nodos, ya que ´ ´la informacion que las versiones anteriores manejan es poco precisa para seleccionar ´una regla a aplicar. Por eso se decide extender la clase Nodo para que se adapte a loscambios de diseno propuestos. Se observa como cambia unicamente la clase Nodo para ˜ ´este optimizador, en la Figura 5.2. Nodo +id: int +tipo: char padre +izq: Nodo 1 +der: Nodo +sub_niv: int +tipo_hijo: char enlaza +padre: Nodo +var_proyectadas: set<String> +var_join: set<String> hijo 2 Figura 5.2: Diagrama de clases para tercera solucion ´ Lo principal que se agrega al nodo son dos estructuras que almacenan la informacion ´que es constantemente recalculada, para as´ agilizar la aplicacion de las transformaciones: ı ´las variables que proyecta un nodo y las variables que representan al operador, es decir,para un grupo estrella ser´a la variable en comun del mismo y para un nodo intermedio ı ´ser´a las variables por las cuales hacen join. Ambas son estructuras representadas con ıset<String> de C++ ya que previene la posibilidad de valores repetidos. La otra informa-cion que se agrega al nodo es necesaria para agilizar las transformaciones, entre ellas est´ n ´ aun apuntador al padre llamado padre y un char que indica si el nodo en cuestion es hijo ´derecho o izquierdo. Tambi´ n se agrega un multidiccionario de variables de tipo multimap, e ´para facilitar la generacion inicial de planes aleatorios. Este contiene, para cada variable, ´un identificador y la tripleta donde esta est´ contenida. Este diccionario se genera solo una ´ a ´vez justo despu´ s de ejecutar el parser. Este multimap es utilizado en la formacion de los e ´grupos estrellas determ´nisticos, al permitir calcular qu´ variable tiene la mayor cantidad ı ede tripletas asociadas. La generacion de planes iniciales, a diferencia de la generacion utilizada en las ver- ´ ´siones anteriores, se concentra en la produccion de planes de cualquier forma, es decir, ´
  • ´ ´CAPITULO 5. IMPLEMENTACION 37 ´arbustos. Esta consiste principalmente en dos etapas: la primera realiza la formacion de ´los grupos estrellas de manera determin´stica utilizando el multidiccionario de variables, ıy concentr´ ndose en aquellos grupos conformados por la mayor cantidad de patrones, lo aque trae como consecuencia que la construccion de los grupos sea totalmente determ´nisti- ´ ıca. La ventaja del determinismo se observa en la ejecucion del optimizador, donde, por ser ´los mismos grupos estrellas se logra utilizar de forma m´ s eficiente el cach´ y se reducen a elos accesos a discos, mas igual, existen estos accesos y siguen aumentando el tiempo deejecucion de forma considerable. ´ La segunda etapa de la generacion de planes iniciales consiste en utilizar un vector ´como una cola, e ir uniendo pares de nodos hasta quedar con un solo nodo. Los pasos sonlos siguientes: primero se almacenan los nodos generados en la primera etapa, y luegoiterativamente, hasta llegar a la condicion de parada, se van seleccionando aleatoriamente ´pares de nodos y, en caso de ser posible, se unen, se elimina el par de la cola y se introduceel nuevo nodo resultante de la union al final de esta. En esta etapa se mantienen las pautas ´ ´sobre los operadores f´sicos de las otras versiones del optimizador. ı5.4. COneQL version 4 ´ En esta ultima version del optimizador se logra crear una estructura que mejora el ´ ´manejo del cach´ , mostrada en la Figura 5.3. Se usa para almacenar la estimacion de un e ´grupo estrella dado. Esta estructura posee un vector<Tripleta> que representa un grupoestrella al cual se le aplico el Muestreo Adaptativo y dos double: uno para la cardinalidad y ´el otro para el costo que fueron obtenidos como resultado de este algoritmo. Esta estructurase construye la primera vez que estima un grupo estrella, es decir cuando la informacion ´de este grupo aun no ha sido manejada por el optimizador; luego se reutiliza en cada ´momento que se instancie nuevamente este grupo.
  • ´ ´CAPITULO 5. IMPLEMENTACION 38 Informacion_estrella +grupo_estrella: vector<Tripleta> +cardinalidad: double Simulated Annealing +costo: double Muestreo Adaptativo +index: MiBD Modelo de Costo +grupo_estrella: vector<Tripleta> +cache: Informacion_estrella +catalogo: Catalogo Figura 5.3: Diagrama de clases para la ultima solucion ´ ´ Esta estructura mejora dr´ sticamente los tiempos en warm cache, pero aun as´ exige a ´ ıun costo considerable en cold cache, ya que aun se tienen que realizar la misma cantidad ´de operaciones sobre disco. Tambi´ n se modifica la formacion de grupos estrellas para e ´que no sea de forma determin´stica, se enfoca en buscar las tripletas con dos variables ıinstanciadas y con un numero considerable de ocurrencias en la variable no instanciada. ´ NJOIN <http://.../rdf-schema#label> Figura 5.4: Nueva formacion de grupos estrellas ´ De igual forma, se aplica otra t´ cnica en donde, si el optimizador se encuentra con una etripleta que posea el URI <http://www.w3.org/2000/01/rdf-schema#label> como predicadoy tiene otro rol instanciado, se busca el grupo estrella asociado a la variable no instanciaday se unen a trav´ s de un operador NJOIN para disminuir la cantidad de resultados eintermedios generados, tal como se muestra en la Figura 5.4. Una de las caracter´sticas ıparticulares a las tripletas con la descripcion anterior es que poseen una baja cardinalidad ´lo cual evita la generacion de muchos resultados intermedios. ´
  • Cap´tulo 6 ı Experimentacion ´ En este cap´tulo se realiza un estudio experimental para analizar la efectividad del ıoptimizador de consultas desarrollado en este trabajo. Se presentan los tiempos de eva-luacion de los planes arbustos producidos por las versiones del optimizador desarrollado ´COneQL en GRDF-3X [11] desarrollado sobre RDF-3X version 0.3.4. Se comparan los re- ´sultados con RDF-3X, manejador de documentos RDF. Por ultimo se plasman las ventajas ´y desventajas observadas emp´ricamente de cada implementacion. ı ´6.1. Objetivo El objetivo del estudio experimental es analizar de forma emp´rica la calidad de los ıplanes de ejecucion generados y luego ejecutados, tanto en cold cache como en warm cache, ´por las diferentes versiones del optimizador COneQL cuando son ejecutadas en GRDF-3X,donde calidad se mide en funcion del tiempo de ejecucion y optimizacion. ´ ´ ´6.2. Procedimiento Haciendo uso de benchmarks de consultas existentes en la literatura [11] se realizarontres tipos de experimentos donde se identifica para cada consulta el plan generado porpor RDF-3X y el plan generado por cada una de las versiones de COneQL. Cada version ´del plan fue evaluado en GRDF-3X y se midio el tiempo de ejecucion para determinar el ´ ´costo del plan. Los experimentos fueron ejecutados en warm y cold cache. Para evaluar una consulta encold cache se limpia el cach´ antes de cada consulta ejecutando el comando sh -c “sync ; echo e3 > /proc/sys/vm/drop caches”. Mientras que para ejecutar una consulta en warm cache,se ejecutaba la misma consulta cinco veces, limpiando el cach´ justo antes de comenzar la eserie de ejecuciones. 39
  • ´ ´CAPITULO 6. EXPERIMENTACION 40 Se desea observar el comportamiento de los sujetos experimentales en tres aspectosdiferentes:Tiempos de ejecucion en cold cache: se utilizan los 4 optimizadores y el optimizador ´ interno de RDF-3X para obtener planes de cada consulta, luego se limpia el cach´ y e se utiliza, para RDF-3X su m´ quina de ejecucion interna, mientras que para los a ´ optimizadores se utiliza GRDF-3X. Se comparan los tiempos de ejecucion mediante ´ el comando time de Unix.Tiempos de ejecucion en warm cache: se utilizan los 4 optimizadores y el optimizador ´ interno de RDF-3X para obtener planes de cada consulta, luego se limpia el cach´ , se e ejecuta la misma consulta 5 veces consecutivas. Para ejecutar las consultas en RDF- 3X se usa su m´ quina de ejecucion interna, mientras que para los optimizadores a ´ se utiliza GRDF-3X, se toma el mejor de los tiempos de ejecucion. Se comparan los ´ tiempos de ejecucion mediante el comando time de Unix. ´Tiempos totales de ejecucion: es la sumatoria de los tiempos de optimizacion m´ s de ´ ´ a ejecucion. Se utilizan los 4 optimizadores y el optimizador interno de RDF-3X para ´ obtener planes de cada consulta, y para calcular el tiempo de ejecucion se usa, para ´ RDF-3X su m´ quina de ejecucion interna, mientras que para los optimizadores se a ´ utiliza GRDF-3X. Se comparan los tiempos mediante el comando time de Unix.6.3. M´ tricas e Se definen tres m´ tricas para medir los resultados en el proceso de experimentacion, e ´las cuales se detallan a continuacion. ´Tiempo de ejecucion: mide el tiempo en segundos desde el momento que se le env´a ´ ı una consulta a la m´ quina de ejecucion hasta que se obtienen todos los resultados a ´ de la consulta por pantalla. Este tiempo es medido mediante el comando time de Unix.
  • ´ ´CAPITULO 6. EXPERIMENTACION 41Tiempo de optimizacion: mide el tiempo en segundos desde comienza la optimizacion ´ ´ con el uso del parser sobre una consulta hasta el momento que se genera un plan de ejecucion. Este tiempo se mide mediante el comando time de Unix. ´Tiempo total de ejecucion: mide el tiempo en segundos desde que se comienza la op- ´ timizacion de una consulta con el uso del parser hasta que se obtienen todos los ´ resultados de una consulta por pantalla, es decir, est´ conformado por la suma- a toria de los tiempos de ejecucion y optimizacion. Este tiempo tambi´ n es medido ´ ´ e mediante el comando time de Unix.6.4. Configuracion ´ Todos los experimentos que se muestran fueron ejecutados en m´ quinas con las espe- acificaciones de hardware y software mostrados en el Apendice F. Adem´ s, se utiliza el compilador de GCC para C++ en su version 4.1.2. Tambi´ n se usa a ´ eel manejador Berkeley DB en su version 11g release 2, en propiedad de Oracle. Por ultimo ´ ´se hace uso de la m´ quina de ejecucion GRDF-3X, construida sobre RDF-3X version 0.3.4, a ´disenada para manejar de forma eficiente los planes tipo arbusto y los operadores f´sicos ˜ ımencionados en el Cap´tulo 2. ı Para cada version del optimizador implementado en este proyecto se establecieron di- ´ferentes par´ metros y diferentes probabilidades para las reglas de transformacion, ambos a ´conjuntos se pueden observar en la Ap´ ndice F. La temperatura, la cantidad de escenarios ey las probabilidades son establecidos segun el trabajo [11]. ´6.5. Fuentes de Datos y Bancos de PruebasYAGO (Yet Another Great Ontology): YAGO 1 es una fuente de datos derivada de Wiki- pedia, WordNet y GeoNames que incluye informacion de celebridades en diferentes ´ areas, organizaciones, etc. Actualmente YAGO posee m´ s de 10 millones de entida- ´ a des y m´ s de 80 millones de hechos acerca de sus entidades. a 1 YAGO: A Core of Semantic Knowledge. http://www.mpi-inf.mpg.de/yago-naga/yago/.
  • ´ ´CAPITULO 6. EXPERIMENTACION 42LinkedCT (Linked Clinical Trials): LinkedCT 2 es una fuente de datos que intenta rela- cionar datos m´ dicos, tales como el uso de drogas y condiciones patologicas, con e ´ los datos de ensayos cl´nicos. En este momento esta fuente incluye casi 10 millones ı de tripletas, acumulando informacion de 80.239 cl´nicas y organizaciones de salud ´ ı alrededor del mundo.Bancos de Pruebas de las Consultas (Benchmarks) Se consideraron dos conjuntos de consultas a evaluar; el primer banco de pruebas perte-neciente a LinkedCT, el cual llamaremos benchmark 1, consiste en 10 consultas. Igualmentese usa el banco de pruebas perteneciente a YAGO, el cual llamaremos benchmark 2, queconsiste en 9 consultas. Estos benchmarks corresponden a los usados en los experimentosreportados en [11]. Ambos benchmarks son descritos en el Ap´ ndice F en funcion a la cantidad de patrones e ´encontrados en la cl´ usula WHERE y el tamano de la respuesta, basado en el numero de a ˜ ´tripletas producidas. Se clasifican a las consultas en complejas y simples segun la cantidad de patrones que ´posea la consulta y la cantidad de resultados intermedios que se pueden obtener, v´ ase eApendice F. A mayor volumen en La Nube Enlazada de Datos se puede interrelacionarm´ s informacion en busqueda de respuestas m´ s espec´ficas, lo que hace m´ s posible a ´ ´ a ı aque la cantidad de patrones de una consulta aumente. En el benchmark 1 se detectan dosconsultas complejas: q04 y q07; mientras que en el benchmark 2 se identifican tres consultascomplejas: q03, q06 y q09.6.6. Experimento I - Cold Cache El objetivo de este experimento es analizar el comportamiento de las distintas versionesde COneQL y RDF-3X ejecutadas en cold cache. Se realizaron experimentos sobre LinkedCTy YAGO. 2 linkedCT.org
  • ´ ´CAPITULO 6. EXPERIMENTACION 436.6.1. Experimentos sobre LinkedCT En el primer experimento sobre LinkedCT se busca la comparacion de los tiempos de ´evaluacion obtenidos en cold cache de cada una de las versiones del optimizador contra ´RDF-3X, cada una con su respectivo an´ lisis de resultados. a A continuacion se muestran los resultados de los experimentos en la Tabla 6.1, se- ´guidamente se muestra la Figura 6.1 donde se presentan los resultados de las consultascomplejas sobre LinkedCT. V´ ase el Ap´ ndice G para el resto de las gr´ ficas. e e a q01 q02 q03 q04 q05 q06 q07 q08 q09 q10 RDF-3X 6.35s 3.55s 4.13s 5322.9s 6.46s 4.36s 4173.3s 2.75s 3.83s 0.51s Opt. v1 1.5s 1.33s 1.06s 42.5s 894s 1.6s 4s 22.43s 1.4s 0.9s Opt. v2 2.32s 1.62s 1.81s 27.42s 3.4s 311.5s 1.27s 2.5s 1.25s 895.3s Opt. v3 23.6s 3.9s 30.4s 491.5s 104.21s 101.88s 363.8s 146s 186s 98.38s Opt. v4 1.1s 1.2s 3.6s 5.2s 7.9s 1.2s 1.4s 3.36s 2.6s 2sTabla 6.1: Ejecucion en cold cache de RDF-3X y las 4 versiones del optimizador en LinkedCT ´ Figura 6.1: Tiempos de ejecucion de consultas complejas en LinkedCT ´
  • ´ ´CAPITULO 6. EXPERIMENTACION 44 En general se observa que para las consultas complejas q04 y q07 todos nuestrosoptimizadores se comportan mejor que RDF-3X, pero el optimizador v3 es el que obtienetiempos m´ s altos entre todos los optimizadores implementados, esto puede deberse al aespacio limitado de planes que se recorren a causa de los grupos estrellas determin´sticos. ıMientras que los optimizadores v1, v2 y v4 obtienen tiempos que son menores a los deRDF-3X entre 2 y 3 ordenes de magnitud. ´ En las consultas simples (todas excepto q04 y q07) el optimizador v3 no obtiene ningun ´tiempo mejor a los obtenidos por RDF-3X, esto puede ser debido a que RDF-3X puede ´explotar mejor el uso de sus ´ndices y estructuras internas. En los optimizadores v1, v2 ıy v4 se observa como mejoran de 5 a 6 consultas simples, en promedio, con respecto aRDF-3X; donde el optimizador v4 es el menos dr´ stico ya que en el peor de los casos aobtiene tiempos 4 veces m´ s altos que RDF-3x, a diferencia de v1 y v2 que pueden llegar aa obtener tiempos con 2 o 3 ordenes de magnitud mayor que RDF-3X. ´6.6.2. Experimentos sobre YAGO En el primer experimento sobre YAGO se busca la comparacion de los tiempos de ´evaluacion obtenidos en cold cache de cada una de las versiones del optimizador contra ´RDF-3X, cada una con su respectivo an´ lisis de resultados. a Se observan los resultados de la Tabla 6.2 y la gr´ fica de las consultas q03, q06 y q09 aen la Figura 6.2. V´ ase el Ap´ ndice G para el resto de las gr´ ficas. e e a q01 q02 q03 q04 q05 q06 q07 q08 q09 RDF-3X 62s 84.9s 100657.33s 85.95s 61.2s 188909.7s 0.15s 1.47s 827.8s Opt. v1 2.63s 3.3s 442.54s 56.79s 3.19s 1227s 2.83s 1433s 139.07s Opt. v2 3.23s 3.2s 80.2s 4.3s 2.35s 65.5s 2.6s 2.71s 3.73s Opt. v3 2.89s 6.08s 57.21s 2.7s 570s 135.09s 0.5s 3.04s 68s Opt. v4 2.9s 4.01s 58.87s 2.8s 4.3s 55.12s 2.6s 3.72s 79.3sTabla 6.2: Ejecucion en cold cache de RDF-3X y las 4 versiones del optimizador en YAGO ´
  • ´ ´CAPITULO 6. EXPERIMENTACION 45 Figura 6.2: Tiempo de ejecucion de consultas complejas en YAGO ´ Observando las consultas complejas q03, q06 y q09 se nota como todos los optimiza-dores implementados se comportan mejor en este tipo de consultas que RDF-3X, llegandoa disminuir los tiempos de ejecucion hasta en 2 ordenes de magnitud. ´ ´ Tomando los tiempos de las consultas simples, se observa como cada optimizadorobtienen mayores tiempos que RDF-3X en 2 o 3 consultas de 6, esto debido a que sonalgoritmos aleatorios que pueden ser buenos para resolver problemas complejos pero notanto para problemas m´ s sencillos. Los optimizadores v1, v2 y v3 obtienen tiempos que ason mayores a los de RDF-3X hasta en casi 3 ordenes de magnitud. Mientras que para los ´casos en que los tiempos obtenidos por el optimizador v4 son mayores que los obtenidospor RDF-3X, ocurre que son a lo sumo 5 veces mayor.6.7. Experimento II - Warm Cache El objetivo de este experimento es analizar el comportamiento de las distintas versio-nes de COneQL y RDF-3X ejecutadas en warm cache. Se realizaron experimentos sobre
  • ´ ´CAPITULO 6. EXPERIMENTACION 46LinkedCT y YAGO.6.7.1. Experimentos sobre LinkedCT En el segundo experimento sobre LinkedCT se busca la comparacion de los tiempos de ´evaluacion obtenidos en warm cache de cada una de las versiones del optimizador contra ´RDF-3X, cada una con su respectivo an´ lisis de resultados. a En la Tabla 6.3 se muestran los resultados de los experimentos, y en la Figura 6.3 lagr´ fica con las consultas q04 y q07. V´ ase el Ap´ ndice G para el resto de las gr´ ficas. a e e a q01 q02 q03 q04 q05 q06 q07 q08 q09 q10 RDF-3X 2.44s 2.28s 2.41s 1380s 2.71s 1.75s 1321.1s 1.74s 1.73s 0.14s Opt. v1 0.3s 0.2s 0.15s 40.7s 890.4s 0.7s 2.6s 21.63s 0.7s 0.82s Opt. v2 0.7s 0.74s 0.6s 24.98s 1.62s 307.7s 0.413s 0.73s 0.741s 883.06s Opt. v3 20s 3s 22.4s 483s 93.64s 87.9s 361.7s 138.6s 184.6s 90.7s Opt. v4 0.6s 0.26s 2s 0.2s 6.3s 0.26s 0.2s 1.5s 1.08 0.6sTabla 6.3: Ejecucion en warm cache de RDF-3X y las 4 versiones del optimizador en Lin- ´kedCT Para las consultas complejas q04 y q07 nuestros optimizadores siguen obteniendomenores tiempos que RDF-3X. El optimizador v3 debido a la formacion determin´stica de ´ ılos grupos estrellas obtiene tiempos muy parecidos a los obtenidos en cold cache; siendo lostiempos de v3 hasta 3 veces menor que los de RDF-3X. El resto de los optimizadores siguemanteniendo el mismo comportamiento, donde supera a RDF-3X por diferentes ordenes ´de magnitud. Al observar las consultas simples de LinkedCT, el optimizador v3 sigue sin podercompetir contra RDF-3X por sus limitaciones sobre la generacion de planes iniciales. Se ´observa como el optimizador v1 en la consulta q05 y el optimizador v2 en las consultasq06 y q10, obtienen altos tiempos debido a la caracter´stica de ser algoritmos aleatorios, ımientras que RDF-3X al poder explotar las estructuras obtiene bajos tiempos. El optimi-zador v4 obtiene tiempos por debajo a los de RDF-3X, exceptuando q05 y q10 donde v4
  • ´ ´CAPITULO 6. EXPERIMENTACION 47 Figura 6.3: Tiempo de ejecucion de consultas complejas en LinkedCT ´genera planes con tiempos de ejecucion, a lo sumo, 4 veces mayor que RDF-3X. ´6.7.2. Experimentos sobre YAGO En el segundo experimento sobre YAGO se busca la comparacion de los tiempos de ´evaluacion obtenidos en warm cache de cada una de las versiones del optimizador contra ´RDF-3X, cada una con su respectivo an´ lisis de resultados. a A continuacion se muestran los resultados del experimento en la Tabla 6.4 y seguida- ´mente se muestra la gr´ fica con las consultas complejas en la Figura 6.4. V´ ase el Ap´ ndice a e eG para el resto de las gr´ ficas. a
  • ´ ´CAPITULO 6. EXPERIMENTACION 48 q01 q02 q03 q04 q05 q06 q07 q08 q09 RDF-3X 58.21s 59.54s 72584.71s 58.52s 59.73s 175905s 0.14s 1.46s 808.8s Opt. v1 0.5s 0.6s 430s 58.5s 1.73s 1223.2s 0.8s 1333s 130s Opt. v2 0.5s 0.9s 77.9s 0.8s 0.45s 64s 0.47s 0.5s 1.2s Opt. v3 0.4s 3.3s 58.4s 0.5s 560s 150.28s 0.4s 2.8s 65.75s Opt. v4 0.48s 1.6s 57s 0.85s 2.16s 55.5s 0.5s 1.84s 55.6sTabla 6.4: Ejecucion en warm cache de RDF-3X y las 4 versiones del optimizador en YAGO ´ Figura 6.4: Tiempo de ejecucion de consultas complejas en YAGO ´ Basado en las consultas complejas q03, q06 y q09 se observa como los optimizadorestienen un mejor comportamiento que RDF-3X, donde se pueden llegar a observar hastadiferencias de hasta 4 ordenes de magnitud, como es en el caso de q06 con el optimizador ´v4. El comportamiento de los optimizadores en las consultas simples es bien marcada,en q07 ningun optimizador pudo mejorar los tiempos de RDF-3X, esto puede ser debido ´
  • ´ ´CAPITULO 6. EXPERIMENTACION 49a que la forma de los planes de ejecucion producido por RDF-3X explotan sus ´ndices ´ ıy sus estructuras mucho mejor de lo que lo hacen los planes obtenidos por nuestrosoptimizadores. En muy pocos casos, como en q05 con v3 y en q08 con v1, se observandiferencias muy grandes por las debilidades del optimizador en cada caso. En el resto delas consultas los optimizadores implementados superan a RDF-3X o sino, la diferencia nodoblega el tiempo de RDF-3X.6.8. Experimento III - Efecto de Warm Cache en Tiempos de Optimizacion y Total de Ejecucion ´ ´ El objetivo de este experimento es analizar los tiempos de optimizacion y total de ´ejecucion de las distintas versiones de COneQL y RDF-3X en warm cache. Se realizaron ´experimentos sobre LinkedCT y YAGO. Recordemos que los tiempos totales de ejecucion son la sumatoria de los tiempos de ´optimizacion m´ s los tiempos de ejecucion. ´ a ´6.8.1. Experimento sobre LinkedCT Este ultimo experimento sobre LinkedCT, compara RDF-3X y cada una de las versiones ´del optimizador. Primero se muestran los tiempos de optimizacion en la Tabla 6.5, y luego ´los tiempos de ejecucion en la Tabla 6.6. Los tiempos de optimizacion en RDF-3X se ´ ´tomaron mediante el comando interno EXPLAIN, el cual solo genera el plan de ejecucion ´ ´de la consulta. Ahora se analizar´ n los tiempos de optimizacion de cada implementacion, es decir, a ´ ´cuanto tiempo gasta cada una en generar un plan de ejecucion. V´ ase la Tabla 6.5 y la ´ eFigura 6.5 para la gr´ fica de las consultas complejas de LinkedCT. V´ ase el Ap´ ndice G a e epara el resto de las gr´ ficas. a
  • ´ ´CAPITULO 6. EXPERIMENTACION 50 q01 q02 q03 q04 q05 q06 q07 q08 q09 q10 RDF-3X 0.6s 0.5s 0.5s 0.8s 0.7s 0.7s 0.7s 0.7s 0.6s 0.43s Opt. v1 112s 211.18s 73s 78s 103.7s 113.1s 96.8s 114.4s 114.4s 105s Opt. v2 482.1s 336.8s 317.3s 275.54s 81.05s 433.35s 476s 422s 425.3s 474s Opt. v3 775.2s 7.7s 18s 8s 7.7s 5.7s 6.71s 8.77s 7.49s 7.21s Opt. v4 83.54s 2.4s 2s 1.4s 1.7s 2.52s 2.05s 3s 1.44s 2.09s Tabla 6.5: Tiempos de optimizacion sobre LinkedCT ´ Figura 6.5: Tiempo de optimizacion de consultas complejas en LinkedCT ´ Luego de analizar los resultados obtenidos en los tiempos de optimizacion se observa ´que los optimizadores no obtienen mejores tiempo que los de RDF-3X. Sin embargo, ladiferencia que existe entre los tiempos de optimizacion de RDF-3X y el optimizador v3 ´no son mayores a un orden de magnitud. Por otra parte los tiempos obtenidos por v4son mayores por 4 o 5 veces comparado con los de RDF-3X, esto por consecuencia deque v4 posee su propia estructura cach´ . Notese que los tiempos del optimizador v2 son e ´los peores puede ser debido a las t´ cnicas aplicadas para conseguir mayor porcentaje de e
  • ´ ´CAPITULO 6. EXPERIMENTACION 51aplicacion en las reglas de transformacion. ´ ´ q01 q02 q03 q04 q05 q06 q07 q08 q09 q10 RDF-3X 3.04s 2.78s 2.91s 1385.9s 3.41s 2.45s 1321.8s 2.44s 2.33s 0.57s Opt. v1 133.3s 211.38s 73.15s 118.7s 994.1s 114s 99.4s 136.03s 115.1s 105.82s Opt. v2 482.8s 337s 317.9s 300.5s 82.67s 741.05s 476.413s 422.73s 426.04s 1357.06s Opt. v3 315.2s 10.7s 40.4s 491s 101.34s 93.6s 368.41s 147.37s 192.09s 97.91s Opt. v4 84.14s 2.66s 4s 1.6s 8s 2.78s 2.25 4.5s 2.52s 2.69s Tabla 6.6: Suma de tiempos de optimizacion y ejecucion en LinkedCT ´ ´ Figura 6.6: Tiempo de ejecucion total de consultas complejas en LinkedCT ´ Luego de haber observado el tiempo usado por cada implementacion en cada proceso ´se proceder´ a analizar la suma de ambos, mostrados en la Tabla 6.6 y graficados en la aFigura 6.6. V´ ase el Ap´ ndice G para el resto de las gr´ ficas. e e a Se observa que el optimizador v4 es el unico de los optimizadores implementados que ´logra tiempos competibles en todas las consultas comparados con los de RDF-3X. Analizando las consultas complejas q04 y q07, incluyendo los tiempos de optimizacion, ´
  • ´ ´CAPITULO 6. EXPERIMENTACION 52todos los optimizadores implementados superan a RDF-3X, siendo el optimizador v4 elque obtiene la mayor diferencia, que llega a ser de 3 ordenes de maginitud. ´ Mientras que en las consultas simples el mismo optimizador v4 es el unico que obtiene, ´en ciertos casos, menores tiempos de ejecucion que RDF-3X, esto puede ser debido a lo ´explicado anteriormente de que RDF-3X aprovecha mejor las estructutas internas y sus´ndices.ı6.8.2. Experimento sobre YAGO Este experimento compara RDF-3X y cada una de las versiones del optimizador bajolas mismas condiciones, mostrando los tiempos de optimizacion en la Tabla 6.7, y seguida- ´mente los tiempos de ejecucion. Para tomar estos tiempos con RDF-3X, se uso el comando ´ ´EXPLAIN el cual solo genera el plan de ejecucion de la consulta. ´ ´ Se observa en la Tabla 6.7 que los optimizadores v3 y v4 son los que logran obtener losmenores tiempos de optimizacion entre las 4 versiones de COneQL, esto puede ocurrir ´debido a la decision de diseno de formar los grupos estrellas como paso previo a la ´ ˜generacion del plan inicial. Justamente las dos implententaciones que superan en varios ´ordenes de magnitud los tiempos de RDF-3X son aquellas que no cumplen con estacaracter´stica de la generacion previa de los grupos estrellas. Tambi´ n se observa que ı ´ eRDF-3X tiene un comportamiento inusual en las consultas q03, q06 y q09 al obtener altostiempos de optimizacion,esto es debido a la gran cantidad de patrones que poseen estas ´consultas. Tambi´ n podemos observa la graficacion de las consultas q03, q06 y q09 en la e ´Figura 6.7. V´ ase el Ap´ ndice G para el resto de las gr´ ficas. e e a
  • ´ ´CAPITULO 6. EXPERIMENTACION 53 q01 q02 q03 q04 q05 q06 q07 q08 q09 RDF-3X 0.6s 0.2s 1060s 0.2s 2.7s 1061s 0.2s 2.7s 835.5s Opt. v1 806s 403s 614s 335s 454s 740s 244s 539s 900s Opt. v2 1673s 2052s 2653s 1189s 1768s 2058s 1413s 1917s 2883s Opt. v3 380s 70s 92s 90s 93s 88s 56.3s 75s 85s Opt. v4 475s 38s 17.5s 12.6s 13.15s 8.3s 10.6s 9.14s 9.5s Tabla 6.7: Tiempos de optimizacion sobre YAGO ´ Figura 6.7: Tiempo de optimizacion de consultas complejas en YAGO ´ Ahora se observar´ la Tabla 6.8, el cual representa la suma entre los tiempos de optimi- azacion m´ s los tiempos de ejecucion y la grafica sobre estos datos en la Figura 6.8. V´ ase ´ a ´ ´ eel Ap´ ndice G para el resto de las gr´ ficas. e a
  • ´ ´CAPITULO 6. EXPERIMENTACION 54 q01 q02 q03 q04 q05 q06 q07 q08 q09 RDF-3X 58.81s 59.74s 73644.71s 58.72s 62.43s 176966s 0.34s 4.16s 1584.3s Opt. v1 806.5s 403.6s 1044s 393.5s 464.73s 1963.2s 244.8s 1872s 1030s Opt. v2 1673.3s 2052.9s 3083s 1247.5s 1769.73s 2062s 1413.47s 1917.5s 2884.2s Opt. v3 380.4s 73.3s 90.4s 90.5s 650s 238.28s 56.7s 77.8s 150.75s Opt. v4 475.48s 39.6s 74.5s 13.45s 15.31s 63.8s 11.1s 10.98s 65.1s Tabla 6.8: Suma de tiempos de optimizacion y ejecucion en YAGO ´ ´ Figura 6.8: Tiempo de ejecucion total de consultas complejas en YAGO ´ Para las consultas complejas q03, q06 y q09 los tiempos de nuestros optimizadoresson menores a los de RDF-3X en varios ordenes de magnitud. En las consultas simples, ´al momento de sumar los tiempos de ejecucion y de optimizacion solo el optimizador v4 ´ ´ ´logra superar, consulta por consulta, a RDF-3X en los tiempos de totales de ejecucion. Esto ´gracias a la combinacion de t´ cnicas del optimizador v4 en generar las estrellas previas a ´ ela generacion de planes iniciales, sumado con el uso de su propia estructura cach´ . ´ e En el caso de las consultas simples se observa como el optimizador v4 puede llegar a
  • ´ ´CAPITULO 6. EXPERIMENTACION 55obtener mejores tiempos que los de RDF-3X. Los otros optimizadores no logran competircontra RDF-3X debido a los altos costos de optimizacion y las debilidades de diseno. ´ ˜6.9. An´ lisis de Resultados a A continuacion se muestran las conclusiones que se toman despu´ s observar el com- ´ eportamiento de los 4 optimizadores implementados y de RDF-3X. RDF-3X tiene un buen comportamiento con consultas simples, pero no as´ con las ı consultas complejas. Todos los optimizadores implementados se comportan mejor, en casi todos los casos, en las consultas complejas a RDF-3X. COneQL v4 se comporta mejor que RDF-3X en todas las consultas complejas. COneQL v4 tambi´ n genera planes de ejecucion con menor tiempo de respuesta a e ´ los tiempos totales de ejecucion en las consultas simples de RDF-3X. ´ ´ e ¯ COneQL v4 mantiene un comportamiento bueno, segun nuestra m´ trica t para consultas de diferentes complejidades.6.10. Ventajas y Desventajas de los Optimizadores A trav´ s del estudio experimental se observo las siguientes ventajas y desventajas de e ´las diferentes versiones de COneQL.6.10.1. COneQL version 1 ´Ventajas: Como el diseno de la estructura es simple, la implementacion de los algoritmos ˜ ´ de manipulacion es sencilla. Dado que la generacion del diccionario es simple ya ´ ´ que se incluyen todos los nodos, sin aplicar ningun filtro. ´Desventajas: Al almacenar poca informacion del plan podr´an no generarse los mejores ´ ı planes de ejecucion. Hay poco porcentaje de efectividad en la aplicacion de las reglas ´ ´
  • ´ ´CAPITULO 6. EXPERIMENTACION 56 de transformacion. Algunas veces produce producto cartesiano. ´6.10.2. COneQL version 2 ´Ventajas: Se aumento la eficacia del optimizador (aplicacion de reglas de transformacion). ´ ´ ´Desventajas: Al realizar m´ s intentos sobre una regla de transformacion y a la constante a ´ verificacion en la generacion del diccionario de nodos, los tiempos de optimizacion ´ ´ ´ aumentan. Algunas veces puede producir productos cartesianos.6.10.3. COneQL version 3 ´Ventajas: El nuevo diseno de la generacion de planes iniciales trae como consecuencia ˜ ´ planes de cualquier forma, es decir, tipo arbustos. La nueva informacion en las ´ estructuras, acelera las verificaciones y aplicaciones de las reglas. Con el diseno de ˜ las estrellas determin´sticamente, se reducen las operaciones sobre disco. ıDesventajas: El espacio ocupado por las estructuras aumenta debido a la informacion ´ agregada. Debido a la nueva generacion de estrellas determin´sticas se recorre un ´ ı menor espacio de planes. Los algoritmos de manipulacion aumenta en complejidad. ´6.10.4. COneQL version 4 ´Ventajas: Se disminuyen los tiempos en warm cache.3 Debido a la nueva forma de agrupar los grupos estrellas, se generan menos resultados intermedios. Al eliminarse el determinismo en la seleccion de la tripleta pivote para la generacion de los grupos ´ ´ estrellas, se explora un mayor espacio de planes de ejecucion. ´Desventajas: Altos tiempos de ejecucion del optimizador en cold cache4 ya que la estruc- ´ tura cach´ no est´ inicializada. e a 3 Estado en el cual ya existe informacion de la base de datos en memoria cach´ ´ e 4 Estado en el cual no existe informacion de la base de datos en memoria cach´ , por lo tanto se debe ´ ebuscar en disco
  • Cap´tulo 7 ı Conclusiones En el presente trabajo se logro disenar e implementar cuatro versiones del optimizador ´ ˜COneQL para consultas en SPARQL capaz de producir planes de ejecucion eficientes para ´las fuentes de datos YAGO y LinkedCT. Para la implementacion realizada se hizo un estudio de los elementos necesarios para ´el desarrollo de un optimizador, en este caso particular, un optimizador de consultas enSPARQL. Algunos conceptos provienen de la Web Sem´ ntica, ambiente en donde se desen- avuelve el optimizador. Otros son los distintos elementos que componen un optimizador,incluyendo la t´ cnica de optimizacion y el modelo de costos. Tambi´ n se tienen conceptos e ´ emanejados por la m´ quina de ejecucion, tales como los tipos de planes de ejecucion, los a ´ ´operadores f´sicos utilizados y la definicion de un grupo estrella. Por ultimo, de trabajos ı ´ ´relacionados, como RDF-3X y OneQL, se tomaron algunas ideas para la implementacion. ´Se desarrollo un Parser con la capacidad de manejar consultas en SPARQL, junto con una ´adaptacion del modelo de costos presentado en [28] para que se aproveche funciones ´provistas por BerkeleyDB y se opere con el algoritmo de Muestreo Adaptativo disenado ˜e implementado en este trabajo. Durante el proceso de implementacion del optimizador ´se desarrollaron cuatro versiones distintas, cada una pensada en diferentes situaciones,por lo que fue necesario adaptar la implementacion del algoritmo Simulated Annealing, ´presentado en [11], y las reglas de transformacion. ´ Las cuatro versiones se pueden dividir en dos grandes implementaciones, una para lasdos primeras versiones que tienen el mismo diagrama de clases y cuya unica distincion ´ ´es el diccionario de nodos modificado en la segunda version, y una para las dos ultimas ´ ´versiones, en donde la gran diferencia es la formacion de los grupos estrellas y la estructura ´que se agrego a la cuarta version para realizar un mejor manejo del cach´ . ´ ´ e Despu´ s de las pruebas realizadas con las distintas versiones sobre las fuentes de e 57
  • ´CAPITULO 7. CONCLUSIONES 58datos YAGO y LinkedCT, y comparar los resultados obtenidos con el manejador RDF-3X,se obtuvieron resultados satisfactorios en la construccion de planes correctos, tiempos de ´ejecucion y de optimizacion. ´ ´ Las conclusiones espec´ficas obtenidas tras la realizacion de este trabajo son las si- ı ´guientes: 1. La optimizacion de consultas en SPARQL haciendo uso de un algoritmo aleatorio ´ permite escalar a consultas complejas. Sin embargo, tambi´ n ocasiona un aumento e en el tiempo de optimizacion. ´ 2. Los grupos estrellas colaboran con la disminucion de resultados intermedios. ´ 3. La generacion de planes iniciales gu´ada hacia la formacion de grupos estrellas ´ ı ´ produce planes de ejecucion m´ s eficientes. ´ a 4. Los planes arbustos, al ser resultado de la busqueda en un mayor universo de ´ planes, logran un mejor desempeno que los planes lineales izquierdos en consultas ˜ complejas.7.0.5. Aportes Realizados Se logro implementar y desarrollar una adaptacion de la t´ cnica de Muestreo Adap- ´ ´ e tativo m´ s eficiente, y cuyas estimaciones son lo suficientemente acertadas como a para generar planes de ejecucion eficientes. ´ Con el optimizador v4, se consiguio desarrollar un optimizador que utiliza un al- ´ goritmo aleatorio y logra producir tiempos de optimizacion que compiten con los ´ tiempos de RDF-3X que utiliza un algoritmo greedy. Se comprobo emp´ricamente que los planes de ejecucion obtenidos por el optimi- ´ ı ´ zador desarrollado compiten, y hasta en algunos casos mejoran, los tiempos de RDF-3X.
  • ´CAPITULO 7. CONCLUSIONES 597.0.6. Direcciones Futuras Mejorar el modelo de costos tradicional utilizado para que trabaje directamente con las estructuras implementadas. Estudiar qu´ cambios son necesarios para que el optimizador siga produciendo e planes eficientes para consultas con poca cantidad de patrones, en un tiempo menor. Idear una forma en que la estructura cach´ mantenga la informacion obtenida du- e ´ rante la ejecucion de una instancia del optimizador para ejecuciones futuras. ´ Hacer uso de la sem´ ntica de predicados como rdfs:seeAlso, owl:sameAs, o foaf:page, a para identificar planes contra diferentes fuentes de datos enlazadas. Usar una red Bayesiana para estimar la probabilidad condicional de que una tripleta satisfaga la condicion de join de una consulta. ´
  • Bibliograf´a ı [1] G. Klyne and J. J. Carroll, “Resource Description Framework (RDF): Concepts and Abstract Syntax.” W3C Recommendation, 2004. [2] D. Allemang and J. Hendler, Semantic Web for the Working Ontologist: Effective Modeling in RDFS and OWL. San Francisco, CA, USA: Morgan Kaufmann Publishers Inc., 2008. [3] T. Neumann and G. Weikum, “RDF-3X: a RISC-style engine for RDF,” PVLDB, vol. 1, no. 1, pp. 647–659, 2008. [4] T. Lampo, E. Ruckhaus, J. Sierra, M.-E. Vidal, and A. Martinez, “OneQL: An Ontology- based Architecture to Efficiently Query Resources on the Semantic Web,” in The 5th International Workshop on Scalable Semantic Web Knowledge Base Systems at ISWC, 2009. [5] “Jena TDB.” http://jena.hpl.hp.com/wiki/TDB, 2009. [6] M. K. Nguyen, C. Basca, and A. Bernstein, “B+Hash Tress: Optimizing query execu- tion times for on-disk semantic web data structures,” in The 6th International Workshop on Scalable Semantic Web Knowledge Base Systems at ISWC, 2010. [7] T. Berners-Lee, J. Hendler, and O. Lassila, “The Semantic Web,” Scientific American, vol. 284, no. 5, pp. 34–43, 2001. [8] T. Berners-Lee, R. T. Fielding, and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005. [9] T. Heath and C. Bizer, Linked Data: Evolving the Web into a Global Data Space. Morgan & Claypool, 1st ed., 2011.[10] E. Prud’hommeaux and A. Seaborne, “SPARQL query language for RDF, W3C re- commendation.” http://www.w3.org/TR/rdf-sparql-query/, Jan. 2008.[11] M.-E. Vidal, E. Ruckhaus, T. Lampo, A. Martinez, J. Sierra, and A. Polleres, “Efficiently Joining Group Patterns in SPARQL Queries,” in Proceedings of the 7th Extended Semantic Web Conference (ESWC2010), 2010.[12] R. Lipton and J. Naughton, “Query Size estimation by adaptive sampling (extended abstract),” in Proceedings of SIGMOD, 1990.[13] J. Broekstra, A. Kampman, and F. Harmelen, “Sesame: An Architecture for Storing and Querying RDF Data and Schema Information,” in Spinning the Semantic Web, pp. 197–222, 2003.[14] “AllegroGraph.” http://www.franz.com/agraph/allegrograph/, 2009. 60
  • 61[15] G. Fletcher and P. Beck, “Scalable Indexing of RDF Graph for Efficient Join Proces- sing,” in CIKM, 2009.[16] J. McGlothlin, “RDFVector: An Efficient and Scalable Schema for Semantic Web Knowledge Bases,” in Proceedings of the PhD Symposium ESWC, 2010.[17] D. J. Abadi, A. Marcus, S. Madden, and K. Hollenbach, “SW-Store: a vertically parti- tioned DBMS for Semantic Web data management,” VLDB J., vol. 18, no. 2, pp. 385– 406, 2009.[18] D. J. Abadi, A. Marcus, S. Madden, and K. J. Hollenbach, “Scalable Semantic Web Data Management Using Vertical Partitioning,” in VLDB, pp. 411–422, 2007.[19] M. Atre, V. Chaoji, M. J. Zaki, and J. A. Hendler, “Matrix ”Bit”loaded: a scalable lightweight join query processor for RDF data,” in Proceedings of the WWW, pp. 41– 50, 2010.[20] A. Harth, J. Umbrich, A. Hogan, and S. Decker, “YARS2: A Federated Repository for Querying Graph Structured Data from the Web,” in ISWC/ASWC, pp. 211–224, 2007.[21] Y. Li and J. Heflin, “Using reformulation trees to optimize queries over distributed heterogeneous sources,” in International Semantic Web Conference (ISWC), 2010.[22] T. Urhan and M. J. Franklin, “Xjoin: A reactively-scheduled pipelined join operator,” IEEE Data Eng. Bull., vol. 23, no. 2, pp. 27–33, 2000.[23] T. Urhan, M. J. Franklin, and L. Amsaleg, “Cost based query scrambling for initial delays,” in SIGMOD Conference, pp. 130–141, 1998.[24] C. Weiss and A. Bernstein, “On-disk storage techniques for Semantic Web data- Are B-Trees always the optimal solution?,” in The 5th International Workshop on Scalable Semantic Web Knowledge Base Systems at ISWC, 2009.[25] J. J. Carroll, I. Dickinson, C. Dollin, D. Reynolds, A. Seaborne, and K. Wilkinson, “Jena: Implementing the semantic web recommendations,” in Proc. of the 13th Int. WWW Conf. on Alternate Track Papers & Posters, (USA), pp. 74–83, 2004.[26] M.-E. Vidal, A. Mart´nez, E. Ruckhaus, . T. Lampo, and J. Sierra, Graph Data Manage- ı ment: Techniques and Applications, ch. On the Efficiency of Querying and Storing RDF Documents. IGI BOOK- To appear 2012, 2012.[27] T. B¨ ck, Evolutionary algorithms in theory and practice: evolution strategies, evolutionary a programming, genetic algorithms. Oxford, UK: Oxford University Press, 1996.[28] I. M. Acosta, “Proyecto de ci7311: Bases de datos heterogeneas. 2010.” http://www.ldc.usb.ve/ macosta/ci6318/modelocostos.tar.gz, 2010.
  • 62[29] T. Berners-Lee, “Long Live the Web: A Call for Continued Open Standards and Neutrality,” Scientific American, Nov. 2010.[30] J. Hendler, “Agents and the semantic web,” IEEE Intelligent Systems, vol. 16, pp. 30–37, 2001.[31] “The JenaOntology Api.” http://jena.sourceforge.net/ontology/index.html, 2009.[32] C. Weiss, P. Karras, and A. Bernstein, “Hexastore: sextuple indexing for semantic web data management,” PVLDB, vol. 1, no. 1, pp. 1008–1019, 2008.
  • Ap´ ndice A e Detalle del Marco Teorico ´A.1. Web Sem´ ntica a La Web Sem´ ntica adapta ciertos principios de la WWW, como la universalidad y la adescentralizacion, los cuales se explicar´ n a continuacion. ´ a ´ Gracias a la universalidad es posible publicar e interrelacionar cualquier informa- cion sin importar su ambito, calidad o relevancia; y deber´a ser accesible desde ´ ´ ı cualquier hardware que tenga la opcion de conectarse a Internet. Esta caracter´stica ´ ı ha permitido que la Web genere tanta, o m´ s informacion, que la mayor´a de los a ´ ı medios de comunicacion ha logrado hasta hoy en d´a. [29] ´ ı La descentralizacion se basa en el derecho de poder publicar un contenido sin la ´ necesidad de pasar por la aprobacion de alguna autoridad, solo con cumplir ciertos ´ ´ est´ ndares como escribir la p´ gina en formato HTML, identificarlo con un URI y a a distribuirlo bajo el protocolo HTTP es suficiente. Esto ha tra´do como consecuencia ı que se pierda cierta consistencia utopica de toda la informacion publicada, pero ha ´ ´ permitido un crecimiento exponencial de conocimientos. [29] En la Figura A.1 podemos ver como la Web Sem´ ntica est´ formada por diferentes a acomponentes. Conceptos b´ sicos como los URIs pasando por lenguajes de etiquetas como aXML, y vemos como estos se relacionan con vocabularios ontologicos mediante el formato ´ ´de modelacion de datos RDF, todo este subconjunto de conceptos son los que se tratar´ n ´ aa fondo en este trabajo. El resto de los conceptos importantes como las capas de logica, ´reglas, pruebas, etc., est´ n fuera de nuestro universo. a 63
  • ´ ´APENDICE A. DETALLE DEL MARCO TEORICO 64 Figura A.1: Arquitectura de la Web Sem´ ntica [30] aA.1.1. Resource Description Framework (RDF) Las tripletas RDF se pueden clasificar en dos tipos [9]:Tripleta literal: poseen algun literal (como string o un numero) y se usan principalmente ´ ´ para describir las propiedades de un recurso de la Web.Tripleta con enlace: es usada para describir la relacion entre dos recursos de la Web, esta ´ tripleta debe poseer URIs tanto en el sujeto como en el objeto para identificar los recursos que se est´ n identificando. Los enlaces creados pueden ser internos a un a dataset o pueden ser externos, cuando los enlaces del sujeto y del objeto se encuentran en dos fuentes de datos diferentes.A.1.2. SPARQL Una consulta en SPARQL est´ conformada por los siguientes elementos: aLista de prefijos: constituido por los URI’s de las diferentes fuentes de datos que partici- pan en la consulta.Cl´ usula SELECT: proyecta los valores de las variables listadas en la cl´ usula. a aCl´ usula FROM: esta cl´ usula se usa para nombrar las fuentes de datos cuando no se a a especifican los prefijos en la cabecera de la consulta.
  • ´ ´APENDICE A. DETALLE DEL MARCO TEORICO 65Cl´ usula WHERE: an´ logo al formato SQL, pero las expresiones booleanas est´ n basadas a a a en operaciones sobre tripletas.A.1.3. Nube Enlazada de Datos (Linked Data) El crecimiento de la Nube Enlazada de Datos desde el momento de su creacion en ´Mayo del 2007, se puede observar en la Figura A.2. En la Figura cada nodo representauna fuente de datos publicada bajo los lineamientos del W3C, mientras que los arcosrepresentan enlances entre diferentes recursos entre dos fuentes de datos. El tamano de ˜los nodos y el grosor de los arcos indican mayor poblacion en el diagrama. Se observa ´como la inclusion de nuevas nodos al diagrama ha crecido hasta llegar a la Figura A.3 ´donde podemos ver La Nube Enlazada de Datos en Noviembre de 2010 con 203 fuentes,en la cual adem´ s estas se agrupan segun el ambito a la cual ese vocabulario corresponde. a ´ ´ ´
  • ´ ´APENDICE A. DETALLE DEL MARCO TEORICO 66 Figura A.2: Crecimiento de La Nube de Datos Enlazados [9]
  • ´ ´APENDICE A. DETALLE DEL MARCO TEORICO 67 Figura A.3: Nube de Datos Enlazados (actualmente) [9]
  • Ap´ ndice B e Reglas de Transformacion ´ Lista de reglas de transformacion a aplicar sobre planes de ejecucion de consultas en ´ ´SPARQL. 1. Simetr´a: ı n join n join R1 R2 ≡ R2 R1 g join g join R1 R2 ≡ R2 R1 2. Asociatividad n join n join n join n join (R1 R2 ) R3 ≡ R1 (R2 ) R3 ) g join g join g join g join (R1 R2 ) R3 ≡ R1 (R2 ) R3 ) 3. Distributividad n join n join n join g join n join (R1 R2 ) R3 ≡ (R1 R3 ) (R2 R3 ) 4. Agrupacion ´ n join n join n join n join g join n join (R1 R2 ) (R3 R4 ) ≡ (R1 R2 ) (R3 R4 ) 5. Seleccionar Grupo Estrella n join n join P1 P2 ⇒ (P1 P2 ) 6. Desplegar Grupo Estrella n join n join (P1 P2 ) ⇒ P1 P2 68
  • Ap´ ndice C e Otros Trabajos RelacionadosC.1. Arquitectura de OneQL A continuacion se muestra el diagrama de OneQL introducido en [4]. ´ Figura C.1: Arquitectura del sistema OneQLC.2. Otros Manejadores de Documentos RDF Jena [31] es un framework para Java que provee distintos API’s para lograr extraerinformacion y escribir RDF y RDFS. Para lograr manejar consultas en SPARQL tiene el ´motor de consultas ARQ (A SPARQL Processor for Jena) y sus ´ndices, para as´ lograr un ı ıacceso eficiente a grandes conjuntos de datos. TDB (Tuple Database) [5] es una capa que trabaja sobre Jena y permite el almacena- 69
  • ´APENDICE C. OTROS TRABAJOS RELACIONADOS 70miento de grafos en estructuras de memoria secundaria; es utilizada en conjunto con ARQpara agregar un numero de extensiones para trabajar con consultas de SPARQL. ´ Hexastore [32] es una t´ cnica de indizacion en memoria principal que usa seis ´ndices e ´ ıpara las tripletas RDF. Hexastore mantiene estos ´ndices para recuperar eficientemente ıdatos para cada combinacion entre patrones. El problema de estas estructuras es que ´pueden consumir una gran cantidad de espacio en memoria, adem´ s de que puede haber aredundancia entre los diferentes ´ndices con respecto a un recurso dependiendo del papel ıque ocupa en la tripleta.
  • Ap´ ndice D e Complejidad del Problema Se muestra el an´ lisis de la formula para estimar el tamano del universo de planes de a ´ ˜ejecucion para una consulta de SPARQL. La formula simplifacada es: ´ ´ 2(n−1) S= n−1 × (n − 1)! × 2(n−1) ´ Este es un c´ lculo importante ya que para los ordenes de magnitud que se trabaja en a ´la Nube Enlazada de Datos no se pueden realizar busquedas exhaustivas de soluciones, y ´es por eso que se deben definir estrategias de busqueda que permitan recorrer el espacio ´de manera eficiente y eficaz. Basado en [26] se propone la siguiente formula con sus explicaciones sobre lo que ´mide cada parte. 2(n−1) n−1 S= × n! × 2(n−1) n N o ordenamientos N o operadores N o parentizaciones 71
  • Ap´ ndice E e Algoritmos ImplementadosE.1. Simulated Annealing Pseudocodigo del algoritmo de Simulated Annealing. ´Entrada: Plan de ejecucion ´Salida: Plan de ejecucion optimizado ´ 1: temperatura ← T 2: cant escenarios ← CE 3: i=1 4: while i ≤ tempteratura do 5: j=1 6: Se genera un plan aleatorio P 7: while j ≤ cant escenarios do 8: Se elige aleatoriamente segun una probabilidad k una regla de transformacion r ´ ´ 9: P = la aplicacion de r a un nodo n del plan P ´10: if costo(P ) < costo(P) then11: P←P12: end if13: j← j+114: end while15: i←i+116: end whileE.2. Muestreo Adaptativo Pseudocodigo del algoritmos de Muestreo Adaptativo. ´Entrada: Subconsulta que se desea estimar 72
  • ´APENDICE E. ALGORITMOS IMPLEMENTADOS 73Salida: Costo y Cardinalidad de la subconsulta 1: i←1 2: T ←Tripleta pivote del grupo estrella 3: N ←Tamano de la poblacion de T ˜ 4: while i ≤ N do 5: Se extrae una instancia I de T y se almacena en mapa 6: end while 7: 8: i←1 9: {Para el 2 % de la poblacion total} ´10: while i ≤ N ∗ 0,02 do11: Se extrae aleatoriamente una instancia I de mapa12: X ←Grupo Estrella sin T con la instancia I en la variable comun del grupo13: Se calcula la cardinalidad c de X14: if card max ≤ c then15: card max ← c16: end if17: end while18:19: suma ← 020: cota ← card max21: while suma ≤ cota do22: Se extrae aleatoriamente una instancia I de mapa23: X ← Grupo Estrella sin T con la instancia I en la variable comun del grupo24: Se calcula la cardinalidad c de X25: suma ← suma + c26: end while
  • Ap´ ndice F e Configuracion de experimentos ´F.1. Especificaciones de las M´ quinas de Pruebas a A continuacion en la Tabla F.1 se muestran las especificaciones de hardware y software ´de las m´ quinas usadas en los experimentos. a Componente Descripcion ´ Procesadores Dos procesadores AMD Opteron de la serie 2000 Cach´ por nucleo e ´ 1 MB Memoria RAM 10 GB Sistema Operativo Linux/CentOS 5.4 de 64 bits Tabla F.1: Especificaciones de las estaciones de experimentacion ´F.2. Descripcion de Bancos de Pruebas (Benchmarks) ´ La definicion de los benchmark no forma parte del alcance de este trabajo, por lo ´que se decidio utilizar el conjunto de pruebas definido en [11]. Dichos bancos de pruebas ´contienen una serie de experimentos que evaluan el rendimiento de los planes de ejecucion ´ ´obtenidos por un optimizador. La idea es utilizar estos como un marco de referencia paracomparar y evaluar el rendimiento de los diferentes optimizadores desarrollados en estetrabajo y RDF-3X. Las caracter´sticas mostradas en la Tabla F.2 son las m´ tricas que se tomaron en con- ı esideracion al momento de definir los bancos de prueba. Las mismas toman en cuenta ´factores tanto de la m´ quina como de las consultas. a 74
  • ´ ´APENDICE F. CONFIGURACION DE EXPERIMENTOS 75 Criterios de Evaluacion ´ Variables Variables Variables Observadas Ocultas Independientes Tiempo Tiempo Tiempo Tamano ˜ Manejo del Optimizacion ´ Optimizacion ´ Ejecucion ´ Carga Memoria Cache de la calidad # patrones X X X instanciaciones X X X Forma de la consulta X X X X Resultados intermedios X X Espec´ficas de la consulta Tamano de ˜ la respuesta X X X Duplicados de la respuesta X # joins X X X X ı Tipo de la consulta (Select/Describe) X Operadores de la consulta (Optional/Filters) X X X Busqueda de texto ´ X X X Dereferenciacion ´ de enlaces X X XTabla F.2: Relacion entre factores de los benchmarks y caracter´sticas de las m´ quinas de ´ ı adocumentos RDF El banco de prueba LinkedCT esta conformado por las consultas presentadas en la ´Tabla F.3. Este est´ compuesto por diez consultas, donde solo q04 y q07 son consideradas a ´consultas complejas. La complejidad de una consulta viene dada por la cantidad depatrones que la conforman y la cantidad de resultados intermedios que se pueden generaren el momento de evaluarla. Particularmente en este benchmark las complejidad viene dadapor la cantidad de resultados intermedios generados. Las consultas en SPARQL se puedenobservar en la seccion F.3.1. ´
  • ´ ´APENDICE F. CONFIGURACION DE EXPERIMENTOS 76 Consulta Nro. Patrones Tamano de ˜ Es Compleja? respuesta(tripletas) q01 13 6 NO q02 13 53 NO q03 13 9 NO q04 17 4 SI q05 17 99 NO q06 17 11 NO q07 17 4 SI q08 17 4 NO q09 17 2 NO q10 16 30 NO Tabla F.3: Benchmark 1 Por otra parte la Tabla F.4 hace referencia a las consultas que conforman el benchmark ´de la fuente de datos YAGO. Esta consiste en nueve consultas, con solo las consultas q03, ´q06 y q09 como complejas. Una de las caracter´sticas m´ s importantes de este banco de ı aprueba es que las consultas poseen una mayor cantidad de patrones, el cual es la otra ´forma de identificar la complejidad de una consulta. Las consultas en SPARQL se puedenobservar en la seccion F.3.2. ´
  • ´ ´APENDICE F. CONFIGURACION DE EXPERIMENTOS 77 Consulta Nro. Patrones Tamano de ˜ Es Compleja? respuesta(tripletas) q01 17 1.170 NO q02 21 4.264 NO q03 26 22.434 SI q04 17 238 NO q05 21 516 NO q06 26 1.348 SI q07 17 342 NO q08 21 1.220 NO q09 26 5.718 SI Tabla F.4: Benchmark 2F.3. Consultas en SPARQL de los bancos de pruebaF.3.1. Consultas del banco de prueba de LinkedCTselect DISTINCT ?fn1 ?fn3 ?fn5 ?I select DISTINCT ?fn1 ?fn3 ?fn5 ?Iwhere { where { ?A2 linkedct:condition name "Colorectal Cancer" . ?A2 linkedct:condition name "Colorectal Cancer" . ?A1 linkedct:intervention ?I . ?A1 linkedct:intervention ?I . ?A1 foaf:page ?fn1 . ?A1 foaf:page ?fn1 . ?A1 linkedct:condition ?A2 . ?A1 linkedct:condition ?A2 . ?A4 linkedct:condition name "Breast Cancer" . ?A4 linkedct:condition name "Breast Cancer" . ?A3 linkedct:intervention ?I . ?A3 linkedct:intervention ?I . ?A3 foaf:page ?fn3 . ?A3 foaf:page ?fn3 . ?A3 linkedct:condition ?A4 . ?A3 linkedct:condition ?A4 . ?A6 linkedct:condition name "Prostate Cancer" . ?A6 linkedct:condition name "Ovarian Cancer" . ?A5 linkedct:intervention ?I . ?A5 linkedct:intervention ?I . ?A5 foaf:page ?fn5 . ?A5 foaf:page ?fn5 . ?A5 linkedct:condition ?A6 . ?A5 linkedct:condition ?A6 . ?I linkedct:intervention type "Drug" . ?I linkedct:intervention type "Drug" .} } Figura F.1: Consulta q01 Figura F.2: Consulta q02
  • ´ ´APENDICE F. CONFIGURACION DE EXPERIMENTOS 78 select DISTINCT ?fn1 ?fn3 ?fn5 ?fn7 ?I where { ?A2 linkedct:condition name "Colorectal Cancer" . ?A1 linkedct:intervention ?I . ?A1 foaf:page ?fn1 .select DISTINCT ?fn1 ?fn3 ?fn5 ?I ?A1 linkedct:condition ?A2 .where { ?A4 linkedct:condition name "Breast Cancer" . ?A2 linkedct:condition name "Colorectal Cancer" . ?A3 linkedct:intervention ?I . ?A1 linkedct:intervention ?I . ?A3 foaf:page ?fn3 . ?A1 foaf:page ?fn1 . ?A3 linkedct:condition ?A4 . ?A1 linkedct:condition ?A2 . ?A6 linkedct:condition name "Ovarian Cancer" . ?A4 linkedct:condition name "Breast Cancer" . ?A5 linkedct:intervention ?I . ?A3 linkedct:intervention ?I . ?A5 foaf:page ?fn5 . ?A3 foaf:page ?fn3 . ?A5 linkedct:condition ?A6 . ?A3 linkedct:condition ?A4 . ?A8 linkedct:condition name "Lung Cancer" . ?A6 linkedct:condition name "Lung Cancer" . ?A7 linkedct:intervention ?I . ?A5 linkedct:intervention ?I . ?A7 foaf:page ?fn7 . ?A5 foaf:page ?fn5 . ?A7 linkedct:condition ?A8 . ?A5 linkedct:condition ?A6 . ?I linkedct:intervention type "Drug" . ?I linkedct:intervention type "Drug" . }} Figura F.3: Consulta q03 Figura F.4: Consulta q04select DISTINCT ?fn1 ?fn3 ?fn5 ?fn7 ?I select DISTINCT ?fn1 ?fn3 ?fn5 ?fn7 ?Iwhere { where { ?A2 linkedct:condition name "Pancreatic Cancer" . ?A2 linkedct:condition name "Pancreatic Cancer". ?A1 linkedct:intervention ?I . ?A1 linkedct:intervention ?I. ?A1 foaf:page ?fn1 . ?A1 foaf:page ?fn1. ?A1 linkedct:condition ?A2 . ?A1 linkedct:condition ?A2. ?A4 linkedct:condition name "Breast Cancer" . ?A4 linkedct:condition name "Breast Cancer". ?A3 linkedct:intervention ?I . ?A3 linkedct:intervention ?I. ?A3 foaf:page ?fn3 . ?A3 foaf:page ?fn3. ?A3 linkedct:condition ?A4 . ?A3 linkedct:condition ?A4. ?A6 linkedct:condition name "Ovarian Cancer" . ?A6 linkedct:condition name "Ovarian Cancer". ?A5 linkedct:intervention ?I . ?A5 linkedct:intervention ?I. ?A5 foaf:page ?fn5 . ?A5 foaf:page ?fn5. ?A5 linkedct:condition ?A6 . ?A5 linkedct:condition ?A6. ?A8 linkedct:condition name "Colorectal Cancer" . ?A8 linkedct:condition name "Lung Cancer". ?A7 linkedct:intervention ?I . ?A7 linkedct:intervention ?I. ?A7 foaf:page ?fn7 . ?A7 foaf:page ?fn7. ?A7 linkedct:condition ?A8 . ?A7 linkedct:condition ?A8. ?I linkedct:intervention type "Drug" . ?I linkedct:intervention type "Drug"} } Figura F.5: Consulta q05 Figura F.6: Consulta q06
  • ´ ´APENDICE F. CONFIGURACION DE EXPERIMENTOS 79select DISTINCT ?fn1 ?fn3 ?fn5 ?fn7 ?Iwhere { select DISTINCT ?fn1 ?fn3 ?fn5 ?fn7 ?I ?A2 linkedct:condition name "Colorectal Cancer". where { ?A1 linkedct:intervention ?I. ?A2 linkedct:condition name "Colorectal Cancer". ?A1 foaf:page ?fn1. ?A1 linkedct:intervention ?I. ?A1 linkedct:condition ?A2. ?A1 foaf:page ?fn1. ?A4 linkedct:condition name "Breast Cancer". ?A1 linkedct:condition ?A2. ?A3 linkedct:intervention ?I. ?A4 linkedct:condition name "Breast Cancer". ?A3 foaf:page ?fn3. ?A3 linkedct:intervention ?I. ?A3 linkedct:condition ?A4. ?A3 foaf:page ?fn3. ?A6 linkedct:condition name "Ovarian Cancer". ?A3 linkedct:condition ?A4. ?A5 linkedct:intervention ?I. ?A6 linkedct:condition name "Pancreatic Cancer". ?A5 foaf:page ?fn5. ?A5 linkedct:intervention ?I. ?A5 linkedct:condition ?A6. ?A5 foaf:page ?fn5. ?A8 linkedct:condition name "Lung Cancer". ?A5 linkedct:condition ?A6. ?A7 linkedct:intervention ?I. ?A8 linkedct:condition name "Lung Cancer". ?A7 foaf:page ?fn7. ?A7 linkedct:intervention ?I. ?A7 linkedct:condition ?A8. ?A7 foaf:page ?fn7. ?I linkedct:intervention type "Drug" ?A7 linkedct:condition ?A8.} ?I linkedct:intervention type "Drug" } Figura F.7: Consulta q07 Figura F.8: Consulta q08select DISTINCT ?fn1 ?fn3 ?fn5 ?fn7 ?Iwhere { select DISTINCT ?fn1 ?fn3 ?fn5 ?fn7 ?C ?A2 linkedct:condition name "Colorectal Cancer". where { ?A1 linkedct:intervention ?I. ?A2 linkedct:intervention name "Simvastatin". ?A1 foaf:page ?fn1. ?A1 linkedct:intervention ?A2. ?A1 linkedct:condition ?A2. ?A1 linkedct:condition ?C. ?A4 linkedct:condition name "Ovarian Cancer". ?A1 foaf:page ?fn1. ?A3 linkedct:intervention ?I. ?A4 linkedct:intervention name "Coenzyme Q10". ?A3 foaf:page ?fn3. ?A3 linkedct:intervention ?A4. ?A3 linkedct:condition ?A4. ?A3 linkedct:condition ?C. ?A6 linkedct:condition name "Pancreatic Cancer". ?A3 foaf:page ?fn3. ?A5 linkedct:intervention ?I. ?A6 linkedct:intervention name "Niacin". ?A5 foaf:page ?fn5. ?A5 linkedct:intervention ?A6. ?A5 linkedct:condition ?A6. ?A5 linkedct:condition ?C. ?A8 linkedct:condition name "Lung Cancer". ?A5 foaf:page ?fn5. ?A7 linkedct:intervention ?I. ?A8 linkedct:intervention name "Aspirin". ?A7 foaf:page ?fn7. ?A7 linkedct:intervention ?A8. ?A7 linkedct:condition ?A8. ?A7 linkedct:condition ?C. ?I linkedct:intervention type "Drug" ?A7 foaf:page ?fn7} } Figura F.9: Consulta q09 Figura F.10: Consulta q10
  • ´ ´APENDICE F. CONFIGURACION DE EXPERIMENTOS 80F.3.2. Consultas del banco de prueba de YAGO select ∗ where { ?A1 yago:hasFamilyName ?fn1 . ?A1 yago:hasGivenName ?ln1 . ?person1 yago:influences ?A1 .select ∗ where { ?A2 yago:hasFamilyName ?fn2 .?A1 yago:hasFamilyName ?fn1. ?A2 yago:hasGivenName ?ln2 .?A1 yago:hasGivenName ?ln1 . ?person1 yago:influences ?A2 .?person1 yago:influences ?A1. ?A1 rdf:type ?type .?A2 yago:hasFamilyName ?fn2 . ?type rdfs:label "artist" .?A2 yago:hasGivenName ?ln2 . ?A2 rdf:type ?type1 .?person1 yago:influences ?A2. ?type1 rdfs:label "artist" .?A1 rdf:type ?type . ?person2 yago:influences ?person1 .?type rdfs:label "artist". ?person2 rdf:type ?type2 .?A2 rdf:type ?type1 . ?type2 rdfs:label "artist".?type1 rdfs:label "artist". ?A3 yago:hasGivenName ?ln3 .?person2 yago:influences ?person1. ?person2 yago:influences ?A3.?person2 rdf:type ?type2. ?A3 rdf:type ?type3 .?type2 rdfs:label "artist". ?type3 rdfs:label "artist".?A3 yago:hasGivenName ?ln3 . ?A4 yago:hasGivenName ?ln4 .?person2 yago:influences ?A3. ?person2 yago:influences ?A4.?A3 rdf:type ?type3 . ?A4 rdf:type ?type4 .?type3 rdfs:label "artist". ?type4 rdfs:label "artist".} } Figura F.11: Consulta q01 Figura F.12: Consulta q02select ∗ where {?A1 yago:hasFamilyName ?fn1.?A1 yago:hasGivenName ?ln1 .?person1 yago:influences ?A1.?A2 yago:hasFamilyName ?fn2 .?A2 yago:hasGivenName ?ln2 .?person1 yago:influences ?A2.?A1 rdf:type ?type .?type rdfs:label "artist".?A2 rdf:type ?type1 . select ∗ where {?type1 rdfs:label "artist". ?A1 yago:hasFamilyName ?fn1.?person2 yago:influences ?person1. ?A1 yago:hasGivenName ?ln1 .?person2 rdf:type ?type2. ?person1 yago:influences ?A1.?type2 rdfs:label "artist". ?A2 yago:hasFamilyName ?fn2 .?A3 yago:hasGivenName ?ln3 . ?A2 yago:hasGivenName ?ln2 .?person2 yago:influences ?A3. ?person1 yago:influences ?A2.?A3 rdf:type ?type3 . ?A1 rdf:type ?type .?type3 rdfs:label "artist". ?type rdfs:label "actor".?A4 yago:hasGivenName ?ln4 . ?A2 rdf:type ?type1 .?person2 yago:influences ?A4. ?type1 rdfs:label "actor".?A4 rdf:type ?type4 . ?person2 yago:influences ?person1.?type4 rdfs:label "artist". ?person2 rdf:type ?type2.?A5 yago:hasGivenName ?ln5 . ?type2 rdfs:label "actor".?person2 yago:influences ?A5. ?A3 yago:hasGivenName ?ln3 .?A5 rdf:type ?type5 . ?person2 yago:influences ?A3.?type5 rdfs:label "artist". ?A3 rdf:type ?type3 .?person2 yago:influences ?person1. ?type3 rdfs:label "actor".} } Figura F.13: Consulta q03 Figura F.14: Consulta q04
  • ´ ´APENDICE F. CONFIGURACION DE EXPERIMENTOS 81 select ∗ where { ?A1 yago:hasFamilyName ?fn1. ?A1 yago:hasGivenName ?ln1 . ?person1 yago:influences ?A1. ?A2 yago:hasFamilyName ?fn2 .select ∗ where { ?A2 yago:hasGivenName ?ln2 .?A1 yago:hasFamilyName ?fn1. ?person1 yago:influences ?A2.?A1 yago:hasGivenName ?ln1 . ?A1 rdf:type ?type .?person1 yago:influences ?A1. ?type rdfs:label "actor".?A2 yago:hasFamilyName ?fn2 . ?A2 rdf:type ?type1 .?A2 yago:hasGivenName ?ln2 . ?type1 rdfs:label "actor".?person1 yago:influences ?A2. ?person2 yago:influences ?person1.?A1 rdf:type ?type . ?person2 rdf:type ?type2.?type rdfs:label "actor". ?type2 rdfs:label "actor".?A2 rdf:type ?type1 . ?A3 yago:hasGivenName ?ln3 .?type1 rdfs:label "actor". ?person2 yago:influences ?A3.?person2 yago:influences ?person1. ?A3 rdf:type ?type3 .?person2 rdf:type ?type2. ?type3 rdfs:label "actor".?type2 rdfs:label "actor". ?A4 yago:hasGivenName ?ln4 .?A3 yago:hasGivenName ?ln3 . ?person2 yago:influences ?A4.?person2 yago:influences ?A3. ?A4 rdf:type ?type4 .?A3 rdf:type ?type3 . ?type4 rdfs:label "actor".?type3 rdfs:label "actor". ?A5 yago:hasGivenName ?ln5 .?A4 yago:hasGivenName ?ln4 . ?person2 yago:influences ?A5.?person2 yago:influences ?A4. ?A5 rdf:type ?type5 .?A4 rdf:type ?type4 . ?type5 rdfs:label "actor".?type4 rdfs:label "actor". ?person2 yago:influences ?person1.} } Figura F.15: Consulta q05 Figura F.16: Consulta q06 select ∗ where { ?A1 yago:hasFamilyName ?fn1. ?A1 yago:hasGivenName ?ln1 . ?person1 yago:influences ?A1.select ∗ where { ?A2 yago:hasFamilyName ?fn2 .?A1 yago:hasFamilyName ?fn1. ?A2 yago:hasGivenName ?ln2 .?A1 yago:hasGivenName ?ln1 . ?person1 yago:influences ?A2.?person1 yago:influences ?A1. ?A1 rdf:type ?type .?A2 yago:hasFamilyName ?fn2 . ?type rdfs:label "scientist".?A2 yago:hasGivenName ?ln2 . ?A2 rdf:type ?type1 .?person1 yago:influences ?A2. ?type1 rdfs:label "scientist".?A1 rdf:type ?type . ?person2 yago:influences ?person1.?type rdfs:label "scientist". ?person2 rdf:type ?type2.?A2 rdf:type ?type1 . ?type2 rdfs:label "scientist".?type1 rdfs:label "scientist". ?A3 yago:hasGivenName ?ln3 .?person2 yago:influences ?person1. ?person2 yago:influences ?A3.?person2 rdf:type ?type2. ?A3 rdf:type ?type3 .?type2 rdfs:label "scientist". ?type3 rdfs:label "scientist".?A3 yago:hasGivenName ?ln3 . ?A4 yago:hasGivenName ?ln4 .?person2 yago:influences ?A3. ?person2 yago:influences ?A4.?A3 rdf:type ?type3 . ?A4 rdf:type ?type4 .?type3 rdfs:label "scientist". ?type4 rdfs:label "scientist".} } Figura F.17: Consulta q07 Figura F.18: Consulta q08
  • ´ ´APENDICE F. CONFIGURACION DE EXPERIMENTOS 82select ∗ where {?A1 yago:hasFamilyName ?fn1.?A1 yago:hasGivenName ?ln1 .?person1 yago:influences ?A1.?A2 yago:hasFamilyName ?fn2 .?A2 yago:hasGivenName ?ln2 .?person1 yago:influences ?A2.?A1 rdf:type ?type .?type rdfs:label "scientist".?A2 rdf:type ?type1 .?type1 rdfs:label "scientist".?person2 yago:influences ?person1.?person2 rdf:type ?type2.?type2 rdfs:label "scientist".?A3 yago:hasGivenName ?ln3 .?person2 yago:influences ?A3.?A3 rdf:type ?type3 .?type3 rdfs:label "scientist".?A4 yago:hasGivenName ?ln4 .?person2 yago:influences ?A4.?A4 rdf:type ?type4 .?type4 rdfs:label "scientist".?A5 yago:hasGivenName ?ln5 .?person2 yago:influences ?A5.?A5 rdf:type ?type5 .?type5 rdfs:label "scientist".?person2 yago:influences ?person1.} Figura F.19: Consulta q09F.4. Configuracion Inicial de Experimentacion ´ ´ En la Tabla F.5 se muestra la configuracion inicial del optimizador para los experimen- ´tos realizados. Estos valores fueron tomados de [11]. Temperatura inicial igual a 50 Escenarios inicial igual a 10 Aumento en 10 % la cantidad de escenarios en cada temperatura Instanciar el 2 % de tripletas en el Muestreo Adaptativo Tabla F.5: Par´ metros Iniciales de Experimentacion a ´ En la Tabla F.6 se muestran los valores de las probabilidades de las reglas de transfor-macion que se usaron en la etapa experimental. Estos valores fueron tomados de [11]. ´
  • ´ ´APENDICE F. CONFIGURACION DE EXPERIMENTOS 83 Regla Probabilidad Simetr´a ı 0.9 Asociatividad 0.9 Distributividad 0.9 Agrupacion ´ 0.9 Seleccionar Grupo Estrella 0.7 Desplegar Grupo Estrella 0.3 Tabla F.6: Probabilidades de las reglas
  • Ap´ ndice G e Graficas de resultados experimentalesG.1. Cold CacheG.1.1. Experimento sobre LinkedCT A continuacion se muestra la Figura G.1 donde se muestran las consultas simples de ´LinkedCT. Figura G.1: Tiempo de ejecucion de consultas simples ´ A continuacion se muestra la Figura G.2 donde se muestran las consultas complejas ´de LinkedCT. 84
  • ´APENDICE G. GRAFICAS DE RESULTADOS EXPERIMENTALES 85 Figura G.2: Tiempo de ejecucion de consultas complejas ´G.1.2. Experimento sobre YAGO A continuacion se muestra la Figura G.3 donde se muestran las consultas simples de ´YAGO. Figura G.3: Tiempo de ejecucion de consultas simples ´
  • ´APENDICE G. GRAFICAS DE RESULTADOS EXPERIMENTALES 86 A continuacion se muestra la Figura G.4 donde se muestran las consultas complejas ´de YAGO. Figura G.4: Tiempo de ejecucion de consultas complejas ´G.2. Warm CacheG.2.1. Experimento sobre LinkedCT A continuacion se muestra la Figura G.5 donde se muestran las consultas simples de ´LinkedCT.
  • ´APENDICE G. GRAFICAS DE RESULTADOS EXPERIMENTALES 87 Figura G.5: Tiempo de ejecucion de consultas simples ´ A continuacion se muestra la Figura G.6 donde se muestran las consultas complejas ´de LinkedCT. Figura G.6: Tiempo de ejecucion de consultas complejas ´
  • ´APENDICE G. GRAFICAS DE RESULTADOS EXPERIMENTALES 88G.2.2. Experimento sobre YAGO A continuacion se muestra la Figura G.7 donde se muestran las consultas simples de ´YAGO. Figura G.7: Tiempo de ejecucion de consultas simples ´ A continuacion se muestra la Figura G.8 donde se muestran las consultas complejas ´de YAGO.
  • ´APENDICE G. GRAFICAS DE RESULTADOS EXPERIMENTALES 89 Figura G.8: Tiempo de ejecucion de consultas complejas ´G.3. Tiempos de Optimizacion y Total de Ejecucion ´ ´G.3.1. Experimento sobre LinkedCT A continuacion se muestra la Figura G.9 donde se muestran los tiempos de optimiza- ´cion para las consultas simples de LinkedCT. ´
  • ´APENDICE G. GRAFICAS DE RESULTADOS EXPERIMENTALES 90 Figura G.9: Tiempo de ejecucion de consultas simples ´ A continuacion se muestra la Figura G.10 donde se muestran los tiempos de optimi- ´zacion para las consultas complejas de LinkedCT. ´ Figura G.10: Tiempo de ejecucion de consultas complejas ´ A continuacion se muestra la Figura G.11 donde se muestran los tiempos de ejecucion ´ ´total para las consultas simples de LinkedCT.
  • ´APENDICE G. GRAFICAS DE RESULTADOS EXPERIMENTALES 91 Figura G.11: Tiempo de ejecucion total de consultas simples ´ A continuacion se muestra la Figura G.12 donde se muestran los tiempos de ejecucion ´ ´total para las consultas complejas de LinkedCT. Figura G.12: Tiempo de ejecucion total de consultas complejas ´
  • ´APENDICE G. GRAFICAS DE RESULTADOS EXPERIMENTALES 92G.3.2. Experimento sobre YAGO A continuacion se muestra la Figura G.13 donde se muestran los tiempos de optimi- ´zacion para las consultas simples de YAGO. ´ Figura G.13: Tiempo de ejecucion de consultas simples ´ A continuacion se muestra la Figura G.14 donde se muestran los tiempos de optimi- ´zacion para las consultas complejas de YAGO. ´
  • ´APENDICE G. GRAFICAS DE RESULTADOS EXPERIMENTALES 93 Figura G.14: Tiempo de ejecucion de consultas complejas ´ A continuacion se muestra la Figura G.15 donde se muestran los tiempos de ejecucion ´ ´total para las consultas simples de YAGO. Figura G.15: Tiempo de ejecucion total de consultas simples ´ A continuacion se muestra la Figura G.16 donde se muestran los tiempos de ejecucion ´ ´
  • ´APENDICE G. GRAFICAS DE RESULTADOS EXPERIMENTALES 94total para las consultas complejas de YAGO. Figura G.16: Tiempo de ejecucion total de consultas complejas ´