Optimización de Preguntas

Optimización de preguntas zOptimización: pregunta  plan costo ópt. costo = CPU + I/O + COMUNICACIONES zNecesario para responder eficientemente zPosible con lenguajes no procedurales (ej. SQL) yleng. no procedural: se dice qué se quiere obtener y no cómo obtenerlo (algoritmo, uso de índices...) ysistemas con lenguajes procedurales: ej. IMS (jerárquico) o CODASYL (en red)

Ejemplo motivador zLa optimización es posible y necesaria zLas distintas estrategias requieren costes muy distinto zDebe ser un proceso automático ydepende del momento concreto en la vida de la BD yes complicado saber qué estrategia es mejor yNunca se esta seguro (estimaciones)

Etapas en la optimización zConvertir la pregunta en una representación interna (álgebra relacional, árbol sintáctico) zTransformar la pregunta en una forma canónica (reglas sintácticas y semánticas) zEscoger los procedimientos de bajo nivel candidatos (para cada operador) y¿índices? ¿clustering? ¿rango y núm. valores? zGenerar los planes y escoger el más barato yusar heurísticos para reducir búsqueda

Optimización sintáctica zEntrada: expresión álgebra relacional zSalida: expr. álgebra relacional equivalente yoperaciones de idempotencia, propagar ctes. yoperación selección se baja en el árbol yoperación proyección se baja en el árbol yagrupar selecciones y proyecciones yIdea: reducir tamaño de las relaciones a combinar con la operación join

Optimización semántica zTransformar la pregunta en otra que devuelve las misma tuplas zUtilizar conocimiento semántico de la BD yrestr. integridad, dependencias funcionales, claves extranjeras, reglas semánticas z En general, la opt. sem. es un proceso caro, por lo que los SGBD comerciales no la aplican. Se suele basar en técnicas de Int. Artificial.

Optimización física: Selección zAlgoritmos yBúsqueda lineal yBúsqueda binaria yEmpleo de índices (de distintos tipos) zSelectividad de una condición y% de la relación que satisface la condición yEjecutar primero las selecciones de mayor selectividad

Optimización física: Join zAlgoritmos yCiclo anidado (Nested Loops) o fuerza bruta ySort-Join (Sort Merge) yJoin con índice en una de las relaciones yJoin con índice para cada relación yHash-Join

Optimización física: otras op. zProyecciones: fácil de implementar (hay que recorrer todas las tuplas) zProducto cartesiano: muy costosa yEvitarla zUnión, Intersección, Diferencia yPrimero se ordenan las dos relaciones

Generar los planes y escoger el más barato zPlanes para responder a la pregunta, y su costo zCada plan se construye combinando el conjunto de procedimientos candidatos posibles. yCalcular el costo es complicado  hay que estimar tamaños de resultados intermedios (estadísticas de la BD, en el catálogo). xCalcular el orden óptimo de ejecución de joins N! posibilidades de ejecutar un join entre N relaciones xEvitar resultados intermedios (subir selecciones) zUsar heurísticos para reducir la búsqueda

Optimización del costo: CPU + I/O + COM zBD centralizadas ygeneralmente se tiene en cuenta sólo costo I/O zBD distribuidas en Redes Area Amplia (WAN) ygeneralmente, sólo costo COM. zBD distribuidas en Redes de Area Local (LAN) ygeneralmente, costos I/O y COM. zBD en servidores paralelos yinfluyen los tres: CPU, I/O y COM.

Optimización en Oracle zOptimización basada en reglas o basada en costes (seleccionado por el usuario) zEXPLAIN PLAN: ver como se ejecutará una sentencia SQL zNo hay optimización semántica yhasta Oracle 8, incluido zSe puede influir en el uso o no de índices (no recomendado)

Conclusiones yLos SGBD realizan optimización de preguntas son inútiles algunas reformulaciones de preguntas yAlgunas optimizaciones (todavía) no son realizadas por los SGBD (ej. optimización semántica) hay que reformular algunas preguntas yEl proceso de optimización de preguntas es complejo y cada SGBD lo hace distinto. hay que consultar el manual del SGBD concreto. yEs necesario conocer cómo se procesan las preguntas para realizar el DISEÑO FÍSICO. cuándo es útil usar índices o hash o no utilizarlos. saber que el join es costoso --> reducir número de joins.