Introducción a Evaluación y Optimización de Consultas

Introducción a Evaluación y Optimización de Consultas Adaptado de Database Management Systems 3ed, Ch.12, R. Ramakrishnan and J. Gehrke 1 Cuál es el propósito?! Obtener un buen plan de ejecución (Minimizar costo). Consulta SQL Árbol de la Expresión Álgebra Relacional Índices Carácterísticas de las Tablas Plan de Ejecución Adaptado de Database Management Systems 3ed, Ch.12, R. Ramakrishnan and J. Gehrke 2

Evaluación de Consultas! Plan de Ejecución: Árbol de operadores de Álgebra Relacional, para cada opertador se ha seleccionado un algoritmo de implementación.! Hay dos aspectos fundamentales en optimización de consultas: " Para una consulta dada Qué planes son considerados? Algoritmo para buscar en el espacio de planes el más barato (estimado). " Como se estima el costo de un plan?! Idealmente: Encontrar el mejor plan. En la práctica: Evitar los peores planes. Adaptado de Database Management Systems 3ed, Ch.12, R. Ramakrishnan and J. Gehrke 3 Por ejemplo SELECT S.sname FROM Reserves R, Sailors S WHERE R.sid=S.sid AND R.bid=100 AND S.rating>5 sname sname (On-the-fly) bid=100 rating > 5 rating > 5 (On-the-fly) Reserves sid=sid Sailors (Use hash index; do not write result to temp) sid=sid bid=100 Reserves with pipelining ) Sailors Adaptado de Database Management Systems 3ed, Ch.12, R. Ramakrishnan and J. Gehrke 4

Algunas técnicas comunes! Los algoritmos para evaluar operadores relacionales usan las siguientes ideas: " Indexado: Se pueden usar las condiciones de WHERE para obtener conjuntos pequeños de tuplas (selecciones, reuniones) " Iteración: En algunos casos, es más rápido recorrer todas las tuplas aún si existe un índice. (También, podríamos recorrer el índice mismo en lugar de la tabla) " Particionado: Al usar ordenamiento o hashing, podemos particionar las tuplas de entrada y reemplazar una operación cara por operaciones similares sobre entradas más pequeñas. Adaptado de Database Management Systems 3ed, Ch.12, R. Ramakrishnan and J. Gehrke 5 Catálogo y Estadísticas! Se necesita información acerca de las relaciones y los índices involucrados. Usualmente el catálogo contiene al menos: " # tuplas (NTuplas) y # pags (NPags) para cada relación. " # valores distintos de clave (NKeys) y NPags para cada índice. " Altura, y valores de clave menor/mayor (Low/High) para cada índice de árbol.! El catálogo es actualizado periódicamente. " Actualizarlo cada vez que los datos cambian es demasiado caro; muchas decisiones aproximadas, así que es tolerable algo de inconsistencia.! Algunos SABDs almacenan información más detallada, por ejemplo: histogramas de los valores de un campo. Adaptado de Database Management Systems 3ed, Ch.12, R. Ramakrishnan and J. Gehrke 6

Rutas de Acceso! Una ruta de acceso es un método para recuperar tuplas: " Recorrido (rastreo) de archivo, o un índice que coincide (matches) con una selección (en la consulta).! Un índice de árbol coincide con una conjunción de términos que involucran sólo atributos en un prefijo de la clave de búsqueda del índice. " E.g., índice de árbol sobre <a, b, c> coincide con la selección a=5 AND b=3, y a=5 AND b>6, pero no b=3.! Un índice de hash coincide con una conjunción de términos que tienen un término atributo = valor para cada atributo en la clave de búsqueda del índice. " E.g., índice hash sobre <a, b, c> coincide con a=5 AND b=3 AND c=5; pero no con b=3, o a=5 AND b=3, o a>5 AND b=3 AND c=5.! Se prefieren las rutas de acceso más selectivas (índices). Adaptado de Database Management Systems 3ed, Ch.12, R. Ramakrishnan and J. Gehrke 7 Esquema para los ejemplos Sailors (sid: integer, sname: string, rating: integer, age: real) Reserves (sid: integer, bid: integer, day: dates, rname: string)! Reserves: " Cada tupla es de 40 bytes de largo, 100 tuplas por página, 1000 páginas.! Sailors: " Cada tupla es de 50 bytes de largo, 80 tuplas por página, 500 páginas. Adaptado de Database Management Systems 3ed, Ch.12, R. Ramakrishnan and J. Gehrke 8

