M. Andrea Rodríguez-Tastets. II Semestre

Transcripción

1 M. -Tastets Universidad de Concepción,Chile andrea II Semestre

2

3 Objetivos de la Unidad Entender cómo las consultas son resuelta y cuál es su costo.

4 Evaluación de Plan: Árbol de operadores de algebra relación con la elección de algoritmos por cada operador. Dos importantes consideraciones en optimización de consulta: (1) cuáles planes son considerados?, (2) Cuál es el costo del plan estimado? Idealmente: Uno busca el mejor plan. En la práctica: uno elimina los peores planes

5 Algunas Técnicas Algoritmos para evaluar cada operador relacional usan algunas ideas simples: Indexación: usa condiciones WHERE para recuperar un conjunto pequeño de tuplas (selections y joins) Iteración: Algunas veces es más rápido recorrer todas las tuplas, aún cuando exista un índice. (Algunas veces se pude recorrer las entradas de los índices en vez de los datos en las tablas) Particiones: Usando un ordenamiento o hash se pude dividir las tuplas de entrada y reemplazar una operación sobre todas las tuplas en operaciones similares sobre pequeños conjuntos de tuplas de entrada.

6 Estadísticas y Catálogos Es necesario información acerca de las relaciones e índices existentes. Catálogos típicamente contienen, al menos: N. tuplas (Ntuples) y N. páginas (Npages) por cada relación N. de valores de claves distintos (Nkeys) y Npages por cada índices Altura del índice, valores de claves alta y bajas del árbol de ndice. Los catálogos son actualizados periódicamente Mayor detalle de información puede ser también almacenada (histograms..)

7 Caminos de Acceso Un camino de acceso es un método de recuperación de tuplas. Recorrido del archivo, o índice que concuerda con una selección en la consulta. Un índice árbol calza con una (conjunción) de términos que envuelven sólo atributos en un prefijo de la clave de búsqueda. Ej. El índice de < a, b, c > calza la selección a = 5 AND b = 3, y a = 5 AND b > 6, pero no b = 3 Un índice hash calza con una (conjunción) de términos que tiene un atributo = valor para cada atributo de la clave de búsqueda del índice. Ej. índice hash de < a, b, c > calza con a = 5 AND b = 3 AND c = 5, pero no b = 3, o A = 5 AND b = 3, o a > 5 AND b = 3 AND c = 5.

8 Esquema de ejemplo VELEROS(sid:integer,sname:string,rating: integer, age: real) RESERVAS(sid: integer, bid: integer, day: dates, rname: string) Reservas: Cada tupla es 40 bytes de largo, 100 tuplas por páginas, 1000 páginas. Veleros: Cada tupla es 50 bytes, 80 tuplas por páginas, 500 páginas.

9 Selecciones Complejas (day < 8/9/94 AND rname = Paul ) OR bid = 5ORsid = 3 Condiciones de selección son covertidas primero a forma normal conjuntiva (CNF): (day < 8/9/94 OR bid = 5 OR sid = 3) AND (rname = Paul OR bid = 5 OR sid = 3) Aquí solo discutiremos casos sin or

10 Un Enfoque Encontrar el camino de acceso más selectivo, recuperar las tuplas usándolo, y aplicar cualquier término remanente que no calce el índice. Camino más selectivo: Un índice o barrido de archivo que se piense necesitará menor número de páginas de I/O. Términos que calzan este índice reducen el número de tuplas recuperadas, otros términos son usados para descartar algunas tuplas recuperadas, pero no afectan el número de tuplas/páginas recolectadas (fetched). Considere day < 8/9/94 AND bid = 5 AND sid = 3. Un B+ tree por day puede ser usado; entonces, bid = 5 y sid = 3 deben ser evaluados por cada tupla. Similarmente, un índice hash por < bid, sid > puede ser usado; entonces day < 8/9/94 debe ser evaluado.

