Bases de Datos I. Cursada Clase 5: Optimización de Consultas

Transcripción

1 Bases de Datos I Cursada 2008 Clase 5: Optimización de Consultas Facultad de Ciencias Exactas Universidad Nac. Centro de la Pcia. de Bs. As. DISEÑO Y OPTIMIZACIÓN DE BASES DE DATOS Objetivo Mejorar los tiempos de respuesta en un sistema de gestión de bases de datos relacional. DISEÑO Y OPTIMIZACIÓN DE BASES DE DATOS Donde incide la optimización? Factores a tener en cuenta: El costo de comunicación de acceso a almacenamiento secundario. El costo de almacenamiento. El costo de computación. El optimizador interviene también en las actualizaciones y borrados!!!. 1

2 DISEÑO Y OPTIMIZACIÓN DE BASES DE DATOS Motivación: Crítica a los primeros sistemas basados en el modelo relacional: bajo rendimiento de las consultas Investigación y desarrollo de algoritmos eficientes para procesar consultas En un sistema no relacional... Consultas expresadas en lenguaje procedural de bajo nivel El usuario selecciona la estrategia de ejecución: optimización manual Decide las operaciones necesarias y su orden de ejecución Si se equivoca, el sistema no puede mejorar la situación Debe tener conocimientos de programación En un sistema relacional... Consultas expresadas con SQL: QUÉ datos y no CÓMO recuperarlos El DBMS selecciona la mejor estrategia de ejecución y tiene mayor control sobre el rendimiento del sistema DISEÑO Y OPTIMIZACIÓN DE BASES DE DATOS La optimización [automática] es: Un desafío obligatorio si se debe lograr un tiempo de ejecución de consultas aceptable Una oportunidad el alto nivel semántico de una expresión relacional permite su optimización antes de la ejecución Procesamiento de Consultas Actividades involucradas en la recuperación de datos de la BD Optimización de Consultas Elección de una estrategia de ejecución eficaz para procesar cada consulta sobre la base de datos Objetivo de la optimización de consultas Elegir la estrategia de ejecución que minimiza el uso de los recursos En general, no se garantiza que la estrategia elegida por el DBMS sea la óptima, pero seguro que será una estrategia razonablemente eficiente OPTIMIZACIÓN DE CONSULTAS Formas alternativas de evaluar una consulta Hallar expresiones equivalentes Algoritmos elaborados para cada operación Diferencia de costo entre una buena y una mala forma de evaluar una consulta muy significativa!! Para estimar el costo de las operaciones: Información estadística sobre las relaciones: Cantidad de tuplas, Cantidad de repeticiones de cada valor de cada atributo, Frecuencia de acceso a cada relación, a conjuntos de tuplas, etc. Estimación estadística de los costos de hallar resultados intermedios, para las expresiones complejas. 2

3 OPTIMIZACIÓN DE CONSULTAS Las relaciones generadas por expresiones equivalentes El mismo conjunto de atributos El mismo conjunto de tuplas Tuplas y atributos pueden ser obtenidos en distinto orden. Bibliografía Principal: Database System Concepts. 5ª edición Silverschatz, Korth y Sudarshan, 2005 OPTIMIZACIÓN DE CONSULTAS Generación de un plan de evaluación de cada consulta involucra: Generación de una expresión lógicamente equivalente reglas de equivalencia Analizar expresiones resultantes para obtener planes alternativos Elegir el que ofrezca el menor costo costo estimado Proceso de optimización basado en costos. Consulta representación interna proceso de optimización elección de índices/órdenes # de accesos a disco costo TRANSFORMACIÓN DE EXPRESIONES Modelo relacional Álgebra relacional Dos expresiones algebraicas son equivalentes si generan el mismo conjunto de tuplas, para cualquier estado de la base de datos. Recordar el orden de las tuplas y de los atributos es irrelevante En SQL Bolsas Dos expresiones en álgebra de bolsas son equivalentes si generan las mismas bolsas, para cualquier estado de la base de datos. Recordar el orden de las tuplas y de los atributos es irrelevante 3

