procesamiento de consultas
Post on 08-Aug-2015
217 Views
Preview:
TRANSCRIPT
Administración de Base de Datos
Procesamiento de Consultas
Ing. Ronald Pérezrrperez@unimet.edu.ve
rperez@shopepk.com
Agenda
Objetivo
Arquitectura de un motor de base de datos
Componentes
Panorámica procesamiento de consultas
Algebra relacional
Reglas de equivalencia
Procesamiento de consultas
Optimización de consultas.
Expresiones equivalentes
Fase de optimización
Comparación de enfoques
Información de catálogo
¿Cómo se construye un plan?
Técnicas algebraicas
Técnicas físicas
Ejercicio
Objetivo
Disminuir el tiempo de ejecución de las consultas
realizadas frecuentemente en una base de datos.
¿Cuál es el camino de acceso a los datos?
Modificar el diseño físico
o Añadir redundancia y modificar la organización
o Reorganizar las estructuras para mantener las
características a pesar de borrados y actualizaciones.
Arquitectura de un motor de base de datos
Componentes
Disk Manager
Capa de más bajo nivel de la BD
Maneja el espacio en disco
Oculta los detalles de cómo se guardan las tablas
en hardware
Provee una abstracción a capas superiores,
haciendo que las tablas se vean como una colección de
páginas
Componentes
Buffer Manager
Responsable de traer las páginas del disco a la
memoria.
Capa que administra un espacio de memoria de la
BD.
Divide a la memoria en páginas de igual tamaño
(formando uno o varios pooles de memoria).
Capas superiores pueden usar las páginas sin
preocuparse si están en disco o memoria, de eso se
encargará este componente.
Componentes
Query Evaluation Engine
Recibe comandos SQL.
Al recibir una consulta, el Parser la interpreta y la
pasa al Query Optimizer.
El Query Optimizer busca un plan de ejecución
eficiente.
El plan generado es finalmente ejecutado por el
Query Executor.
Componentes
Transaction Manager
Controla la ejecución de las transacciones.
Lock Manager
Mantiene registro de los locks sobre los objetos de la
BD.
Recovery Manager
Mantiene un log sobre los cambios en la BD.
Se encarga de restaurar la BD a un estado
consistente en caso de una caída.
Panorámica del procesamiento de consultas
Los lenguajes de consultas relacionales (como el SQL) nos
dan una interfaz declarativa de alto nivel para acceder a
los datos almacenados en una base de datos.
El procesamiento de consultas se refiere al conjunto de
actividades que realiza un motor de base de datos para
la extracción de datos de la base de datos a partir de
una sentencia en un lenguaje de consulta.
Panorámica del procesamiento de consultas
Procesamiento de consultas: las actividades implicadas
en el análisis sintáctico, la validación, la optimización y la
ejecución de consultas.
Optimización de consultas: la actividad de seleccionar una
estrategia de ejecución eficiente para el procesamiento
de la consulta.
Panorámica del procesamiento de consultas
Ejemplo hallar todos los gerentes que trabajen en la sucursal
de Londres:
SQL: SELECT * FROM Staff s, Branch b
WHERE s.branchNo = b.branchNo AND
(s.position= ‘Manager’ AND b.city =‘’London)
Suponer que hay:
1000 tuplas en Staff
50 tuplas en Brach
50 empleados con categoría Maneger
5 sucursales en Londres
Panorámica del procesamiento de consultas
Los pasos básicos son:
1. Parsing y traducción
2. Optimización
3. Generación de código
4. Ejecución de la consulta
Estos pasos en general son realizados por diferentes
componentes del motor. Los componentes clave son: el
optimizador de consultas y el procesador de consultas.
Algebra relacional
Definición
Conjunto cerrado de operaciones
Actúan sobre las relaciones
Producen relaciones como resultados
Pueden combinarse para construir expresiones
más complejas
Operadores Básicos
•Unión
•Diferencia
•Producto cartesiano
•Selección
•Proyección
Son operacionalmente
completos permiten expresar
cualquier consulta a una BDR
Operadores Derivados
•Intersección
•Join
•División
•Asociación
oNo añaden nada nuevo
oSe forman combinando los
operadores básicos.
oSon útiles en determinadas
consultas
Reglas de equivalencia
1. Las operaciones de selección conjuntivas pueden dividirse
en una secuencia de selecciones individuales.
Cascada de selecciones.
2. Las operaciones de selección son conmutativas.
Conmutación de selecciones.
3. Sólo son necesarias las últimas operaciones de una
secuencia de operaciones de proyección, las demás pueden
omitirse.
Cascada de proyecciones
))(()(2121
EE
))(())((1221
EE
121
)()))...)((...((LL LL
EEn
Reglas de equivalencia
4. Las selecciones pueden combinarse con los productos
cartesianos y con las reuniones.
5. las operaciones de reunión son conmutativas
6. (a) Las operaciones de reunión natural son asociativas:
(b) Las reuniones son asociativas en sentido siguiente:
2121
2121
2121)( .
)(.
EEEEb
EEEEa
1221 EEEE
)()( 321321 EEEEEE
32 2
321321
Ey E de atributos solo
)()(231321
implicadonde
EEEEEE
Reglas de equivalencia
7. Las operaciones de selección se distribuyen por la
operación reunión bajo las dos condiciones siguientes:
(a) Cuando los atributos de la condición de selección implican
únicamente los atributos de una de las expresiones (por
ejemplo E) que se están uniendo.
(b) Cuando θ1 implica únicamente los atributos de E1 y θ2
Implican los atributos de E2
2121 ))(()(00
EEEE
))(())(()( 2121 2121EEEE
0
Reglas de equivalencia
9. Las operaciones de unión e intersección son conmutativas
La diferencia de conjuntos no es conmutativa.
10. La unión e intersección de conjuntos son asociativas.
11. La operación selección se distribuye por las operaciones
de unión, intersección y diferencia de conjuntos
12. La operación de proyección es distributiva con respecto
a la operación unión:
1221
1221
EEEE
EEEE
)()(
)()(
321321
321321
EEEEEE
EEEEEE
para no pero paray también -)(E)E-(E
y parasimilar manera dey )(E-)(E)E-(E
2121
2121
E
))((())((()( 2121 EEEE LLL
Procesamiento de consultas
Dada una consulta, encontrar un plan de ejecución eficiente.
Un plan de ejecución define cómo se resolverá una consulta
dada, indicando paso a paso los algoritmos y estructuras que
se usarán para resolverla.
Tiempo búsqueda plan eficiente = 1 seg Tiempo
de ejecución plan = 1 seg
Tiempo búsqueda mejor plan = 10 min
Tiempo de ejecución plan = 1 ms
Query
Tiempo total = 10 min (aprox)
Tiempo total = 2 seg
Analizar todo el espacio de búsqueda puede ser prohibitivamente costoso, por lo que se utilizan
diferentes técnicas para evitar analizarlo completo, pero obteniendo planes eficientes.
Optimización de consultas.
El coste de una consulta se puede expresar:
o El tiempo de acceso a almacenamiento secundario.
o El tiempo de CPU para ejecutar la consulta.
o El tiempo de comunicación (BD distribuidas).
El tiempo de acceso dependerá:
o Del volumen de datos sobre el cuál debe actuar
(número y tamaño de las tuplas)
o De la organización física (existencia de índices,
agrupamientos, etc.)
o De su localización (memoria principal o dispositivo
externo).
o Del tamaño del buffer de memoria principal que se
dedica a almacenar las tuplas mientras se ejecutan los
operaciones sobre ellas.
Expresiones equivalentes
Los optimizadores de consultas usan las reglas de
equivalencia para generar de manera sistemática
expresiones equivalentes a la expresión de consulta dada.
El proceso es:
o Para cada sub-expresión que coincide con la parte
derecha o izq. de una regla, se genera una nueva
expresión y con esta se continúa el mismo proceso
hasta que no se puedan generar nuevas expresiones
o Resulta costoso tanto en tiempo como en espacio.
Expresiones equivalentes
El tiempo puede reducirse si el optimizador tiene en cuenta
la estimación de costes y de este modo evita evaluar
ciertas expresiones.
El espacio de memoria se puede reducir si dos
subexpresiones comparten el mismo espacio cuando éstas
son idénticas
Fase de optimización
La fase de optimización de una consulta tiene por objeto
generar el plan de ejecución para la consulta a partir del
programa algebraico generado en la fase anterior de
descomposición.
Deben contemplarse diversos aspectos en esta fase de
optimización:
El momento o modo de generación del plan.
La estrategia de optimización de operadores algebraicos
del programa.
Fase de optimización
En cuanto al momento de generación, se
contemplan:
Planes dinámicos
Planes estáticos
La estrategia de optimización permite diferenciar los
enfoques de:
Optimización por reglas
Optimización por costes
Comparación de enfoques
Plan dinámico Plan estático
Toda la información necesaria para
optimizar la consulta está disponible
cada vez que se genera el plan.
El plan se genera con la información
disponible en el momento de su
catalogación. Si la información
cambia con el tiempo, el plan puede
no ser óptimo en las nuevas
circunstancias.
Cada vez que se ejecuta la consulta
se genera el plan, añadiendo el
tiempo de generación del plan al
tiempo de ejecución del mismo.
Sólo se incurre en el coste o tiempo
de generación del plan en el
momento en que se cataloga. Las
transacciones no sufrirán este
tiempo de generación, pues pueden
cargar y ejecutar el plan en
memoria.
Comparación de enfoques
Optimización basada en reglas Optimización basado en coste
Sólo tiene en cuenta los caminos de
acceso existentes en el esquema
interno de la BD (índices primarios,
secundarios, clusters, rutinas de
hashing, etc.), un conjunto
predefinido de reglas (métodos
alternativos) y la manera de
especificar las condiciones en la
consulta (constantes, variables, uso
de funciones, etc.).
Maneja caminos de acceso, como en
el caso de optimización por reglas, e
información volumétrica (tamaños)
sobre las tablas manejadas en cada
consulta. El objetivo es maximizar el
througput o minimizar el uso de
recursos necesarios para procesar
la consulta (minimizar el tamaño de
resultados intermedios para
ejecutar cada operador algebraico).
Es el enfoque clásico de optimización. Para cada resultado intermedio es
necesario evaluar costes de los
métodos alternativos y el tamaño
de dicho resultado intermedio.
Información de catálogo
Para cada SGBD es distinta pero al menos tiene para cada
relación:
Nº de tuplas de la relación r (nr)
Nº de bloques que contienen tuplas de la relación r (br)
Tamaño en bytes de una tupla de r (tr)
Factor de bloqueo de r. Nº de tuplas de r que caben en
un bloque. (fr)
Nº de valores distintos del atributo A de la relación (
V(A,r))
Nº medio de tuplas de r que satisfacen una condición
de igualdad sobre el atributo A de la relación r ( CS(A,r) )
oSi A es clave de r CS(A,r)=1
oSi A no es clave de r, CS(A,r)= nr/V(A,r)
Información de catálogo
Para los índices:
Grado de salida de los nodos internos del índice i (para
índices B+) (gi)
Altura del índice para el atributo A de r (AAi)
Número de bloques que ocupa el nivel más bajo (nivel
de hojas) del índice i
(MAi)
¿Cómo se construye un plan?
Primer paso
– SQL Álgebra Relacional Árbol Canónico
Ejemplo SELECT nombreJugador, nombreEquipo
FROM Jugador J, Equipo E
WHERE J.idEquipo = E.idEquipo
πnombreJugador, nombreEquipo(σJugador.idEquipo=Equipo.idEquipo (Jugador X Equipo))
πnombreJugador, nombreEquipo
σJugador.idEquipo=Equipo.idEquipo
XJugador Equipo
¿Cómo se construye un plan?
Segundo paso
– Modificaciones algebraicas sobre el árbol
EjemploπnombreJugador, nombreEquipo
σJugador.idEquipo=Equipo.idEquipo
XJugador Equipo
πnombreJugador, nombreEquipo
⋈Jugador Equipo
πnombreJugador, nombreEquipo
⋈Equipo Jugador
Técnicas algebraicas
• Se utilizan Heurísticas
– Se basan en propiedades algebraicas
– Siempre generan árboles equivalentes
– Son reglas que, por lo general, mejoran la
performance de las consultas
Ejemplos
Cascada de selecciones
Bajar selecciones
Bajar proyecciones
Cambiar productos cartesianos por joins
¿Cómo se construye un plan?
Tercer paso
– Selección de la implementación de cada
operador
EjemploπnombreJugador, nombreEquipo
⋈
Jugador EquipoBNLJ
pipeline
Técnicas físicas
Consiste en seleccionar implementaciones para los
operadores basándose en cómo están organizados
los archivos y las estructuras adicionales que existen.
Utilizan una estructura de la BD llamada Catálogo
o Mantiene información estadística acerca de los
datos de las diferentes tablas.
o Se actualiza periódicamente y no están siempre
sincronizadas con los datos reales.
o Permite estimar la selectividad de los diferentes
operadores.
Ejercicio
Micro(numMicro, marca, numEmpresa)
Empresa(numEmpresa, nombreEmpresa, fechaCreacion,
direccion)
Viaje(numMicro,fechaViaje,destino)Micro.numEmpresa no admite nulos y es FK de Empresa.
Viaje.numMicro es FK de Micro.
Se desea optimizar la siguiente consulta:
SELECT numMicro, numEmpresa, nombreEmpresa,
fechaCreacion, direccion,destino, fechaViaje
FROM Micro M, Empresa E, Viaje V
WHERE M.numMicro = V.numMicro
AND M.numEmpresa = E.numEmpresa
AND E.fechaCreacion >= ‘1/1/2000’
AND V.fechaViaje >= ‘1/1/2007’
AND V.fechaViaje < ‘1/2/2007’
AND M.marca = ‘Mercedes Benz’
Ejercicio
Se tiene como datos:
La longitud de los campos es de 128 bytes cada uno.
Tuplas Micro: 200.000.
Tuplas Empresa: 3.000.
Tuplas Viaje: 2.500.000.
Micros con marca ‘Mercedes Benz’: 50.000.
Viajes de enero del 2007: 100.000.
Empresas creadas desde el año 2000: 2.000.
Además:
Se cuenta con 5 bloques de memoria.
El tamaño de bloque es 2048 bytes.
Se asume distribución uniforme.
a) Armar el árbol canónico de la consulta.
b) Obtener un árbol optimizado, indicando su plan de ejecución, y
calcular los costos.
c) Describir brevemente qué estructura agregaría para mejorar la
performance de la consulta (sin calcular costos).
Ejercicio (Solución)
Armar la consulta en álgebra relacional:
Π numMicro, nombreEmpresa, numEmpresa, fechaCreacion,
direccion, destino, fechaViaje
(σ M.numMicro = V.numMicro
AND M.numEmpresa = E.numEmpresa
AND E.fechaCreacion >= ‘1/1/2000’
AND V.fechaViaje >= ‘1/1/2007’
AND V.fechaViaje < ‘1/2/2007’
AND M.marca = ‘Mercedes Benz’
(M x E x V))
Ejercicio (Solución)
Árbol canónico:
Ejercicio (Solución)
Separar la selección en varias selecciones:
Ejercicio (Solución)
Bajar las selecciones que son condiciones de junta para poder
cambiar productos cartesianos por natural joins.
Ejercicio (Solución)
Cambiar productos cartesianos + condición de junta por natural
joins
Ejercicio (Solución)
Bajar las selecciones hasta las hojas:
Ejercicio (Solución)
Proyectar sólo los atributos que se usan:
Ejercicio (Solución)
Analizar utilidad de las selecciones:
Ejercicio (Solución)
Calcular los costos:
top related