Optimización y Evaluación de Consultas en Fuentes de Datos Heterogéneas.

Optimización y Evaluación de Consultas en Fuentes de Datos Heterogéneas

Optimización de Consultas en Ambientes Heterogéneos con Capacidades Limitadas

Capacidades LimitadasInformation ManifoldGarlic

Propiedades de las Fuentes de Datos en el Internet

No existe una Interfaz de Programación para interactuar con ellas.

La respuesta se presenta en documentos no estructurados en formato HTML o semi-estructurados en XML.

La interfaz es a través de una planilla que limita el tipo de consultas que se pueden efectuar y los atributos que deben ser instanciados.

Fuentes de Datos con Capacidades Limitadas de Procesamiento.

Fuentes de Datos con Capacidades de Procesamiento Limitadas

Interfaz es una plantilla mediante la cual se deben instanciar un conjunto de atributos para que se produzca una respuesta. Respuesta es otra plantilla.

Capacidades Limitadas Una capacidad de procesamiento limitada

puede modelarse como una tupla (Input,Ouput) donde: Input: conjuntos de atributos que deben ser

instanciados. Ouput: conjunto de atributos producidos cuando

los atributos en Input son instanciados.Pelicula(NombrePelicula,Actores,Directores,CodPelicula) 0) Director-> NombrePelicula,CodPelicula

1) NombrePelicula -> Actores, Directores, CodPelicula

Fuentes de Datos-Capacidades Limitadas

FD1: publica información sobre películas, sus actores, directores, etc.

Pelicula(NombrePelicula,Actores,Directores,CodPelicula) 0) Director-> NombrePelicula,CodPelicula

1) NombrePelicula -> Actores, Directores, CodPelicula FD2: publica evaluaciones sobre películas.Evaluacion(CodPelicula,Evaluacion) 2) CodPelicula -> Evaluacion FD3: publica información sobre las películas que recibieron

algún premio durante un año particular.Premio(CodPelicula,Premio,Año) 3) CodPelicula -> Premio, Año 4) Año-> Premio, CodPelicula

Fuentes de Datos-Capacidades Limitadas FD4: publica información sobre las películas que se

presentan en los teatros o en cable.Cartelera(NombrePelicula,Dia,Teatro,Ciudad) 5) Dia,Ciudad, NombrePelicula->Teatro FD5: vende los tickets para ver las películasCine(NombrePelicula,Dia,Hora,Teatro,Disponibilidad

). 6) Dia,Hora,Teatro,NombrePelicula-

>Disponibilidad

Fuentes de Datos-Capacidades LimitadasConsulta: Chequear si hay tickets disponibles para ver una

película que haya sido producida por Almodovar, que haya ganado algún premio este año, que su evaluación sea buena, en algun cine de Barcelona, hoy a las 7:30pm.

Select C2.DiponibilidadFrom Pelicula P1, Evaluacion E, Premio P2, Cartelera C1, Cine C2Where P1.Director=“Almodovar” AND P1.CodPelicula=E.CodPelicula

AND E.Evaluacion=“buena” AND P1.CodPelicula=P2.CodPelicula AND

P2.Año=“2003” AND C1.Dia=“23-04-03” AND P1.NombrePelicula= C2. NombrePelicula AND

C1.Cuidad=“Barcelona” AND C1.Teatro=C2.Teatro AND C1.Dia=C2.Dia AND

P1.NombrePelicula= C2. NombrePelicula AND C2.Hora=“7:30pm”

Fuentes de Datos-Capacidades Limitadas En ambientes tradicionales cualquier

permutación de Pelicula, Evaluacion, Premio, Cartelera, Cine

es un plan válido. Si las capacidades de las fuentes de datos

son consideradas, planes válidos deben respetar las siguientes precedencias:

Pelicula -> Evaluacion Pelicula -> Premio,

Pelicula -> Cartelera, Cartelera ->Cine

Optimizadores de Consultas en Fuentes de Datos con Capacidades Limitadas

No cualquier orden de ejecución es seguro.

Extensiones a optimizadores existentes Capacidad de decidir si un plan de

ejecución es seguro o no. El optimizador puede perder

mucho tiempo produciendo soluciones no seguras.

Resultados en Planes de Ejecución en Fuentes de Datos en el Internet

Existen Planes de Ejecución que no pueden ser evaluados (planes no seguros de ejecución).

El espacio de los planes de ejecución en fuentes de datos con capacidades limitadas considerablemente más grande que el espacio de planes de ejecución en bases de datos tradicionales [Levy99].

Espacio de planes de ejecución: (mn)1/n! (Seguros y No Seguros) n(n+1) planes lineales izquierdos nn planes de ejecución de tipo arbusto.

n: número de sub-objetivos m: número de maneras evaluar cada sub-objetivo

Decidir si existe un plan de evaluación seguro para una consulta es NP-completo.

1

)1(2

n

n

1

)1(2

n

n

Capacidades Limitadas Una capacidad de procesamiento limitada

puede modelarse como una tupla (Input,Ouput) donde: Input: conjuntos de atributos que deben ser

instanciados. Ouput: conjunto de atributos producidos cuando

los atributos en Input son instanciados.Pelicula(NombrePelicula,Actores,Directores,CodPelicula) 0) Director-> NombrePelicula,CodPelicula