4 REGLAS DE EQUIVALENCIA Expresiones diferentes son equivalentes si cada una puede reemplazar a la otra. 1. Selección Conjuntiva secuencia de selecciones individuales. σ θ ( ) ( ( )) 1 θ E = σ E 2 θ σ 1 θ 2 2. Selección es conmutativa. σ θ ( σ ( E)) ( ( E)) 1 θ = σ 2 θ σ 2 θ1 REGLAS DE EQUIVALENCIA 3. Secuencia de proyecciones sólo tiene sentido la última. Π L ( Π ( ( ( E)) )) ( E) 1 L K Π 2 Ln K = Π L1 Selección puede combinarse con productos cartesianos y ensambles generales (Theta join). a. σ θ (E 1 X E 2 ) = E 1 θ E 2 b. σ θ1 (E 1 θ2 E 2 ) = E 1 θ1 θ2 E 2 REGLAS DE EQUIVALENCIA 5. Ensambles naturales y generales son conmutativos. E1 θ E2 = E2 θ E1 6. (a) Ensamble Natural es asociativo (E1 E2) E3 = E1 (E2 E3) (b) Ensambles generales son asociativos de la siguiente forma: (E1 θ1 E2) θ2 θ3 E3 = E1 θ1 θ3 (E2 θ2 E3) θ2 involucra atributos sólo de E2 y E3. 4

5 REGLAS DE EQUIVALENCIA 7. Selección distributiva sobre los ensambles generales, bajo las siguientes condiciones: (a) Cuando θ0 involucra sólo atributos de una de las expresiones a ensamblar (sea E1). σ θ0 (E1 θ E2) = (σ θ0 (E1)) θ E2 (b) Cuando θ1 involucra sólo los atributos de E1 y θ2 sólo los de E2. σ θ1 θ2 (E1 θ E2) = (σ θ1 (E1)) θ (σ θ2 (E2)) REGLAS DE EQUIVALENCIA 8. Proyección es distributiva para el ensamble general en los siguientes casos: (a) si Π involucra sólo atributos de L1 L2 (L1 y L2 conj. de atributos de E1 y E2, inters. no vacía): L1 L2 1 θ 1 θ 2 E ( E E 2 ) = ( L ( E1)) ( L ( 2 )) (b) Sea el ensamble E1 θ E2. Sean L1 y L2 conjuntos de atributos de E1 y E2, respectivamente. Sean L3 y L4 conjuntos de atributos de E1 y E2 respectivamente, involucrados en la condición θ, pero no en L1 L2. ( E E ) = (( ( E )) ( ( E ))) L 1 L2 1 θ 2 L L L L 1 L L θ REGLAS DE EQUIVALENCIA 9. Unión e intersección son conmutativas E1 E2 = E2 E1 E1 E2 = E2 E1 Recordar la diferencia no es conmutativa!! 10. Unión e intersección son asociativas. (E1 E2) E3 = E1 (E2 E3) (E1 E2) E3 = E1 (E2 E3) 11. Proyección es distributiva sobre la unión Π L (E1 E2) = (Π L (E1)) (Π L (E2)) 5

6 REGLAS DE EQUIVALENCIA 12. (a) Selección es distributiva sobre, y. σ θ (E1 E2) = σ θ (E1) σ θ (E2) (lo mismo para y ) (b) σ θ (E1 E2) = σ θ (E1) E2 (lo mismo para, pero no para ) 13. Otras. ESTRATEGIAS GENERALES DE OPTIMIZACIÓN Realizar las selecciones tan pronto como sea posible. Combinar ciertas selecciones con un producto cartesiano anterior, para realizar una asociación o un JOIN. Combinar secuencias de operaciones unarias, como selecciones y proyecciones. Detectar subconsultas con resultados equivalentes que puedan reutilizarse a lo largo de una misma consulta. ESTRATEGIAS GENERALES DE OPTIMIZACIÓN Mediante sus propiedades, desplazar cada selección simple lo más abajo posible del árbol. Mediante sus propiedades, desplazar las proyecciones lo más abajo posible del árbol. Usar las propiedades de proyección y selección para combinar cascadas de proyecciones y selecciones en una selección sencilla, una proyección sencilla o una selección seguida de una proyección (hacer todas las proyecciones y a continuación todas las selecciones que afecten a una misma relación es mejor que alternar dichas operaciones) 6

