UNIVERSIDAD SIMON BOL´                               ´     IVAR                       Ingenier´a de Computacion           ...
Desarrollo de un optimizador de consultas en SPARQL para la Nube                                 Enlazada de Datos.       ...
Agradecimientos   A mi familia, por ser un apoyo incondicional siempre, sin importar las decisiones quetome o en el moment...
A la Profesora Mar´a Esther Vidal por su extraordinaria guiatura acad´ mica, por su                     ı                 ...
´Indice generalAgradecimientos                                                                                iii´Indice g...
3.2. Formalizacion del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20                   ´   3.3. Comp...
6.6.2. Experimentos sobre YAGO . . . . . . . . . . . . . . . . . . . . . . . . 44   6.7. Experimento II - Warm Cache . . ....
C.2. Otros Manejadores de Documentos RDF . . . . . . . . . . . . . . . . . . . . . 69Ap´ ndice D. Complejidad del Problema...
´Indice de tablas 6.1. Tiempos de ejecucion en cold cache en LinkedCT . . . . . . . . . . . . . . . . 43                  ...
´Indice de figuras 2.1. Ejemplo de una tripleta RDF . . . . . . . . . . . . . . . . . . . . . . . . . . . .    5 2.2. Arqui...
6.7. Tiempo de optimizacion de consultas complejas en YAGO . . . . . . . . . . 53                         ´6.8. Tiempo de ...
G.4. Tiempo de ejecucion de consultas complejas . . . . . . . . . . . . . . . . . . . 86                      ´G.5. Tiempo...
Glosario de T´ rminos             e  WWW World Wide Web. Cantidad de documentos interconectados mediante          Internet...
Cap´tulo 1                                     ı                               Introduccion                               ...
´                  ´CAPITULO 1. INTRODUCCION                                                                    2     Estu...
Cap´tulo 2                                          ı                              Marco Teorico                          ...
´                ´CAPITULO 2. MARCO TEORICO                                                                   4   Los URIs...
´                ´CAPITULO 2. MARCO TEORICO                                                                               ...
´                ´CAPITULO 2. MARCO TEORICO                                                                          6En S...
´                ´CAPITULO 2. MARCO TEORICO                                                                72.1.5. Puntos ...
´                ´CAPITULO 2. MARCO TEORICO                                                                8         ´2.2....
´                ´CAPITULO 2. MARCO TEORICO                                                                   9Planes Arbu...
´                ´CAPITULO 2. MARCO TEORICO                                                               10   La propuest...
´                ´CAPITULO 2. MARCO TEORICO                                                               11un modelo de c...
´                ´CAPITULO 2. MARCO TEORICO                                                               12             D...
´                ´CAPITULO 2. MARCO TEORICO                                                                  132.2.2.2. Si...
´                ´CAPITULO 2. MARCO TEORICO                                                                  14quedarse es...
´                ´CAPITULO 2. MARCO TEORICO                                                                15en optimizar ...
´                ´CAPITULO 2. MARCO TEORICO                                                                162.3.2. RDF-3X...
´                ´CAPITULO 2. MARCO TEORICO                                                                 17su delegacio...
Cap´tulo 3                                     ı                     An´ lisis del Problema                       a   En e...
´          ´CAPITULO 3. ANALISIS DEL PROBLEMA                                                                             ...
´          ´CAPITULO 3. ANALISIS DEL PROBLEMA                                                                             ...
´          ´CAPITULO 3. ANALISIS DEL PROBLEMA                                                                             ...
Cap´tulo 4                                      ı                     Diseno de la Solucion                         ˜     ...
´            ˜              ´CAPITULO 4. DISENO DE LA SOLUCION                                                         234...
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
Documentación Proyecto # 62 Premios Eureka 2011 Mención Innovatividad Técnica
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

534
-1

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
534
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

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

  1. 1. UNIVERSIDAD SIMON BOL´ ´ IVAR Ingenier´a de Computacion ı ´Desarrollo de un optimizador de consultas en SPARQL para la Nube Enlazada de Datos. Por Mireya Gonz´ lez, Jos´ Riera a e Proyecto de Grado Presentado ante la Ilustre Universidad Simon Bol´var ´ ı como Requerimiento Parcial para Optar el T´tulo de ı Ingeniero en Computacion ´ Sartenejas, Mayo de 2011
  2. 2. 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
  3. 3. 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
  4. 4. 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
  5. 5. ´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
  6. 6. 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
  7. 7. 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
  8. 8. 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
  9. 9. ´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
  10. 10. ´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
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. ´ ´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. ı
  16. 16. 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
  17. 17. ´ ´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.
  18. 18. ´ ´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. ´
  19. 19. ´ ´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
  20. 20. ´ ´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 ´
  21. 21. ´ ´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).
  22. 22. ´ ´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.
  23. 23. ´ ´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
  24. 24. ´ ´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.
  25. 25. ´ ´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. ı
  26. 26. ´ ´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 ´
  27. 27. ´ ´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 ´
  28. 28. ´ ´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.
  29. 29. ´ ´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 ´
  30. 30. ´ ´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. ´
  31. 31. 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
  32. 32. ´ ´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 ˜ ´
  33. 33. ´ ´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.
  34. 34. ´ ´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. ´ ı
  35. 35. 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
  36. 36. ´ ˜ ´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 ´

×