Para selecciones! Encuentre la ruta de acceso más selectiva, obtenga con ella las tuplas, finalmente aplique los términos restantes (que no coinciden con el índice): " Ruta de acceso más selectiva: Un rastreo de índice o archivo que, estimamos, requerirá la menor cantidad de I/Os de página. " Los términos que coinciden con este índice reducen el número de tuplas recuperadas; los demás términos se usan para descartar algunas de ellas, pero no afectan el número de tuplas/páginas buscadas. " Considere day<8/9/94 AND bid=5 AND sid=3. Se puede usar un índice de árbol B+ sobre day; luego, bid=5 y sid=3 deben probarse para cada tupla recuperda. Alternativamente, un índice de hash sobre <bid, sid> podría ser usado; el término day<8/9/94 debe ser probado luego. Adaptado de Database Management Systems 3ed, Ch.12, R. Ramakrishnan and J. Gehrke 9 Selecciones: usando índices! El costo depende del número de tuplas que califican y del agrupamiento. " Costo de encontrar las entradas de datos que califican (típicamente pequeño) más costo de recuperar los registros (sin agrupamiento puede ser grande). " En el ejemplo, asumiendo una distribución uniforme de nombres, ~ 10% de tuplas que califican (100 páginas, 10000 tuplas). Con un índice agrupado, el costo es un poco más de 100 I/Os; si está desagrupado, hasta 10000 I/Os! SELECT * FROM Reserves R WHERE R.rname < C% Adaptado de Database Management Systems 3ed, Ch.12, R. Ramakrishnan and J. Gehrke 10

Proyección SELECT DISTINCT FROM R.sid, R.bid Reserves R! La parte costosa es eliminar duplicados. " Los sistemas que usan SQL no eliminan los duplicados a menos que se incluya la palabra reservada DISTINCT en la consulta.! Estrategias alternativas " Ordenamiento: Ordenar por <sid, bid> y eliminar duplicados. (Se puede optimizar eliminando la información no deseada mientras se ordena) " Hashing: Hash sobre <sid, bid> para crear particiones. Cargar particiones en memoria, una por vez, construir una estructura de hash en memoria, y eliminar los duplicados.! Si hay un índice que incluya tanto R.sid como R.bid en la clave de búsqueda, podría ser más barato ordenar los datos. Adaptado de Database Management Systems 3ed, Ch.12, R. Ramakrishnan and J. Gehrke 11 Reunión: Ciclos Anidados con Indice foreach tuple r in R do foreach tuple s in S where ri == sj do add <r, s> to result! Si hay un índice en la columna de reunión para una relación S, se la puede tratar como interna y aprovechar el índice. " Costo: M + ( (M*p R ) * costo de encontrar las tuplas coincidentes de S) " M=#páginas de R, p R =# de tuplas de R por página! Por cada tupla de R, el costo de explorar el índice de S es: ~ 1.2 (hash), ~2-4 (B+ tree). El costo de encontrar las tuplas de S (suponiendo Alt. (2) o (3) para las entradas de datos) depende del agrupamiento. " Indice agrupado: 1 I/O (tipica), desagrupado: hasta 1 I/O por tupla que coincide. Adaptado de Database Management Systems 3ed, Ch.12, R. Ramakrishnan and J. Gehrke 12