7 EJEMPLO DE TRANSFORMACIÓN 1 Consulta: Obtener todos los nombres de los clientes que tienen una cuenta en alguna sucursal del banco localizada en Brooklin. Π customer_name (σ branch_city = Brooklyn (branch (account depositor))) Transformación usando la regla 7a. Π customer_name ((σ branch_city = Brooklyn (branch)) (account depositor)) Ubicar la selección tan tempranamente como sea posible reduce el tamaño de la relación a ensamblar!! EJEMPLO DE TRANSFORMACIÓN 2 Consulta: Obtener los nombres de todos los clientes con cuenta en alguna sucursal de Brooklyn, cuyo saldo sea > $1000. Π customer_name ((σ branch_city = Brooklyn balance > 1000 (branch (account depositor))) Transformación usando la regla 6a: Π customer_name ((σ branch_city = Brooklyn balance > 1000 (branch account)) depositor) Ahora puede usarse la regla que aconseja ejecutar las selecciones tan tempranamente como sea posible en la subconsulta σ branch_city = Brooklyn (branch) σ balance > 1000 (account) EJEMPLO DE TRANSFORMACIÓN 2 (cont.) 7

8 EJEMPLO DE TRANSFORMACIÓN 3 Para las relaciones R1, R2 y R3 (R1 R2) R3 = R1 (R2 R3 ) Si R2 R3 es voluminosa y R1 R2 es más pequeña, se elige (R1 R2) R3 Así se calcula y almacena una relación transitoria de menor tamaño. ASPECTOS CLAVE Diversos enfoques y muchos detalles para considerar Es un problema clásico de búsqueda/optimización! No ha sido resuelto completamente aún! Los principales puntos a tener en cuenta: Las reglas algebraicas y su uso en las transformaciones de queries. Decidir sobre el orden en los ensambles. Estimar el costo de los planes de ejecución y el espacio de los resultados intermedios. OPTIMIZADORES DE CONSULTAS Usan reglas de equivalencia para generar sistemáticamente expresiones equivalentes a la dada. Conceptualmente generan todas las expresiones equivalentes ejecutando repetidamente los siguientes pasos, hasta que no se pueden hallar más expresiones: Para toda expresión encontrada, use todas las reglas de equivalencia aplicables agregue las nuevas expresiones al conjunto de expresiones ya halladas Enfoque sumamente costoso en tiempo y espacio!! 8

9 OPTIMIZADORES DE CONSULTAS Requerimientos de espacio pueden reducirse compartiendo subexpresiones comunes Requerimientos de tiempo Pueden reducirse evitando generar algunas expresiones PLAN DE EVALUACIÓN Decide que algoritmo es usado para cada operación, y la coordinación en la ejecución de las operaciones ELECCIÓN DEL PLAN DE EVALUACIÓN Considera la interacción de las técnicas de evaluación el algoritmo más económico para cada operación no siempre es la mejor elección. Optimizadores de consultas incorporan elementos de los dos enfoques siguientes: 1. Buscan sobre todos los planes y eligen el mejor en función de su costo (costoso!!) 2. Usan heurísticas para elegir un plan. 9

10 OPTIMIZACIÓN HEURÍSTICA Transforma el árbol de la consulta que típicamente mejora el desempeño (aunque no necesariamente en todos los casos) : Ejecución de selecciones tempranamente (reduce el número de tuplas) Ejecución de proyecciones tempranamente (reduce la cantidad de atributos) Ejecutar las selecciones y ensambles más restrictivos antes que otras operaciones similares. Algunos sistemas usan sólo este enfoque; otros una combinación con estrategias basadas en costos. PASOS EN LA OPTIMIZACIÓN HEURÍSTICA TÍPICA 1. Transformar selecciones conjuntivas en una secuencia se selecciones simples Regla 1 2. Desplazar las selecciones para que puedan ser ejecutadas lo más tempranamente posible Reglas 2, 7a, 7b, Ejecutar selecciones y ensambles restrictivos lo antes posible Regla 6 PASOS EN LA OPTIMIZACIÓN HEURÍSTICA TÍPICA (cont) 4. Reemplazar el producto cartesiano + selección, por ensamble Regla 4a 5. Transformar y desplazar tanto como sea posible las proyecciones cerca de las relaciones apropiadas Reglas 3, 8a, 8b, Identificar aquellos subárboles cuyas operaciones pueden ser secuencializadas (pipelined), y ejecutadas en fases secuenciales (la entrada de una es la salida de la previa). 10

11 INFORMACIÓN ESTADÍSTICA Necesaria para estimar el costo de ejecución de una consulta n R : número de tuplas en una relación R. b R : número de bloques conteniendo tuplas de R. t R : tamaño de la tupla de R. f R : factor de bloqueo de R. V(A, R): número de valores diferentes del atributo A en la relación R (equivale a A (R) ) ESTIMACIÓN DE TAMAÑOS Si las tuplas de R están en un único archivo, σ A=v (R) n R / V(A,R) : número de registros que satisfacen la condición Condición de igualdad sobre un atributo clave tamaño estimado = 1 σ A V (R) (caso σ A V (r) es simétrico) C = cant. de tuplas que cumplen la condición. min(a,r) y max(a,r) pueden ser metadatos c = 0 si V < min(a,r) c = = n b f R R R V min( A, R) n R. max( A, R) min( A, R) Tamaño de las tuplas igual al de R Si no hay información estadística, se asume c=n R / 2. ESTIMACIÓN DE TAMAÑOS Producto Cartesiano R x S n R.n S tuplas; cada una de tamaño t R + t S bytes. Si esq(r) esq(s) =, luego R S es equivalente a R x S. Si esq(r) esq(s) es una clave para R, una tupla de S tendrá como máximo una tupla que aparee en R El número de tuplas en R S no es mayor que el de S. Si esq(r) esq(s) en S es una FK referenciando a R,el número de tuplas en R S es el mismo de S. Tamaño de las tuplas t R+ t S - esq(r) esq(s) 11

12 ESTIMACIÓN DE TAMAÑOS Si esq(r) esq(s) = {A} no es una FK para R ó S. Si se asume que cada tupla t en R produce tuplas en R S, la cantidad de tuplas en R S puede estimarse en: nr ns V( A, S) Si la reversa es verdadera: nr ns V( A, R) La menor de estas cantidades probablemente será la más acertada!! ESTIMACIÓN DE TAMAÑOS Proyección A (R) = V(A,R) Tamaño de las tuplas t R.A Operaciones de conjuntos Unión/Intersección de selecciones sobre la misma relación σ θ1 (R) σ θ2 (R) puede reescribirse σ θ1 θ2 (R) Tamaño de las tuplas = t R Sobre diferentes relaciones n R S = n R + n S. n R S = mín (n R, n S ) n R S = n R Estos cálculos indican cotas superiores!! ESTIMACIÓN DE CANTIDAD DE VALORES DISTINTOS Selección σ θ (R) Si θ es del tipo A=valor V(A,σ θ (R)) = 1. Si θ es del tipo A = v1 V A = v2 V A = v3 V(A,σ θ (R)) = cant. valores especificados. Si θ es del tipo A op R V(A,σ θ (R)) = V(A.R) * s s es la selectividad de la selección: probabilidad de que una tupla satisfaga la condición Otros casos mín(v(a,r), n σθ (R) ) Mejor estimación teoría de probabilidades, pero estos cálculos generalmente funcionan bien!! 12

13 ESTIMACIÓN DE CANTIDAD DE VALORES DISTINTOS Ensambles R Si todos los atributos en A son de R V(A, R S) = mín (V(A,R), n R S ) S Si A tiene atributos A1 de R y A2 de S, V(A,R S) = mín(v(a1,r)*v(a2 A1,S), V(A1 A2,R)*V(A2,S), n R S ) Mejor estimación teoría de probabilidades, pero estos cálculos generalmente funcionan bien!! ESTIMACIÓN DE CANTIDAD DE VALORES DISTINTOS Proyección son los mismos en A (R) que en R. Lo mismo para los atributos de agrupamiento. Para valores agregados Para min(a) y max(a), la cantidad de valores distintos puede estimarse min(v(a,r), V(G,R)) donde G es el conjunto de atributos de agrupamiento Para otras funciones de agregación asumiendo todos los valores distintos V(G,R) OPTIMIZACIÓN DE CONSULTAS Y VISTAS MATERIALIZADAS Reescritura de consultas para usar vistas materializadas (VM): Sea una VM V = R S ya obtenida El usuario provee R S T Se puede reescribir V T Costos de ambas alternativas cual conviene? Reemplazo del uso de una VM por la definición de la vista: Sea una VM V = R S sin índices definidos sobre ella El usuario provee σ A=10 (V). Suponiendo que S tiene un índice sobre el atributo común B y R uno sobre A. El mejor plan? reemplazo de V por R S σ A=10 (R) S El optimizador debería ser extendido para que pueda considerar las alternativas anteriores y elegir la mejor. 13

14 ÍNDICES REALMENTE importantes para disminuir el tiempo de procesamiento de una consulta. Supóngase la relación Persona (nombre, edad, ciudad) Barrido Secuencial del archivo Persona puede tomar mucho tiempo SELECT * FROM Persona WHERE nombre = Martinez ÍNDICES Crear un índice sobre nombre: Árboles B+ (por ej. con fan-out de 100 y max 4 niveles!) Adamoli Benegas Coronel. Martinez. CREACIÓN DE ÍNDICES Sintaxis: CREATE INDEX nombreindice ON Persona(nombre) 14

15 CREACIÓN DE ÍNDICES Pueden crearse índices para más de un atributo: Ejemplo: CREATE INDEX otroindice ON Persona (edad, ciudad) SELECT * Ayudaría para hacer: FROM Persona WHERE edad = AND ciudad = Tandil SELECT * Pero no en: FROM Persona WHERE ciudad = Tandil CREACIÓN DE ÍNDICES Los índices pueden ayudar en consultas de rango: CREATE INDEX edadindice ON Persona (edad) Los árboles B+ ayudan en: SELECT * FROM Persona WHERE edad > AND edad < Entonces, por qué no crear índices para todo (o casi)? CREACIÓN DE ÍNDICES Cómo se implementarían? σ π Selección ( ) Projección ( ) Join ( >< ) Diferencia Unión Agregación (SUM, MIN, etc.) y GROUP BY 15

16 ESQUEMA PARA EJEMPLOS Compra (Clte:string, vendedor: string, producto: integer), Persona (nombre:string, ciudad:string, tel: integer) Compra Cada tupla 40 bytes, 100 tuplas por pág, 1000 pág tuplas, tamaño del archivo 4MB. Persona: Cada tupla 50 bytes, 80 tuplas por pág, 500 pág tuplas, archivo 2MB. SELECCIONES SIMPLES Son de la forma σ P. atr valor ( P ) Sin índice, desordenado: Debe barrer toda la relación; el costo es M (#pág en P). Con índice sobre el atributo de selección: Se usa el índice para encontrar el conjunto de entradas que salisfacen la condición, y luego se recupera el registro de datos (Importante: índice con Hash sólo es eficiente para selecciones por igualdad!) Estimación del tamaño del resultado: (Tamaño de P) * factor de reducción op SELECT * FROM Persona P WHERE P.tel < 543% USO DE ÍNDICES PARA SELECCIONES SIMPLES Costo depende de la cantidad de tuplas que satisfacen la condición, y del orden del archivo. Costo de encontrar las entradas aptas (pequeño generalmente) + costo de recuperar registros. Si se asume equidistribución de los teléfonos, y el 50% de las tuplas responden, (500 pág, tuplas). Con un índice sobre un archivo ordenado, el costo es de aprox. 500 I/O; si está desordenado, alrededor de I/O! Mejora para el primer caso: Buscar los registros en forma ordenada para asegurarse de visitar cada pág. una sola vez. 16

17 USO DE ÍNDICES PARA SELECCIONES GENERALES Ejemplo: Sea ciudad= Tandil AND tel< 543% Puede usarse un índice sobre hash por ciudad y luego chequear que cada entrada recuperada tenga tel < 543%. O puede ser un índice sobre árbol B ó B+ sobre tel, y luego verificar que cada entrada tenga ciudad= Tandil. Encontrar el camino más restrictivo y luego aplicar verificaciones para los atributos que no se usaron con el índice USO DE ÍNDICES PARA SELECCIONES GENERALES Otra forma: Obtener los conjuntos de referencias a registros para cada atributo, usando cada índice disponible. Hallar la intersección de las referencias. Recuperar los registros y verificar la condición sobre los atributos remanentes. USO DE ÍNDICES PARA SELECCIONES GENERALES Si hay muchas tuplas con P.tel > 543%, usando un índice sobre tel y ordenando las tuplas recuperadas puede ser costoso! Si el archivo está ordenado el costo puede ser menor. SELECT P.nombre, FROM Persona P Where P.tel > 543% GROUP BY P.nombre 17

18 USO DE ÍNDICES PARA SELECCIONES GENERALES Cuando existen claves de búsqueda múltiples: Recuperar los registros de Persona con tel> 543% y ciudad= Tandil puede ser más eficiente mediante uso de un índice con dominio estructurante el par de atributos, que usar un par de índices! Si ambas condiciones son de rango, índices de arbol sobre cualquier permutación de los atributos puede ser mejor. En este ejemplo, es mejor un índice por <ciudad, tel>! (camino más restrictivo) SELECT P.nombre, count(*) FROM Persona P Where P.tel > 543% GROUP BY P.nombre USO DE ÍNDICES PARA PROYECCIONES Dos pasos: (1) remover atributos no deseados, (2) remover duplicados del resultado. Refinamientos para el 2do paso: Si hubiese algún índice para todos los atributos deseados, se puede hacer un barrido del índice solamente. Si el índice contiene un subconjunto de los atributos deseados, se pueden remover los duplicados localmente. SELECT DISTINCT P.nombre, P.tel FROM Persona P QUERIES SÓLO-ÍNDICE Muchas consultas pueden responderse sin acceder al archivo, si hay un índice apropiado: Ejemplos: Índice por <nombre> para SELECT P.nombre, count(*) FROM Persona P GROUP BY P.nombre Índice (árbol) por <P.nombre,P.tel> para SELECT P.nombre, MIN(P.tel) FROM Persona P GROUP BY P.nombre 18

19 ELECCIÓN DE ÍNDICES Qué índices deberían crearse? Qué relaciones deberían tener índices? Qué atributos debería utilizar para crearlos (dominio estructurante del índice) Cuántos deberían crearse? Que tipo de índice es más conveniente para cada caso (prim./sec.?, de agrup?, un nivel/multinivel??) Qué soporte para cada índice? ELECCIÓN DE ÍNDICES Un enfoque: considerar las consultas más frecuentes (esto puede ser variable en el tiempo) Considerar el mejor plan de acuerdo con los índices ya creados, y analizar si hay mejoras agregando nuevos índices. Si es así, crearlos. Esto implica conocer la forma en que el DBMS evalúa las consultas y crea los planes de ejecución. Antes de crearlos analizar el impacto que producen las actualizaciones propagadas!! ELECCIÓN DE ÍNDICES Entender la naturaleza de la operatoria del sistema y los objetivos de desempeño es esencial para desarrollar un buen diseño. Atributos incluidos en las cláusulas WHERE son candidatos a dominios estructurantes de índices Condición por igualdad sugiere hash Condición de rango sugiere árbol Archivos ordenasdos mejoras las búsquedas por rangos, y las de igualdad si hay muchas repeticiones 19

20 ELECCIÓN DE ÍNDICES Claves de búsqueda de varios dominios pueden ser útiles cuando el WHERE involucra varias condiciones El orden de los atributos es importante! Construir índices que permitan resolver consultas sóloíndice. Tratar de elegir índices útiles para tantas consultas como sea posible. Ordenar el archivo es una decisión importante sólo un indice asociado a este orden! El mantenimiento de los índices suma costos! 20