View
0
Download
0
Category
Preview:
Citation preview
Adaptado de Database Management Systems 3ed, Ch.12, R. Ramakrishnan and J. Gehrke 1
Introducción a Evaluación yOptimización de Consultas
Adaptado de Database Management Systems 3ed, Ch.12, R. Ramakrishnan and J. Gehrke 2
¿Cuál es el propósito…?
ConsultaSQL
Plan deEjecución
ÁlgebraRelacional
Índices
Carácterísticasde las Tablas
! Obtener un “buen” plan de ejecución(Minimizar costo).
Árbol dela
Expresión
Adaptado de Database Management Systems 3ed, Ch.12, R. Ramakrishnan and J. Gehrke 3
Evaluación de Consultas
! Plan de Ejecución: Árbol de operadores de ÁlgebraRelacional, para cada opertador se ha seleccionado unalgoritmo de implementación.
! Hay dos aspectos fundamentales en optimizaciónde 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 4
Por ejemploSELECT S.snameFROM Reserves R, Sailors SWHERE R.sid=S.sid AND R.bid=100 AND S.rating>5
Reserves Sailors
sid=sid
bid=100 rating > 5
sname
Reserves
Sailors
sid=sid
bid=100
sname(On-the-fly)
rating > 5
(Use hashindex; donot writeresult to temp)
with pipelining )
(On-the-fly)
Adaptado de Database Management Systems 3ed, Ch.12, R. Ramakrishnan and J. Gehrke 5
Algunas técnicas comunes
! Los algoritmos para evaluar operadoresrelacionales 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 recorrertodas las tuplas aún si existe un índice. (También,podríamos recorrer el índice mismo en lugar de latabla)
" Particionado: Al usar ordenamiento o hashing,podemos particionar las tuplas de entrada yreemplazar una operación cara por operacionessimilares sobre entradas más pequeñas.
Adaptado de Database Management Systems 3ed, Ch.12, R. Ramakrishnan and J. Gehrke 6
Catálogo y Estadísticas
! Se necesita información acerca de las relaciones y losíndices involucrados. Usualmente el catálogo contieneal 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 deinconsistencia.
! 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 7
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 detérminos que involucran sólo atributos en un prefijo de laclave 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 detérminos que tienen un término atributo = valor para cadaatributo 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 8
Esquema para los ejemplos
! Reserves:
" Cada tupla es de 40 bytes de largo, 100 tuplaspor página, 1000 páginas.
! Sailors:
" Cada tupla es de 50 bytes de largo, 80 tuplas porpágina, 500 páginas.
Sailors (sid: integer, sname: string, rating: integer, age: real)Reserves (sid: integer, bid: integer, day: dates, rname: string)
Adaptado de Database Management Systems 3ed, Ch.12, R. Ramakrishnan and J. Gehrke 9
Para selecciones…
! Encuentre la ruta de acceso más selectiva, obtenga con ella lastuplas, finalmente aplique los términos restantes (que nocoinciden 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 detuplas recuperadas; los demás términos se usan para descartar algunasde 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 índicede árbol B+ sobre day; luego, bid=5 y sid=3 deben probarse para cadatupla 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 10
Selecciones: usando índices
! El costo depende del número de tuplas quecalifican y del agrupamiento.
" Costo de encontrar las entradas de datos que califican(típicamente pequeño) más costo de recuperar losregistros (sin agrupamiento puede ser grande).
" En el ejemplo, asumiendo una distribución uniforme denombres, ~ 10% de tuplas que califican (100 páginas,10000 tuplas). Con un índice agrupado, el costo es unpoco más de 100 I/Os; si está desagrupado, hasta 10000I/Os!
SELECT *FROM Reserves RWHERE R.rname < ‘C%’
Adaptado de Database Management Systems 3ed, Ch.12, R. Ramakrishnan and J. Gehrke 11
Proyección! La parte costosa es eliminar duplicados.
" Los sistemas que usan SQL no eliminan los duplicados amenos que se incluya la palabra reservada DISTINCT en laconsulta.
! Estrategias alternativas" Ordenamiento: Ordenar por <sid, bid> y eliminar
duplicados. (Se puede optimizar eliminando la informaciónno deseada mientras se ordena)
" Hashing: Hash sobre <sid, bid> para crear particiones.Cargar particiones en memoria, una por vez, construir unaestructura de hash en memoria, y eliminar los duplicados.
! Si hay un índice que incluya tanto R.sid como R.biden la clave de búsqueda, podría ser más baratoordenar los datos.
SELECT DISTINCT
R.sid, R.bidFROM Reserves R
Adaptado de Database Management Systems 3ed, Ch.12, R. Ramakrishnan and J. Gehrke 12
Reunión: Ciclos Anidados con Indice
! Si hay un índice en la columna de reunión para unarelación S, se la puede tratar como interna yaprovechar el índice." Costo: M + ( (M*pR) * costo de encontrar las tuplas
coincidentes de S)
" M=#páginas de R, pR=# de tuplas de R por página
! Por cada tupla de R, el costo de explorar el índice de Ses: ~ 1.2 (hash), ~2-4 (B+ tree). El costo de encontrar lastuplas de S (suponiendo Alt. (2) o (3) para las entradasde datos) depende del agrupamiento." Indice agrupado: 1 I/O (tipica), desagrupado: hasta 1 I/O por
tupla que coincide.
foreach tuple r in R doforeach tuple s in S where ri == sj do
add <r, s> to result
Adaptado de Database Management Systems 3ed, Ch.12, R. Ramakrishnan and J. Gehrke 13
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 entradade datos en el índice, más 1 I/O para obtener (exactamenteuna) 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áginadel índice con las entradas de datos, más el costo de obtenerlas tuplas coincidentes de Reserves. Suponindo unadistribución uniforme, 2.5 reservaciones por marino (sailor) ->(100,000 / 40,000). El costo de recuperarlas es 1 o 2.5 I/Osdependiendo si el índice está agrupado.
Adaptado de Database Management Systems 3ed, Ch.12, R. Ramakrishnan and J. Gehrke 14
Reunión: Sort-Merge (R S)
! Ordenar R y S por la columna de reunión, luegorecorrerlos para hacer una “mezcla” (merge) sobre lacolumna 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 (grupoactual en R) y todas las S-tuplas con el mismo valor en Sj (grupoactual en S) coinciden; retornar <r, s> para todos los pares de talestuplas.
" Coninuar con el recorrido de R y S.
! R se recorre una vez; cada grupo de S es recorrido una vezpara cada tupla coincidente de . (Los múltiples recorridosde un grupo de S probablemente encontrarán las páginasnecesarias en el buffer.)
><i=j
Adaptado de Database Management Systems 3ed, Ch.12, R. Ramakrishnan and J. Gehrke 15
Ejemplo
! 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 ySailors, pueden ser ordenadas en 2 pasadas; costo total de lareunión: 7500.
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
Adaptado de Database Management Systems 3ed, Ch.12, R. Ramakrishnan and J. Gehrke 16
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 losresultados.
" 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” (left-
deep).• Estos planes permiten que la salida de cada operador sea traspasada
directamente (pipelined) al siguiente operador sin almacenarla enuna relación temporal.
" Se evitan los productos cartesianos.
Adaptado de Database Management Systems 3ed, Ch.12, R. Ramakrishnan and J. Gehrke 17
Estimación de Costo
! Para cada plan considerado se debe estimar elcosto:" 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 presentadoantes (recorrido secuencial, recorrido por índice, reunión,etc.)
" También se debe estimar el tamaño del resultado paracada operación en el árbol.
• Usando la información acerca de las relaciones de entrada.
• Para las selecciones y reuniones se asume in dependenciade los predicados.
Adaptado de Database Management Systems 3ed, Ch.12, R. Ramakrishnan and J. Gehrke 18
Estimación de tamaño yFactores de reducción
! Considere la consulta:
! El número máximo de tuplas en el resultado es el productode las cardinalidades de las relaciones enumeradas en lacláusula FROM.
! El factor de reducción (Reduction factor - RF) asociado con cadatérmino refleja el impacto del término en reducir el tamaño delresultado.
! 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))
SELECT attribute listFROM relation listWHERE term1 AND ... AND termk
Adaptado de Database Management Systems 3ed, Ch.12, R. Ramakrishnan and J. Gehrke 19
Ejemplo
! Costo: 500+500*1000 I/Os
! ¡Y no es el peor plan posible!
! Pierde varias oportunidades: Lasselecciones podrían haber sidohechas antes, no se usa ningúníndice, etc.
! Meta de la optimización: Encontrarplanes más eficientes quecalculen la misma respuesta.
SELECT S.snameFROM Reserves R, Sailors SWHERE R.sid=S.sid AND R.bid=100 AND S.rating>5
Reserves Sailors
sid=sid
bid=100 rating > 5
sname
Reserves Sailors
sid=sid
bid=100 rating > 5
sname
(Simple Nested Loops)
(On-the-fly)
(On-the-fly)
RA Tree:
Plan:
Adaptado de Database Management Systems 3ed, Ch.12, R. Ramakrishnan and J. Gehrke 20
Plan alternativo 1 (Sin Indices)
! Principal diferencia: posición de los selects (pushselects).
! Con 5 buffers, costo del plan:" Recorrer Reserves (1000) + escribir temp T1 (10
pags, si tenemos 100 boats con distribuciónuniforme).
" Recorrer Sailors (500) + escribir temp T2 (250pags, si tenemos 10 ratings).
" Ordenar T1 (2*2*10), ordenar T2 (2*3*250),mezclar (10+250)
" Total: 3560 pags I/Os.
! 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 tienesid, T2 sólo sid y sname:" T1 cabe en 3 páginas, el costo de BNL cae bajo
las 250 pags, total < 2000.
Reserves Sailors
sid=sid
bid=100
sname(On-the-fly)
rating > 5(Scan;write to temp T1)
(Scan;write totemp T2)
(Sort-Merge Join)
Adaptado de Database Management Systems 3ed, Ch.12, R. Ramakrishnan and J. Gehrke 21
Plan alternativo 2 (con índices)! Con un índice agrupado sobre Reserves.bid,
obtenemos 100,000/100 = 1000 tuplas sobre1000/100 = 10 páginas.
! INL con pipelining (outer is notmaterialized).
– Proyectar campos innecesarios desde outer noayuda.
! La columna de reunión sid es una clave deSailors.
– A lo más una tupla coincidente, un índice noagrupado sobre sid esta OK.
! La decisión de no empujar rating>5 antes dela 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 latupla coincidente de Sailors (1000*1.2); total1210 I/Os.
(Use hash
(Index Nested Loops,
Reserves
Sailors
sid=sid
bid=100
sname(On-the-fly)
rating > 5
index; donot writeresult to temp)
with pipelining )
(On-the-fly)
Adaptado de Database Management Systems 3ed, Ch.12, R. Ramakrishnan and J. Gehrke 22
Resumen! Hay varios algoritmos alternativos de evaluación para
cada operador relacional.
! Una consulta es evaluada convirtiéndola a un árbol deoperadores y evaluando los operadores en el árbol.
! Se debe entender la optimización de consultas paracomprender a cabalidad el impacto en el rendimiento deun diseño de base de datos (relaciones e índices) sobrecierta 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 consideransolo 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.
Recommended