1) NombrePelicula -> Actores, Directores, CodPelicula

Fuentes con Capacidades Limitadas-Modelo de CostosCatálogo debe mantener información

sobre: Por cada tabla T:

Atributos: Tamaño, número de valores diferentes.

Capacidades: (Input,Output): Tiempo para retornar la primera tupla. Número de Páginas en el resultado. Número de Tuplas en el resultado. Costo de Comunicación por página. Por cada atributo en Output, número de valores

diferentes.

Fuentes con Capacidades Limitadas-Modelo de Costos

1) Sea A una tabla y cap la capacidad usada para acceder la tabla, entonces:

Costo(A)=costoPrimeraTupla(cap) + #Paginas(cap)*costoPorPagina(cap)

2) Sea T=Cond(P) donde la selección se realiza en el mediador:

#bloques(P) + costo(P)


3) Sea T=Atributos(P) donde la proyección se realiza en el mediador: Con repeticiones:

#bloques(P) + costo(P) Sin repeticiones: #bloques(P) + 2*#bloques(P’) +

costo(P) + costoOrdenar(P)


4) Sea T=T1 JOIN T2, si T2 no requiere de atributos producidos

por T1 para instanciar atributos de entrada, entonces:

Si se dispone de suficiente memoria principal para evaluar el Block Nested Loop: costo(T)=costo(T1) + costo(T2) +

#bloques(T1) + # bloques(T1)/#Bloques * #bloques(T2)


4) Sea T=T1 JOIN T2, Si se dispone del Hash Join:

costo(T)=costo(T1) + costo(T2) + 3*(#bloques(T1) + #bloques(T2))

Si se dispone del Sort Merge: costo(T)=costo(T1) + costo(T2) + #bloques(T1) +

#bloques(T2) + O(#bloques(T1) Log #bloques(T1) ) +

O(#bloques(T2) Log #bloques(T2) )


4) Sea T=T1 JOIN T2, si T2 requiere de atributos

producidos por T1 para instanciar atributos de entrada, entonces se requiere del DependentJoin.

Dependent Join Se requiere cuando los atributos

producidos por el outer table son necesarios para instancias atributos en la inner table.

No es commutativo. Su costo es es similar al costo de

Nested Loop Join.

A Djoin B Por cada tupla de A se deben instanciar

los atributos de entrada de B. Llamar a B tantas veces como tuplas de A

existan. En ambientes heterogéneos con fuentes de

datos con capacidades limitadas, costo(A Join B)= costo(A) + #bloques(A)

+#Tuplas(cap1)*costo(B), donde, costo(B)=costoPrimeraTupla(cap2) +#Paginas(cap2)*costoPorPagina(cap2)

El proceso de optimización debería minimizar el tamaño de A.

Information Manifold Las capacidades de una fuente de datos

se expresa a través de una registro de capacidad: Atributos de entrada que deben ser dados a

la fuente para producir la salida. Mínimo y Máximos atributos en la entrada. Las posibles salidas que la fuente puede

proyectar. Las selecciones que la fuente puede

evaluar.

Information Manifold Formalmente un registro de capacidad es

una tupla: (Sin, Sout, Ssel, min, max) Sin, Sout, Ssel son conjuntos de atributos de R y

min, max son enteros. Para obtener una tupla de R, se le deben instanciar

al menos min de los elementos de Sin. Los atributos en Sout, son los que R puede proyectar.

Los elementos en Ssel, son un subconjunto de los elementos en Sin U Sout, y son los atributos sobre los que la fuente es capaz de ejecutar selecciones.

Information Manifold-Optimización

Dado una reescritura semánticamente rc correcta, IM identifica un plan de ejecución para rc siguiendo un algoritmo polinomial.

Information Manifold-OptimizaciónEntrada: Q’ consulta semanticamente correcta. C conjunto de capacidades.Salida: un plan ejecutable para Q’QueryBindings= conjunto de las variables en Q’ instanciadas por constantes en la

consulta.Qout= las variables en la cabeza de Q’,QuerySeleccion= el conjunto de las variables sobre las cuales existe una

seleccion en Q’.BindAval0= QueryBindingsPlan=For i=1,…,n Sea Vi un subobjetivo de Q’, cuyo atributo en min son cubiertos por BindAvali-1. BindAvali= BindAvali-1 U Sout; Plan = Plan U {Vi} Sino existe tal subobjetivo, entonces terminar.End forIf Qout not(subset) BindAvaln retornar no existe plan.Else retornar(Plan)

Resultados-Tamaño Espacio de Búsqueda-Capacidades Limitadas

Garlic Datos en las fuentes de datos son vistos

como objetos y Garlic hace referencia a éstos haciendo uso de un OID que está basado en: la fuente de datos; el tipo del objeto y una clave determinada por el

wrapper/adaptador. El IOD le permite a Garlic aplicar

métodos sobre los objetos.

Garlic Los adaptadores encapsulan las

capacidades de las fuentes de datos. Conocimiento sobre las capacidades de

las fuentes de datos es representada en forma de reglas.

Un catálogo mantiene información sobre: el esquema global de Garlic y de su

definición en función de las fuentes de datos. Algunas estadísticas por datos globales.

Garlic La optimización de consultas se realiza en Garlic:

basada en costos. sin tener conocimiento de las capaciadades de las fuentes

de datos. El algoritmo de programación dinámica se extiende para

explorar planes de ejecución seguros. Garlic tiene un conjunto de reglas (Strategy Alternative Rules

STARTs) las cuales son usadas para construir los planes que evaluará la máquina de ejecución.

Determinan como los POP’s pueden ser combinados en un plan. Durante la ejecución de las consultas, se pueden evaluar a

nivel del mediador, algunas operaciones que las fuentes de datos no son capaces de evaluar.

Los adaptadores/wrappers proveen la posibilidad de evaluar el método get sobre cada objeto.

Garlic Planes

Árboles de ejecución donde cada nodo recibe el nombre de POPs (Plan Operators).

Se caracterizan por un conjunto de propiedades Tablas: conjunto de tablas que son accedidas. Columnas: conjunto de columnas a ser proyectadas. Predicados: conjunto de predicados a ser aplicados en

la selección. Fuente de Datos: identificador del objeto de donde

provienen los datos. Mat: si el resultado debe materializarse o no. Orden: si el resultado debe ordenarse. Costo: costo estimado del plan. Cardinalidad: cardinalidad estimada del resultado.

Ejemplo-Plan en Garlic

Fuentes de Datos disponibles: Mail: sistema de mensajes

Sender, Subject, Date, Body DB2: base de datos relacional con información sobre las materias y

los profesores que las dictan Consulta: SELECT m.Body FROM Current_Mail M, Classes C WHERE M.Subject=C.CourseName AND C.Professor=“Tim

O’leary”

Project tables: {Current_Mail M, Classes C}

columns: {M.Body} preds: {C.Professor=“Tim O’leary” , M.Subject= C.CourseName } source: { Garlic} mat: false order: NIL

Jointables: {Current_Mail M, Classes C} columns: {M.OID, M.Subject, M.Body, C.IOD, C.CourseName} preds: {C.Professor=“Tim O’leary” , M.Subject= C.CourseName } source: { Garlic} mat: false order: NIL

c

tables: {Current_Mail M}

columns: {M.OID, M.Subject, M.Body}

preds: {}

source: { Garlic}

mat: false

order: NIL

Fetch(M,{Subject,Body})

tables: {Current_Mail M}

columns: {M.OID,}

preds: { }

source: { Mail}

mat: false

order: NIL

PushDown(Mailtables: {Classes C}

columns: { C.IOD, C.CourseName}

preds: {C.Professor=“Tim O’leary” }

source: { DB2}

mat: false

order: NIL

PushDown(DB2)

Optimización de Consultas con Programación Dinámica: Garlic

Se ejecutan “n” iteraciones (n número de subobjetivos en la consulta).

En cada iteración “i” se construyen subplanes de longitud “i”:

Se combina el subplan SP de longitud “i-1” seleccionado en la iteración anterior con los subgoals disponibles seguros.

Subobjetivo S es seguro si: Existe una capacidad de S que puede ser satisfecha con los

atributos producidos por SP.

Se selecciona el(los) subplan(es) de longitud “i” de menor costo.

En el subplan producido todas las variables deben estar instanciadas.

Se producen planes lineales izquierdos. Para planes atómicos, Garlic solo considera un plan para

cada capacidad viable.

Programación Dinámica-Sistema R

Enumeración usando N pasadas (si N relaciones se consideran): Paso 1: Encontrar mejor plan de 1-relacion para cada relación.

Todos los nodos posibles de recorrido de las tablas son considerados.

Paso 2: Encontrar la mejor manera de hacer el join de cada plan con 1-relacion (como un outer) a otra relación. (Todos planes de 2-relaciones.) Las soluciones que tienen una solución equivalente más económica, son desechadas. Se consideran que dos soluciones son equivalentes si al hacer el join producen el mismo resultado y en el mismo orden.

Paso N: Encontrar la mejor manera de hacer el join de planes de (n-1) relaciones (como un outer) con una N’th relación. (Todos planes de N-relaciones)

Para subconjunto de relaciones, retener solo: El plan con más bajo costo y El plan con más bajo costo para cada orden interesante de las

tuplas.

Algoritmo de Programación Dinámica-Garlic

Function DynProg Entrada Rels: Conjunto de relaciones a ser ordenadas. Salida: un árbol lineal izquierdo para Rels.1. PartialSolutions:={Todos los recorridos para todos los atributos invulcrados Un plan para

cada capacidad viable. Atributos de entrada deben satisfacerse con las constantes en la consulta}

2. Remover de PartialSolutions todos los elementos con una alternativa equivalente y de menor costo.

3. For i:=2 to | Rels| 3.1 For all pt in PartialSolutions 3.1.1 For all Ri in Rels pt:= JOIN pt Ri Existe una capacidad de Ri cuyos atributos de entrada son instanciados con los

atributos producidos por pt end end 3.2 Remover de PartialSolutions todos los elementos con una alternativa equivalente y de

menor costo. end 4. Retornar un elemento de PartialSolutions

Sistema R-Garlic Construye planes considerando una clase de equivalencia

a la vez. Cada clase de equivalencia está integrada por los sub-

planes que producen el mismo resultado Tienen los mismos conjuntores y las mismas

anotaciones. Una anotación mantiene información sobre los

atributos que deben instanciarse en el sub-plan y que podrán ser producidos por el mismo.

Las clases de equivalencia se consideran en orden incremental en el número de conjuntores.

El primer plan de ejecución completo se obtiene en la última fase de la optimización.

Garlic-Optimización-Ventajas Si existe un plan seguro de ejecución

para la consulta, Garlic va a ser capaz de conseguirlo, aun si éste no es optimal.

Garlic-Optimización de Consultas-Limitaciones No diferencia entre consultas evaluables y no

evaluables. Puede generar un gran número de sub-planes

de ejecución no evaluables. Unicamente explora el espacio de planes de

ejecución lineales izquierdos. Produce la primera solución sólo después de

considerar todos los posibles sub-planes. No escala a espacios de búsqueda muy

grandes. Produce la primera solución después que todas las

posibilidades han sido consideradas

Best First Search [Florescu et. al Sidmod99] Produce soluciones sin necesidad

de recorrer todo el espacio. La calidad de la primera solución

depende de una función de utilidad.

Una vez que produce la primera solución se mantiene produciendo soluciones.

Best First Strategy[Florescu et. al Sidmod99] Extensión del Sistema R:

A cada punto de la optimización el sistema mantiene el conjunto S de los planes parciales.

Cada sub-plan p in S se etiqueta con la clase de equivalencia al cual pertenece y su costo.

Clase de equivalencia tiene todos los conjuntores cubiertos por p y sus anotaciones, p cubre a p’ si p’ es equivalente a p despues de aplicar una seleccion a p.

Inicialmente el conjunto S solo contiene sub-planes atómicos, es decir, planes para acceder una relación simple. Para una relación R el conjunto S contiene un plan de ejecución atómico por cada capacidad de R.

En el paso iterativo del algoritmo, se añaden nuevos planes a S combinando los planes en S usando selecciones y operaciones de join. Se crea un sub-plan por cada anotación. Se identifica el subplan en S con menor costo.

La opción de decidir con quien combinar un sub-plan depende de una función de medición.

En cada paso se eliminan planes no viables.

Best First Search Se usa una función de utilidad para

producir un plan completo rápido. Esta función de utilidad establece

el orden en el cual se consideran las clases de equivalencia.

Best First Search-Algoritmo Entrada: consulta Q:- C1,…,Cn V conjunto de descripciones de capacidades Salida: Plan de ejecucion para QSi Q no es seguro, entonces parar. Para I=1,…,n Anadir a S las capacidades de Ci Mientras puedan ser creados nuevos planes Seleccionar un p1 en S que maximice la funcion de utilidad Sea S’ el conjunto de planes que pueden ser combinados con p Para cada p2 en S’ (en el orden de la funcion de utilidad) hacer Sea p3 un (dependent) join entre p1 y p2 Si p3 es no viable, ignorar p3 Si existe un p4 en S, p4 cubre p3 y costo(p4) < costo(p3), p3=p4 Si existe p5 en S y p5 equivalente a p3 Si costo(p3) > costo(p5), ignorar p3 Sino en cada p6 en S que use p5 reemplazar p5 por p3 Sea S = S U {p3} if existe p7 en S, p3 cubre p7 and cost(p3) < costo(p7), reemplazar p7 por p3 Si S contiene la clase de equivalencia de Q, retornar el mejor plan de Q Sino Sea S’’ el conjunto de planes en S que cubren Q Para cada p8 en S’’ generar todos los posibles posicionamientos de las selecciones que no estan inlcuidas en p8 escoger un plan optimal entre todos estos planes

Best First Search En cada iteración trata de combinar sub-

planes de ejecucion en base a una función de utilidad.

Cuando un sub-plan de ejecucion p1 se ha identificado, y tiene menor costo a una solucion p2 equivalente previamente identificada, se sustituye p2 por p1 en todos los planes donde p2 sea usado.

Best First Search-Propiedades

Extensión a la programación dinámica con información sobre las capacidades de las fuentes de datos.

Rechaza las consultas que no son evaluables. Puede tener que consider un gran número de sub-

planes no seguros de ejecución. Explora el espacio de planes tipo arbusto.

Resultados-Tiempo (Capacidades Limitadas)

Agenda

Algoritmos AleatoriosBases de Datos Biomoleculares

Algoritmos Aleatorios Se realizan caminatas aleatorias en el

espacio de soluciones. Las caminatas se realizan en N etapas. En cada etapa:

Se genera una solución inicial de manera aleatoria.

Se aplican M transformaciones hasta conseguir una solución optimal.

Se selecciona el mejor optimal local.

Transformaciones Típicas (A JOIN B) = (B JOIN A)

(A JOIN (B JOIN C) = ((A JOIN B) JOIN C)

Se seleccionan aleatoriamente las sub-consultas a transformar.

Después de aplicar una transformación se calcula el costo del nuevo plan. Si el costo es mejor que el costo del mejor identificado hasta el momento, se descartar los anteriores. En caso contrario, se descarta el plan identificado.

Problema de Optimización de Consultas en Fuentes de Datos con Capacidades

Limitadas

WebSrcMed(Vidal00): Extensión de un optimizador aleatorio de consultas para

explorar únicamente el espacio de planes seguros. Proceso de optimzación en dos fases.

Fase 1: identifica porciones del espacio de planes de ejecución donde solo existen planes seguros. Cada porción está caracterizada por un pre-plan.

Fase 2: los pre-planes son dadas al optimizador de consultas, éste solo explora el espacio caracterizado por cada uno de estos pre-planes.

Un pre-plan: orden parcial de los sub-objetivos de la consuta. conjunto de orden de precedepcias. Ambos componentes representan las restricciones impuestas por las

capacidades de las fuentes de datos escogidas.

Optimización en Dos Fases

Espacio de Planes de EjecuciEspacio de Planes de Ejecución ón SegurosSeguros

Pre-plan1Pre-plan1

Pre-plan2Pre-plan2

Pre-plan3Pre-plan3

Pre-plan4Pre-plan4

Pre-plan5Pre-plan5

Pre-plan5Pre-plan5

Motivación: Ejemplo Fuentes de Datos

Fuente1: publica una guía para todos los programas transmitidos en TV.GuiaTv(Hora,Dia,Canal,TituloPrograma,Categoria,Cable,TipoPrograma)

Fuente2: publica una guía para todos los programas transmitidos en canales públicos.GuiaTv(Hora,Dia,Canal,TituloPrograma,Categoria,Cable,TipoPrograma)

Fuente3: publica información sobre directores de programas. Programa(TituloPrograma,Categoria,Director,Ano)

Fuente4: publica información sobre premios.Premios(NombrePremio,Ano,NombreGanador)

Motivación: Ejemplo Interfaz Común

Una guia de los programas de TV transmitidos en la naciónGuiaTv(Hora,Dia,Canal,TituloPrograma,Categoria,Cable,TipoPrograma)

Información sobre los Directores de Programas de TVPrograma(TituloPrograma,Categoria,Director,Ano)

Información sobre los Premios Otorgados a los Programas de TVPremios(NombrePremio,Ano,NombreGanador)

Motivación: Capacidades de Procesamiento

Relación GuiaTv: Md1: Dia,Hora ->Canal,TituloPrograma Md2: [] -> Dia,Hora, Canal,TituloPrograma

Relación Programa: Md3: Director -> TituloPrograma Md4: TituloPrograma -> Director Md5:[] -> TituloPrograma, Director

Relación Premio: Md6: NombrePremio -> NombreGanador Md7:NombreGanador -> NombrePremio Md8:[] -> NombrePremio.NombreGanador

Motivación: Consultas

“Dar los premios que han sido recibidos por los directores de los programas de TV presentados el día 15 de Noviembre de 2001 a las 7:30pm”.

Select NombrePremio From GuiaTv Gt,Programa Po,Premio Pe Where Dia=“15:09:01” and Hora=“19:30” and Gt.TituloPrograma=Po.TituloPrograma and Po.NombreDirector=Pe.NombreGanador

Motivación: Planes de Ejecución

GuiaTv Dia=“15:09:01”,Hora=“19:30” Programa Premio

(Md1,Md4,Md7) (Md1,Md4,Md8) (Md1,Md5,Md7)(Md1,Md5,Md8) (Md2,Md4,Md7) (Md2,Md4,Md8)(Md2,Md5,Md7) (Md2,Md5,Md8)

GuiaTv Dia=“15:09:01”,Hora=“19:30 Premio Programa

(Md1,Md8,Md3) (Md1,Md8,Md4) (Md1,Md8,Md5) (Md2,Md8,Md3) (Md2,Md8,Md4) (Md2,Md8,Md5)

Programa GuiaTv Dia=“15:09:01”,Hora=“19:30 Premio(Md5,Md1,Md7) (Md5,Md1,Md8)(Md5,Md2,Md7) (Md5,Md2,Md8)

Motivación: Planes de Ejecución

Programa Premio GuiaTv Dia=“15:09:01”,Hora=“19:30

(Md5,Md1,Md7) (Md5,Md1,Md8)


Premio Programa GuiaTv Dia=“15:09:01”,Hora=“19:30



Premio GuiaTv Dia=“15:09:01”,Hora=“19:30 Programa



Conducta de un Optimizador Tradicional

Query con 5-way join, 3 WSIs por relación

Problema de Optimización de Consultas

Optimizadores de Consultas Aleatorios: Algoritmo Iterative Improvement para explorar el espacio

de los planes de ejecución. Escala muy bien para espacio de planes de consultas

complejas. No puede limitar su búsqueda a planes de ejecución

seguros. Transformaciones típicas:

Intercambio de las hojas de un subárbol: (A Join B) => (B Join A)

Intercambio de los hijos bajos de un subárbol: ((S1 Join S2) Join S3) => ((S1 Join S3) Join S2)

Cómo garantizar que la transformación es Segura?

Ejemplos de Pre-Planes

(<[Programa,Premio,GuiaTv]>,) (Md1,Md5,Md8) (Md2,Md5,Md8) (<[Programa, GuiaTv],[Premio]>,<(Premio,Programa)>) (Md1,Md5,Md7) (Md2,Md5,Md7) (<[Premio, GuiaTv],[Programa]>,<(Programa, GuiaTv)>) (Md1,Md8,Md4) (Md2,Md8,Md4) (<[Premio, GuiaTv],[Programa]>,<(Programa, Premio)>) (Md1,Md8,Md3) (Md2,Md8,Md3) (<[GuiaTv],[Programa],[Premio]>,<(GuiaTv,Programa), (Premio,Programa)>) (Md1,Md4,Md6) (Md2,Md4,Md6)

Optimizador de Consultas: Iterative Improvement Realiza caminatas aleatorias en el espacio de planes

seguros de ejecución que son un enumeración simple de los subobjetivos en un pre-plan.

Selecciona el mejor de los planes explorados en base al modelo de costos.

Las caminatas aleatorias son ejecutadas en Etapas. Etapa:

Generación plan inicial. Transformaciones al plan inicial, deben producir un plan

seguro (enumeración del pre-plan): Intercambio de las hojas de un subárbol:

(A Join B) => (B Join A) Intercambio de los hijos bajos de un subárbol:

((S1 Join S2) Join S3) => ((S1 Join S3) Join S2)

Arquitectura:

Basada en la Arquitectura de Mediadores-Traductores.

Extensión al sistema WebSrcMed (Vidal,Zadorozhny,Raschid,Urhan, Universidad de Maryland)

Catálogo

Optimizador 2 Fases

Pre-Optimizador

Optimizador Aleatorio

Evaluador

Traductores

Fuentes de DatosPredator

Detailed Architecture

Execution Engine

Web Query Optimizer

Extended Randomized Optimizer

Capability-Based Pre-optimizer

Web Query Broker

WCM WebPT WCM WebPT

Catalog

Web Source Web Source

Mediator

Predator

WrapperWrapper

Query

Espacio de PrePlanes

Radio entre el número de Planes y PrePlanes

El número de Pre-Planes puede llegar a ser 2 n-1.

En este caso existen nn planes

1

)1(2

n

n

PreOptimizador0: Búsqueda Exhaustiva

Costo de los Mejores Planes de cada uno de los Pre-Planes

Pre-Plan vs Costo Mejor Plan

0.00E+00

1.00E+07

2.00E+07

3.00E+07

4.00E+07

5.00E+07

6.00E+07

7.00E+07

8.00E+07

0 50 100 150 200 250 300

Pre-Planes

Co

sto

Me

jor

Pla

n

Series1

Modelo de Costos de Preplanes

Consideraciones para determinar el costo de un pre-plan:

Costo Remoto: tiempo para retornar la primera tupla. Costo de Obtener una Página: tiempo requerido para

obtener una página de datos relevantes. Se mantiene por cada capacidad.

Cardinalidad del Resultado: número de tuplas en el resultados. Se mantiene por cada capacidad.

Se ignora el procesamiento a nivel del mediador. Solo se considera el procesamiento externo. Se supone que el optimizador identificará el mejor plan para

evaluar el sub-plan a nivel del mediador. Se consideran mejores los pre-planes cuyos órdenes de

procesamiento a nivel del mediador minimiza la cardinalidad. (más selectivos)

Modelo de Costos de planes Por cada capacidad de una relacion

Costo Remoto: tiempo para retornar la primera tupla. Costo de Obtener una Página: tiempo requerido para

obtener una página de datos relevantes. Se mantiene por cada capacidad.

Cardinalidad del Resultado: número de tuplas en el resultados. Se mantiene por cada capacidad.

Costo(P)=costoLocal(p) + costoExterno(p) costoLocal(p): depende de la cardinalidad y factores de

selectividad de las selcciones que se efectuan a nivel del mediador.

costoExterno(p): depende del Costo Remoto Costo de Obtener una Página y cardinalidad de resultado de cada capacidad.

PreOptimizador: Ejemplo Modelo de Costos

SubObjetivos consulta Q: A, B, C, D Dependencia: (A,B)

Cost(Q)=costo(A) + costo(C) + costo(D)+ cardinalidad(A)*cost(B)

Se supone que el optimizador de planes identificará el mejor orden para A, C y D.

Modelo de Costos

Correlación entre costos pre-planes y costos mejores planes

Optimización Basada en Costos - Dos Fases Fase 1:

Se recorre el espacio de los pre-planes de ejecución y se identifica un pre-plan de ejecucución con bajo costo.

Preplanes con bajo costo caracterizan espacios con buenos planes.

Se recorre el espacio haciendo uso de un algoritmo aleatorio.

Optimización Basada en Costos -Dos Fases Fase 2:

El optimizador relacional recorre el espacio caracterizado por el pre-plan seleccionado.

Se recorre el espacio haciendo uso de un algoritmo aleatorio.

Pre-Optimizador Aleatorio: Iterative Improvement Realiza caminatas aleatorias en el espacio de pre-planes. Selecciona el mejor de los pre-planes explorados en base al modelo de

costos. Las caminatas aleatorias son ejecutadas en Etapas. Etapa:

Generación pre-plan inicial. Transformaciones al pre-plan inicial

El número de Etapas y Transformaciones vienen dados como parámetros de la configuración.

Una vez que se selecciona un pre-plan optimal pp el optimizador aleatorio realiza caminatas aleatorias en el espacio de planes caracterizado por pp.

Selecciona el mejor de los planes explorados en base al modelo de costos.

Las caminatas aleatorias son ejecutadas en Etapas. Etapa:

Generación plan inicial. Transformaciones al plan inicial

PreOptimizador0 VS. PreOptimizador1

Busqueda Exhaustiva PrePlanes

-5.00E+15

0.00E+00

5.00E+15

1.00E+16

1.50E+16

2.00E+16

2.50E+16

0 10 20 30 40 50 60 70

PrePlanes

Co

sto

Pre

Pla

ne

s

Series1

PreOptimizador1 identidificó pre-plan con

costo:1.9553E+08(Segundo mejor valor).

Optimización de Consultas-Qué falta por hacer? No existen modelos de costos que reflejen el

comportamiento de Internet. No existen optimizadores que consideren toda

la información que puede describir a una fuente de datos. Propiedades de enlaces entre las fuentes de datos,

por ejemplo, entre fuentes de datos biomolecuales. Propiedades de servicios ofrecidos por la fuente

No escalan en ambientes donde las fuentes de datos tienen un diverso número de capacidades.

Evaluación de Consultas-Ambientes Heterogéneos

Evaluaciones Adaptativas

Evaluación Adaptativa-Tipos de Retardos

Retardos Iniciales: el tiempo de llegada de la primera tupla es mayor al esperado.

Tiempo de Transferencia Lento: los datos llegan a una frecuencia constante pero más lento que lo esperado.

Llegadas en lotes: los datos llegan en bloques de forma irregular. Las decisiones tomadas por el optimizador

pueden ser no precisas.

Condiciones de Adaptación El sistema recibe información desde su

ambiente. El sistema usa la información para

determinar su conducta. El sistema itera en el tiempo, generando

un proceso de retroaliementación entre la información suministrada por el ambiente y su comportamiento.

Soluciones AdaptativasOcultar retardos no esperados o considerados

durante el proceso de optimización. Operadores Adaptativos: extensiones a los

operadores físicos que permiten producir soluciones pese a que alguna de las entradas esté bloqueada. Telegraph, Tukwila, XJoin

Evaluadores de Consultas Adaptativos: extensiones a las máquinas de evaluación que permiten adelantar trabajo, pese a que alguna de las fuentes de datos esté bloqueada o que existan retardos no esperados. Query scrambling, Mermaid, Sage

Operadores Adaptativos-XJoin Principios fundamentales:

Optimización para producir resultados incrementalmente a medida que los datos se vuelven disponibles.

Permite que se produzcan resultados aunque las fuentes de datos experimenten algún retardo.

Xjoin-Propiedades Maneja el flujo de tuplas entre memoria

principal y memoria secundaria. Controla el procesamiento en background

que se inicializa cuando existe algun retardo en la llegada de los datos.

Asegura que la respuesta completa es totalmente calculada.

Asegurando que no existen tuplas duplicadas.

A Xjoin B Se crean dos tablas de hash, una para A y otra para

B. Se usa una función de hash h1 para particionar A y

B. Cuando una tupla t llega desde A/B, t se inserta en

la tabla hash correspondiente y se prueba en la otra.

Cada partición está compuesta de una porción residente en memoria prinicipal y una porción residente en disco.

La porción de memoria principal matiene las tuplas que han llegado más recientemente. La porción de memoria en disco mantiene el resto.

A Xjoin B Inicialmente cada partición tiene asignado un

bloque y se van aplicando bloques a medida que se requieren.

Cuando la memoria principal se llena, se seleccionan las tuplas de la partición que ocupa más memoria principal y se escriben en disco.

Si una de la entradas se vuelve no disponible, se sigue procesando el operador con las tuplas que se encuentran en memoria principal y/o disco.

XJoin

1 n 1 k n

AB

A Xjoin B-Etapas Primera Etapa: las tuplas de las respectivas

fuentes de datos se particionan en base a los atributos en la condición del Join.

Cuando llega una tupla se inserta en su partición y se prueba en la de la otra fuente de datos. Un match produce una salida.Se finaliza cuando una de las fuentes de datos se bloquea enviando datos. Puede dejar de hacer join entre tuplas que no están en memoria al mismo tiempo.

A Xjoin B

i j i j… …

Particiones de A Particiones de B

Fuente A Fuente B

Hash(registro A)=i

Hash(registro B)=j

Insercion prueba

prueba insercion

A Xjoin B-Etapas Segunda Etapa: se activa cuando la primera etapa se

bloquea. Se selecciona una porción en disco de una de las particiones PA, y se usa para probar la porción de memoria residente de la partición correspondiente de la otra fuente de datos. Un match produce una salida. Una vez que la porción de memoria en disco se termina de considerar, se chequea si ya la fuente de datos que estaba bloqueada se ha desbloqueado. En caso afirmativo, comienza nuevamente la fase 1. En caso negativo, se selecciona una nueva porción en disco. Puede dejar de hacer join entre tuplas que no están en memoria al mismo tiempo.

A Xjoin B-Etapas Tercera Etapa: se activa después que todas

las tuplas han sido recibidas. Es un proceso de limpieza que garantiza que todas las tuplas son producidas. Hace join de todas las particiones de las dos fuentes de datos. Las particiones en disco se traen a memoria principal y se crea una tabla hash para ellos.

Evaluadores Adaptativos

Evaluador Adaptativo

Procesamiento de consultas en el Web introduce nuevos problemas: La entrega de datos puede

ser más lenta de lo que se esperaba.

La entrega de los datos puede ser en paquetes.

La entrega de los datos puede interrumpirse

Las fuentes de datos se pueden volver inaccesibles.Propuestas estáticas no son capaces de adaptarse a estos

problemas dinámicamente.

Evaluador Adaptativo Adaptarse a las sobreestimaciones

realizadas durante la fase de optimización: Imprecisión en las estadísticas. Retardos en la llegada de los datos Congestiones en la red. No disponibilidad de la fuente de datos

Hacer cambios en el plan de ejecución que oculten los retardos.

Sistema R Mantiene un catálogo de estadísticas

que incluyen cardinalidades de las tablas y valores de distribución de los valores de las columnas.

El sistema no tiene retroalimentación explícita del ambiente.

El administrador debe actualizar las estadísticas.

Ingres Menos efectivo que el proceso del Sistema R

pero más adaptativo. Se alterna entre la selección de un sub-plan y

su ejecución. Para un consulta de n tablas:

Selecciona la tabla más pequeña. Para cada tupla t en la tabla más pequeña:

Elige la próxima tabla cuyo resultado de join sea el más pequeño.

Aplica el algortimo recursivamente. Para cada tupla el orden de join puede ser

diferente.

Dinamic Query PlansGrafe and Cole El optimizador descarta solo aquellos

planes que son sub-optimales en cualquier configuración.

El resultado de la optimización estática es un conjunto de planes C.

A tiempo de ejecución se determinan los mejores planes en C. Se hace uso de los valores encontrados en la consulta.

Adaptative Selectivity Estimation Chen and Rouspoulus Provee al sistema R con un sistema de

retroalimentación de sus estadísticas. Cuando una consulta se ejecuta, los

tamaños de los resultados intermedios se registran y se utilizan para actualizar las estadísticas mantenidas por el optimizador.

El mecanismo no modifica información de tablas que no han sido llamadas en alguna consulta.

DEC RDB (Predecesor de Oracle) Usa competencia para la selección

de métodos de acceso. Se basa en la la selección dinámica

de de métodos de acceso. Para cada tabla en la consulta, se

aplican los diferentes métodos de acceso y se seleccionan aquellos con mejor comportamiento.

Mariposa-Optimización en ambientes federados

Durante la optimización, cada Mariposa le solicita a cada fuente una apuesta del costo del respectivo sub-plan.

Cada vez que se repite la evaluación de la consulta, la fuente de datos debe ajustar su apuesta, comparandola con apuestas anteriores.

La optimización se hace en dos etapas: Mariposa selecciona los órdenes de los joins y

métodos de acceso de manera central. Las apuestas afectan las decisiones tomadas por la

fuente de datos.

Evaluador Adaptativo-Query Scrambling[Urhan96]

Modificar el plan on-the-fly si algún problema se detecta.

El objetivo es ocultar retardos ejecutando otro trabajo útil.

Comenzar con un plan optimizado y en dos fases modificar el plan inicial, en espera que las fuentes de datos retrasadas respondan. Fase 1: Se materializan partes del árbol que pueden

evaluarse. Fase 2: Se cambia el orden de evaluación de los

operadores que aparecen en el árbol.

Query Scrambling-Fase 1

B C D E

1

2

3

4

A

1

4

A

CDEB

Modificado

Plan Inicial

La fuente de datos A sufre un retaso

Se materializa el sub-árbol de raíz 3

No pueden materializarse más sub-árboles.Finaliza Fase 1

Query Scrambling-Fase 2

A

CDEB

A

CDEB

Operadores Nuevos

Modificado

Se crean nuevos operadores entre B y CDE (Si no genera un Producto Cartesiano)

1

4

A

CDEB

Modificado

Query Scrambling-Limitaciones

A está retrasadoPlan Original>>

•Se requiere de gran cantidad de memoria temporal para mantener los resultados materializados.

•En fase 2 se pueden generar operadores cuyo factor de selectividad no es optimal degradándose el comportamiento del plan inicial.

Soluciones Adaptativas-Limitaciones Los cambios se hacen en base a

heurísticas pese a que la optimización se realizó en base a costos.

Al igual que el optimizador de consultas, deben tomar en cuenta información sobre las fuentes de datos, para no degradar el comportamiento del plan inicial seleccionado.

Conocimiento sobre fuentes de datos equivalentes, podría ser de intersés. Mecanismos de inferencia son requeridos!

Optimización y Evaluación de Consultas en Fuentes de Datos Heterogéneas.

Documents

Transcript of Optimización y Evaluación de Consultas en Fuentes de Datos Heterogéneas.