Ejemplos! Indice Hash (Alt. 2) sobre Sailors.sid (como inner): " Recorrer Reserves: 1000 I/Os de páginas, 100*1000 tuplas. " Para cada tupla de Reserves: 1.2 I/Os para obtener la entrada de datos en el índice, más 1 I/O para obtener (exactamente una) tupla coincidente de Sailors. Total: 220,000 I/Os.! Indice Hash (Alt. 2) sobre Reserves.sid (como inner): " Recorrer Sailors: 500 I/Os de páginas, 80*500 tuplas. " Para cada tupla de Sailors: 1.2 I/Os para encontrar la página del índice con las entradas de datos, más el costo de obtener las tuplas coincidentes de Reserves. Suponindo una distribución uniforme, 2.5 reservaciones por marino (sailor) -> (100,000 / 40,000). El costo de recuperarlas es 1 o 2.5 I/Os dependiendo si el índice está agrupado. Adaptado de Database Management Systems 3ed, Ch.12, R. Ramakrishnan and J. Gehrke 13 Reunión: Sort-Merge (R >< S)! Ordenar R y S por la columna de reunión, luego recorrerlos para hacer una mezcla (merge) sobre la columna de reunión, y retornar las tuplas resultantes. " Avanzar el recorrido de R hasta que R-tupla_actual >= S-tupla, entonces avanzar el recorrido de S hasta que S-tupla_actual >= R- tupla_actual; hacerlo hasta que R-tupla = S-tupla_actual. " En este punto, todas las R-tuplas con el mismo valor en Ri (grupo actual en R) y todas las S-tuplas con el mismo valor en Sj (grupo actual en S) coinciden; retornar <r, s> para todos los pares de tales tuplas. " Coninuar con el recorrido de R y S.! R se recorre una vez; cada grupo de S es recorrido una vez para cada tupla coincidente de. (Los múltiples recorridos de un grupo de S probablemente encontrarán las páginas necesarias en el buffer.) Adaptado de Database Management Systems 3ed, Ch.12, R. Ramakrishnan and J. Gehrke 14 i=j

Ejemplo sid sname rating age 22 dustin 7 45.0 28 yuppy 9 35.0 31 lubber 8 55.5 44 guppy 5 35.0 58 rusty 10 35.0 sid bid day rname 28 103 12/4/96 guppy 28 103 11/3/96 yuppy 31 101 10/10/96 dustin 31 102 10/12/96 lubber 31 101 10/11/96 lubber 58 103 11/12/96 dustin! Costo: M log M + N log N + (M+N) " El costo de recorrer, M+N, podría ser M*N ( poco probable!)! Con 35, 100 o 300 páginas de buffer, ambas tablas, Reserves y Sailors, pueden ser ordenadas en 2 pasadas; costo total de la reunión: 7500. Adaptado de Database Management Systems 3ed, Ch.12, R. Ramakrishnan and J. Gehrke 15 Optimizador: System R! Impacto: " Actualmente el más usado; trabaja bien para < 10 reuniones.! Estimación de costos: Aproximada. " Se usan las estadísticas, mantenidas en el catálogo del sistema, para estimar los costos de las operaciones y el tamaño de los resultados. " Considera una combinación de costos de Cpu y E/S (I/O).! Espacio de planes: Muy grande, debe ser acotado. " Sólo se considera el espacio de los planes hacia la izquierda (leftdeep). Estos planes permiten que la salida de cada operador sea traspasada directamente (pipelined) al siguiente operador sin almacenarla en una relación temporal. " Se evitan los productos cartesianos. Adaptado de Database Management Systems 3ed, Ch.12, R. Ramakrishnan and J. Gehrke 16

Estimación de Costo! Para cada plan considerado se debe estimar el costo: " Se debe estimar el costo para cada operación en el árbol del plan. Depende de la cardinalidad de las entradas. El costo de cada operación se estima según lo presentado antes (recorrido secuencial, recorrido por índice, reunión, etc.) " También se debe estimar el tamaño del resultado para cada operación en el árbol. Usando la información acerca de las relaciones de entrada. Para las selecciones y reuniones se asume in dependencia de los predicados. Adaptado de Database Management Systems 3ed, Ch.12, R. Ramakrishnan and J. Gehrke 17 Estimación de tamaño y Factores de reducción SELECT attribute list FROM relation list! Considere la consulta: WHERE term1 AND... AND termk! El número máximo de tuplas en el resultado es el producto de las cardinalidades de las relaciones enumeradas en la cláusula FROM.! El factor de reducción (Reduction factor - RF) asociado con cada término refleja el impacto del término en reducir el tamaño del resultado.! Cardinalidad del Resultado = Max # tuplas * producto de todos los RF s. " Supuesto implícito: los términos son independientes! " Término col=valor tiene un RF de 1/NKeys(I), dado un índice I sobre col " Término col1=col2 tiene un RF 1/MAX(NKeys(I1), NKeys(I2)) " Término col>valor tiene un RF (High(I)-valor)/(High(I)-Low(I)) Adaptado de Database Management Systems 3ed, Ch.12, R. Ramakrishnan and J. Gehrke 18