11 Usando un índice para Selecciones El costo depende de la cantidad de tuplas y agrupamiento: El costo de encontrar las entradas de datos que califican (típicamente pequeño) más el costo de recuperar registros (puede ser bastante con o sin agrupamiento). Por ejemplo, asumiendo una distribución uniforme de nombres, cerca del 10 % de tuplas califica (100 páginas, tuplas). Con índice agrupado, el costo es un poco más de 100 I/Os; si no está agrupado, puede ser de hasta I/Os. SELECT * FROM Reserves R WHERE R.rname < C %

12 Usando un índice para Proyecciones La parte costosa es remover las duplicaciones. El sistema SQL no remueve tuplas a menos que se use DISTINCT en la consulta. Enfoque de ordenamiento: Ordene por < sid, bid > y elimine duplicados. (Se puede optimizar al eliminar información no deseada en el momento de la ordenación.) Enfoque Hashing: Hash por < sid, bid > para crear particiones. Cargar particiones en memoria una por una, construir en memoria una estructura hash e eliminar duplicados. Si existe un índice con ambos R.sid y R.bid en la clave de búsqueda puede ser más barato ordenar las entradas de datos. Bases de Datos SELECT DISTINCT R.sid, R.bid FROM Reserves R

13 Join de Igualdad con una Columa de Join En algebra: R S es común y debe ser cuidadosamente optimizado. R S es grande; así, R S seguido por una selección es ineficiente. Asuma: M el número de páginas en R, p R tuplas por páginas, N el número de páginas en S, p S tuplas por páginas. En nuestro ejemplo, R es Reservas y S es Veleros. Métrica de costo: # de I/Os. SELECT * FROM Reservas R1, Veleros S1 WHERE R1.sid=S1.sid

14 Join: Loop Anidado Simple foreach tuple r in R do foreach tuple s in S do if r i == s j then add < r, s > to result Por cada tupla en la relación externa R, se recorre la relación interna S entera. Cost: M + p R M N = I/Os, con M el número de páginas en R, p R el número de tuplas por página en R y N el número de páginas en S. Loop anidado de join orientado a la página: Por cada página de R, tome cada página de S, y saque las tuplas que calzan < r, s >, donde r está en página R y s está en página S. Cost: M + M N = Si la relación más chica (S) es externa, costo =

