ÀCu l es el prop sitoÉ? Introducci n a Evaluaci n y ...

Adaptado de Database Management Systems 3ed, Ch.12, R. Ramakrishnan and J. Gehrke 1

Introducción a Evaluación yOptimización de Consultas


¿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


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.


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)


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.


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.


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).


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)


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.


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%’


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


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


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.


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


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


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.


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.


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


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:


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)


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)


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.

ÀCu l es el prop sitoÉ? Introducci n a Evaluaci n y ...

Documents

Transcript of ÀCu l es el prop sitoÉ? Introducci n a Evaluaci n y ...