Ejemplo SELECT S.sname FROM Reserves R, Sailors S WHERE R.sid=S.sid AND R.bid=100 AND S.rating>5! Costo: 500+500*1000 I/Os! Y no es el peor plan posible! Plan:! Pierde varias oportunidades: Las selecciones podrían haber sido hechas antes, no se usa ningún índice, etc.! Meta de la optimización: Encontrar planes más eficientes que calculen la misma respuesta. RA Tree: bid=100 rating > 5 Reserves sname bid=100 rating > 5 sid=sid sname sid=sid Sailors (On-the-fly) (On-the-fly) (Simple Nested Loops) Reserves Sailors Adaptado de Database Management Systems 3ed, Ch.12, R. Ramakrishnan and J. Gehrke 19 Plan alternativo 1 (Sin Indices)! Principal diferencia: posición de los selects (push selects).! Con 5 buffers, costo del plan: " Recorrer Reserves (1000) + escribir temp T1 (10 pags, si tenemos 100 boats con distribución uniforme). " Recorrer Sailors (500) + escribir temp T2 (250 pags, si tenemos 10 ratings). " Ordenar T1 (2*2*10), ordenar T2 (2*3*250), mezclar (10+250) " Total: 3560 pags I/Os. (Scan; write to temp T1)! Si usamos reunión BNL (Block Nested Loop), la reunión cuesta = 10+4*250, costo total = 2770.! Si se empujan las projecciones, T1 sólo tiene sid, T2 sólo sid y sname: " T1 cabe en 3 páginas, el costo de BNL cae bajo las 250 pags, total < 2000. bid=100 Reserves sname (On-the-fly) (Sort-Merge Join) sid=sid (Scan; rating > 5write to temp T2) Sailors Adaptado de Database Management Systems 3ed, Ch.12, R. Ramakrishnan and J. Gehrke 20

Plan alternativo 2 (con índices)! Con un índice agrupado sobre Reserves.bid, obtenemos 100,000/100 = 1000 tuplas sobre 1000/100 = 10 páginas.! INL con pipelining (outer is not materialized). Proyectar campos innecesarios desde outer no ayuda.! La columna de reunión sid es una clave de Sailors. A lo más una tupla coincidente, un índice no agrupado sobre sid esta OK.! La decisión de no empujar rating>5 antes de la reunión se basa en la existencia de un índice sobre Sailors.sid.! Costo: Selección de las tuplas de Reserves (10 I/Os); para cada una se debe obtener la tupla coincidente de Sailors (1000*1.2); total 1210 I/Os. (Use hash index; do bid=100 not write result to temp) Reserves sname rating > 5 (On-the-fly) (Index Nested Loops, sid=sid with pipelining ) Sailors (On-the-fly) Adaptado de Database Management Systems 3ed, Ch.12, R. Ramakrishnan and J. Gehrke 21 Resumen! Hay varios algoritmos alternativos de evaluación para cada operador relacional.! Una consulta es evaluada convirtiéndola a un árbol de operadores y evaluando los operadores en el árbol.! Se debe entender la optimización de consultas para comprender a cabalidad el impacto en el rendimiento de un diseño de base de datos (relaciones e índices) sobre cierta carga de trabajo (conjunto de consultas).! La optimización de una consulta tiene dos partes: " Considerar el conjutno de planes alternativos. Se debe podar el espacio de búsqueda; típicamente se consideran solo los planes left-deep. " Se debe estimar el costo de cada plan considerado. Se debe estimar el tamaño del resultado y el costo para cada nodo del plan. Aspectos clave: Estadísticas, índices, implementación de operadores. Adaptado de Database Management Systems 3ed, Ch.12, R. Ramakrishnan and J. Gehrke 22