15 Join: Loop Anidado Indexado foreach tuple r in R do foreach tuple s in S where r i == s j do add < r, s > to result Si hay un índice sobre la columna de join en una relación (digamos S), el loop interno puede explotar el índice. Cost: M + ((M p R ) costo de encontrar tuplas en S que calzan. Por cada tupla R, el costo de buscar en índice S es cerca de 1.2 para índice hash, 2-4 para B+ tree. El costo de encontrar tuplas S (asumiendo Alt. loop simple o loop indexado para entradas de datos) depende del agrupamiento: índice agrupado: 1 I/O (típico), no agrupado : hasta 1 I/O por tupla en S que calza.

16 Ejemplo: Loop Anidado Indexado Hash-index sobre sid de Veleros (interna): Recorre Reservas: 1000 páginas I/Os, tuplas. Por cada tupla de en Reservas: 1.2 I/Os para obtener entrada de datos del índice, más 1 I/O para obtener la tupla en Veleros que calza. Total: 220,000 I/Os. Hash-index sobre sid de Reservas (interna): Recorre Veleros: 500 page I/Os, 80*500 tuplas. Por cada tupla en Veleros: 1.2 I/Os para encontrar página de índice con entradas de datos, más el costo de recuperar las tuplas que calzan desde Reservas. Asumiendo distribución uniforme, 2.5 reservaciones por veleros (100, 000/40, 000). Costo de recuperarlos es 1 o 2.5 I/Os dependendiendo si el índice está agrupado o no.

17 Join: Loop Anidado de Bloque R & S Hash table for block of R (k < B-1 pages)... Join Result Input buffer for S Output buffer Use una página como un buffer de entrada para recorrer la relación interna S, una página como buffer de salida, y use todas las páginas remanente para mantener block de la relación externa R. Por cada tupla matching r en R-block, s en S-página, agregue < r, s > al resultado. Entonces lea el próximo R-block, recorra S, etc.

18 Ejemplo: Loop Anidado de Bloque Costo: Recorrido externo + # Blocks externos recorrido interno: # outer blocks = # pages of outer / blocksize Con reservas (R) como externo y 100 páginas de R: Costo de recorrdio de R es 1000 I/Os; un total de 10 blocks. Por bloque de R, se recorre Veleros (S); 10*500 I/Os. Si espacio sólo para 90 páginas de R, se recorría S 12 veces. Con 100-page block de Veleros como externo: Costo de barrido de S es 500 I/Os; un total de 5 blocks. Por bloque de S, se recorre Reserves; 5*1000 I/Os. Con lecturas secuenciales puede ser mejor dividir los buffer en forma balanceada entre R y S.

19 join: Sort-Merge Ordene R y S por la columna de join, entonces recórralos para hacer un merge (sobre la columa join), y saque las tuplas de resultado: Avance en el recorrido de R hasta la R-tupla actual >= que la S-tupla actual, entonces avance en el recorrido de S hasta que S-tupla actual >= R-tupla actual; haga esto hasta que R tupla actual = S tupla actual. En ese punto, todas las R tuplas con el mismo valor en R i (R grupo actual) y todas las S tuplas con el mismo valor en S j (S grupo actual) calzan; saque < r, s > para todos los pares de tuplas. Luego retome el recorrdio de R y S. R es recorrida una vez; cada grupo S es recorrido una vez por tupla R calzante (Barridos múltiples de un grupo S se encuentran probablemente en el buffer)

20 Ejemplo: Sort-Merge Join sid sname rating age 22 dustin yuppy lubber guppy rusty sid bid day rname /4/96 guppy /3/96 yuppy /10/96 dustin /12/96 lubber /11/96 lubber /12/96 dustin Cost: MlogM + NlogN + (M + N). El costo del barrido, M + N, could be M N (muy improbable) Con 35, 100 o 300 páginas buffer, ambos Reservas y Veleros pueden ser ordenados en 2 pasos; costo total 7500.

21 Refinamiento Sort-Merge Join Pueden combinarse las fases de merging en el ordenamiento de R y S con el merging requerido para el join. En ejemplo, costo desciende de 7500 a 4500 I/Os. En la práctica, el costo de sort-merge join, como el costs del ordenamiento externo, es lineal.

22 Hash Join (1) Original Relation... OUTPUT 1 INPUT 2 hash function h B-1 Partitions 1 2 B-1 Divida ambas relaciones usando la misma función h de direccionamiento calculado sobre los atributos de reunión: R tuplas en partición i sólo calzarán las tuplas de S tuplas en partición i. Disk B main memory buffers Disk

23 Hash Join (2) Partitions of R & S hash fn h2 Hash table for partition Ri (k < B-1 pages) Join Result h2 Lea una partición de R, aplique el hash usando h (h h). Recorra partición matching de S, búsque por calces. Disk Input buffer for Si Output buffer B main memory buffers Disk

24 Costo: Hash Join En fase de partición, lectura+escritura de ambas relaciones: 2(M + N). En fase de matching, lectura de ambas relaciones: M + N I/Os. En nuestro ejemplo, este es un total de 4500 I/Os. Sort-Merge Join vs. Hash Join: Dada una cantidad mínima de memoria ambos tienen un costo de 3(M + N) I/Os. Hash Join es mejor si el tamaño de las relaciones difiera enormemente. Además, Hash Join puede paralelizarse. Sort-Merge es menos sensitivo a las distribución de los datos; el resultado está ordenado.

25 Condiciones Generales Join Igualdad sobre varios artibutos (e.g., R.sid = S.sid AND R.rname = S.sname): Para NL indexado, construya índice sobre < sid, sname > (Si S es interno); o use índices existente sobre sid o sname. Para Sort-Merge y Hash Join, sort/partition en combinación de las dos columnas. Condiciones de desigualdad (e.g., R.rname < S.sname): Para NL indexado, necesita índice B+ tree agrupado. # de calces tienden a ser más que por join por igualdad. Hash Join, Sort Merge Join no son aplicables. Block NL por bloques es probablemente mejor para métodos de join de este tipo de consultas.

26 Ordenamiento/Clasificación Es uno de los algoritmos básicos empleados en procesamiento de consultas. Por ejemplo, ORDER BY, UNION, DISTINCT, etc.. El algorimo de clasificación externa considera el ordenamiento de archivos que no caben totalmente en memoria. Para ello se ocupa una estrategia de clasificacion/fusional (sort-merge)

27 algoritmo Sort-Merge Sea i 1; j b (tamaño del fichero en bloques); k n b (tamaño del búfer en bloques); m (j/k) ; (Fase de clasificación) mientras (i m) hacer { leer siguientes k bloques del fichero en el búfer o si quedan menos de k bloques, entonces leer los restantes bloques; clasificar los registros en el búfer y escribirlos como un subfichero temporal; i i + 1; } (Fase de fusión: fusionar archivos hasta que sólo quede 1) Sea i 1; p log k 1 m (p es el número de pasadas de la fase); j m; mientras (i p) hacer { n 1; q (j/(k 1)) ; (número de archivos a escribir en este paso) mientras (n q) hacer { leer los siguientes k 1 subarchivos o los subarchivos restantes un bloque cada vez; fusionar y escribir un nuevo subarchivo; n n + 1; } j q; i i + 1; }

28 Ejemplo: Indice Agrupado Indice B+ tree sobre el atributo edad de empleado puede ser usado para calificar tuplas: SELECT E.edad FROM EMPLEADO E WHERE E.edad > 40 Consider la consulta GROUP BY SELECT E.Ndpto, COUNT( ) FROM EMPLEADO E WHERE E.edad > 40 GROUP BY E.Ndpto Consulta de igualdad y duplicacin SELECT E.nombre FROM Empleado E WHERE E.Hobby = musica

29 Indice con Clave Compuesta Búsqueda por la composición de atributos: Consulta por igualdad: Cada atributo es igual a una cte. Consulta por rango: Uno o varios de los atributos no debe ser igual a una cte. Entrada de datos en índice ordenadas por clave de búsqueda para consultas por rango Los índices por clave compuestas son más grandes y requieren mayor actualizacin

30 Sólo Indice Algunas consultas puede ser respondidas sin recuperar tuplas que forman parte de la relación manejada por el índice. SELECT Ndpto, COUNT( ) FROM EMPLEADO GROUP BY Ndepto En general, consultas que retornan funciones de agregación Este tipo de respuesta es posible si el índice es por Ndpto.

31 Modelo de costo B: Número de páginas de datos R: Número de registros por página D: Tiempo (promedio) para leer/escribir una página de/a disco. Midiendo el número de páginas I/O ignora las ganancias para secuencia de páginas. El análisis de costo es una simplificación pero muestra la tendencia

32 Comparación: organización de archivos Pila: orden aleatorio con inserción al final Archivos ordenados por un clave Archivo B+ agrupado Hash no agrupado

33 Comparación: operaciones Barrido (scan) Búsqueda con selección de igualdad Búsqueda con selección de rango Insertar registro Borrar registro

34 Comparación Barrido Igualdad Rango Pila BD 0,5BD BD Ordenado BD Dlog 2 B D(log 2 B+ # match pages) Arbol agrup. BD(R + 0,15) D(1 + log F 0,15B) D(log F 0,15B+ # match pages) Hash no agrup. BD(R + 0,125) 2D BD Insertar Borrar Pila 2D Search + D Ordenado Search + BD Search + BD Arbol agrup. Search + 2D Search + 2D Hash no agrup. Search + 2D Search + 2D

35 Carga de trabajo Para cada consulta: Qué relaciones accesa? Qué atributos se recuperan? Cuáles atributos participan en condición de selección? Cuán selectiva son estas condiciones? Para actualización Cuáles atributos participan en condicin de selección? Cuán selectiva son estas condiciones? El tipo de actualización

36 Elección del indice (1) Qué índice debiera crear: Qué relaciones debieran tener índices? Qué campos debieran formar llaves de búsqueda? Cuántos índices debíeramos crear? Para cada índice Qué tipo? (árbol, hash, agrupado) Enfoque: considere las consultas más importantes en turno. Considere un plan de ejecución de una consulta y vea si agregando un índice esto puede mejorarse Antes de crear el índice, piense su implicancia en el costo de actualización

37 Elección del indice (2) Atributos en WHERE son candidatos de clave de búsqueda: (1) condiciones de matching exacto sugiere Hash, (b) rango sugiere árbol. Claves con múltiple atributos se consideran cuando WHERE tienen muchas condiciones. Estas condiciones puden evaluarse con estrategias de only-index.

38 Ejercicio (1) Defina el término de camino de acceso selectivo de una consulta. Por qué las formas normal conjuntiva es usada para el procesamiento de consultas?

39 Ejercicio (2) Considere una relacion R(a, b, c, d, e) contiene 50, 000 registros, donde cada página contiene 10 registros. R está organizado como un archivo ordenado con índices secundarios. Asuma que R.a es la clave candidata de R, con valores entres 0 y y que R es almacenda en el orden dado por R.a. Además considere que los valores de b se distribuyen uniformemente de manera que no existen más de 10 tuplas con los mimos valores de b. Por cada una de las consultas siguientes, indique cuál de los siguientes enfoques es el más baratos: Enfoques: 1. Acceso de archivos ordenado por R directamente 2. Uso de B+ agrupados sobre atributo R.a 3. Uso un índice hash sobre atributo R.a 4. Uso B+ agrupado sobre atributos (R.a, R.b) 5. Uso hash sobre atributos (R.a, R.b) : 1. σ a<50,000andb<50,000 (R) 2. σ a=50,000andb<50,000 (R) 3. σ a>50,000andb=50,000 (R) 4. σ a=50,000andb=50,000 (R) 5. σ a 50,000ANDb=50,000 (R) 6. σ a<50,000andb=50,000 (R)

40 En un proceso de procesamiento de consulta, se crea una representación interna de la consulta, por lo regular en forma de estructura de datos de árbol o grafo. Esto se denomina árbol o grafo de consulta. En seguida, el SGBD debe crear una estrategia de ejecución para obtener el resultado de la consulta a partir de los archivos internos de la base de datos. Por lo general, una consulta tiene muchas posibles estrategias de ejecución, y el proceso de elegir la más adecuada se conoce como optimización de consultas.

41 (1) Consulta en un lenguaje de alto nivel Analisis lexico y analisis sintactico y validacion Forma intermedia de la consulta Optimizador de consultas Plan de ejecucion Generador de codigo de consulta Codigo para ejecutar la consulta Procesador de base de datos en tiempo de ejecucion Resultado de la consulta

42 (2) El módulo optimizador de consultas se encarga de producir un plan de ejecución y el generador de código genera el código necesario para ejecutarlo. El optimizador en realidad no escoge siempre el plan más óptimo, ya que encontrar la estrategia óptima puede consumir mucho tiempo. Solo escoge una estrategia razonablemente eficiente.

43 Técnicas de Las técnicas para optimizar consultas son dos: basada en reglas heurísticas, que permiten ordenar las operaciones de la consulta en un árbol o grafo. basada en costos, que estiman el costo sistemáticamente, y eligen la de más bajo costo.

44 heurística de árboles de consulta La principal regla heurística es aplicar las operaciones de restricción y proyección antes de aplicar la reunión u otras operaciones binarias. Esto es porque el tamaño del archivo resultante de una operación binaria es una función de los tamaños de los archivos de entrada (en algunos casos función multiplicativa). Un árbol de consulta es una estructura de árbol que corresponde a una expresión del álgebra relacional por el hecho de que representa las relaciones de entrada como nodos hoja del árbol y las operaciones del álgebra relacional como nodos internos.

45 Ejemplo Obtener para cada proyecto ubicado en santiago, su número, el número del departamento que lo controla, el apellido, la dirección y la fecha de nacimiento del gerente de ese departamento. SELECT numerop,numd,apellido,direccion,fechan FROM proyecto,departamento,empleado WHERE numd=numerod AND nssgte=nss AND lugarp= santiago

46 Arbol Canónico (1) En general, existen muchos árboles de consulta que representan una sola consulta. De modo que el analizador sintáctico de consultas, casi siempre genera un árbol de consulta canónico estándar que corresponde a una consulta en SQL, sin efectuar optimización

47 Arbol Canónico (2) Numerop,numd,apellido,direccion,fechan Selection Numd=numerod AND nssgte=nss AND lugarp= santiago Producto Cartesiano X X DEPARTAMENTO PROYECTO EMPLEADO

48 Arbol Canónico (3) El árbol canónico se construye aplicando primero el producto cartesiano de las relaciones especificadas en la cláusula FROM, luego las condiciones de selección y reunión de la cláusula WHERE, seguidas de la proyección sobre los atributos de la cláusula SELECT.

49 Arbol Canónico (4) Este árbol es muy ineficiente, debido al producto cartesiano. Por ejemplo, si las relaciones PROYECTO, DEPARTAMENTO, EMPLEADO tienen 100, 50 y 150 bytes, y contuvieran 100, 20 y 5000 tuplas, respectivamente, el resultado del producto cartesiano contendría 10 millones de tuplas con un tamaño de registro de 300 bytes. Así, el optimizador transformará este árbol de consulta inicial a un árbol de consulta final cuya ejecución sea eficiente. Al hacer esta conversión, se deben ocupar reglas de transformación que vayan conservando las equivalencias.

50 Ejemplo Numerop,numd,apellido,direccion,fechan (3) join nssgte=nss Las 3 relaciones PROYECTO, DEPARTAMENTO, EMPLEADO se representan con nodos hoja, y las operaciones del álgebra relacional con nodos internos. (2) join numd=numerod (1) lugarp= santiago DEPARTAMENTO EMPLEADO PROYECTO Cuando se ejecuta el árbol de consulta, se ejecuta primero el nodo (1), ya que el resultado de (1) debe estar disponible para ejecutar (2).

51 Reglas de Transformaciones (1) cascada de restricciones (σ): una condición de selección conjuntiva puede descomponerse en una secuencia de operaciones σ individuales. σ c1andc 2AND...ANDc n (R) σc 1 (σc 2 (...(σc n (R))...)) conmutatividad de σ : σc 1 (σc 2 (R)) σc 2 (σc 1 (R)) cascada de π: En una secuencia de operaciones π, podemos ignorar todas menos la ltima: π lista1 (π lista2 (...(π listan (R))...)) π lista1 (R)

52 Reglas de Transformaciones (2) conmutación de σ con π: si en la condición de selección C intervienen sólo los atributos A 1,..., A n de la lista de proyección, se pueden conmuta ambas operaciones: πa 1, A 2,..., A n (σ c (R)) σ c (π A1,A 2,...,A n (R)) conmutatividad de join: R S S R conmutación de σ con join: si todos los atributos de la condición de seleccin C pertenecen a sólo una de las relaciones por reunir, digamos R, las dos operaciones pueden conmutarse. σ c (R S) (σ c (R)) S

53 Resumen La principal heurística de la optimización algebraica consiste en aplicar primero las operaciones que reducen el tamaño de los resultados intermedios. En esto entra la ejecución de las operaciones seleccionar tan pronto como sea posible para reducir el número de tuplas y la ejecución de las operaciones proyectar tan pronto como sea posible para reducir el número de atributos. Esto se logra desplazando las operaciones seleccionar y proyectar lo más abajo que se pueda en el árbol. Además se deben ejecutar las operaciones seleccionar y reunión más restrictivas (las que producen relaciones con el menor número de tuplas o el tamaño absoluto más pequeño) antes que otras operaciones similares.