Introducción a Evaluación y Optimización de Consultas ¿Cuál es el

Transcripción

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).
Índices
Consulta
SQL
Árbol de
la
Expresión
Carácterísticas
de las Tablas
Plan de
Ejecución
Álgebra
Relacional
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.
Por ejemplo
SELECT S.sname
FROM Reserves R, Sailors S
WHERE R.sid=S.sid AND
R.bid=100 AND S.rating>5
sname
bid=100
3
sname
(On-the-fly)
rating > 5 (On-the-fly)
rating > 5
sid=sid
with pipelining )
sid=sid
Reserves
Sailors
(Use hash
index; do
not write
result to
temp)
bid=100
Sailors
Reserves
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.
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:
"
"
"
!
El catálogo es actualizado periódicamente.
"
!
# 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.
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.
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.
"
!
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 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.
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).
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.
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.
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%’
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.
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*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 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.
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.
13
Reunión: Sort-Merge (R >i=j<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 >= Rtupla_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.)
14
Ejemplo
sid
22
28
31
44
58
!
bid
103
103
101
102
101
103
day
12/4/96
11/3/96
10/10/96
10/12/96
10/11/96
11/12/96
rname
guppy
yuppy
dustin
lubber
lubber
dustin
Costo: M log M + N log N + (M+N)
"
!
sname rating age
dustin
7
45.0
yuppy
9
35.0
lubber
8
55.5
guppy
5
35.0
rusty
10 35.0
sid
28
28
31
31
31
58
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.
15
Optimizador: System R
!
Impacto:
"
!
Estimación de costos: Aproximada.
"
"
!
Actualmente el más usado; trabaja bien para < 10 reuniones.
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.
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.
17
Estimación de tamaño y
Factores de reducción
!
!
!
!
SELECT attribute list
FROM relation list
WHERE term1 AND ... AND
Considere la consulta:
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))
18
RA Tree:
Ejemplo
SELECT S.sname
FROM Reserves R, Sailors S
WHERE R.sid=S.sid AND
R.bid=100 AND S.rating>5
!
!
!
!
sname
rating > 5
bid=100
sid=sid
Sailors
Reserves
Costo: 500+500*1000 I/Os
(On-the-fly)
¡Y no es el peor plan posible! Plan: sname
Pierde varias oportunidades: Las
selecciones podrían haber sido
rating > 5
(On-the-fly)
bid=100
hechas antes, no se usa ningún
índice, etc.
(Simple Nested Loops)
Meta de la optimización: Encontrar
sid=sid
planes más eficientes que
calculen la misma respuesta.
Sailors
Reserves
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)
(Scan;
write to
Total: 3560 pags I/Os.
temp T1)
(On-the-fly)
sname
(Sort-Merge Join)
sid=sid
bid=100
Si usamos reunión BNL (Block Nested Loop),
Reserves
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:
"
(Scan;
to
temp T2)
rating > 5write
Sailors
T1 cabe en 3 páginas, el costo de BNL cae bajo
las 250 pags, total < 2000.
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).
sname
rating > 5
– 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.
(On-the-fly)
sid=sid
(Use hash
index; do
not write
result to
temp)
bid=100
(On-the-fly)
(Index Nested Loops,
with pipelining )
Sailors
Reserves
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.
22

Introducción a Evaluación y Optimización de Consultas ¿Cuál es el

Transcripción

Documentos relacionados

icacls - smrcanadas

Garantía del Consumidor

CARMEN GARCÍA PUBLICA NUEVO DISCO EN SOLITARIO