Maestría en Bioinformática Bases de Datos y Sistemas de Información Nociones de p erformance Ing. Alfonso Vicente, PMP

Agenda Noción de performance Acceso secuencial Otras formas de acceso Conceptos Índices Optimizador Planes de acceso

Agenda Estructura Acceso por índices Índices implícitos Sentencia CREATE INDEX Mejores prácticas Conceptos Índices Optimizador Planes de acceso

Agenda Función del optimizador Estadísticas Hints Conceptos Índices Optimizador Planes de acceso

Agenda Etapas en la ejecución de SQL Reuso del plan de acceso SQL dinámico y SQL estático Revisión del plan de acceso Conceptos Índices Optimizador Planes de acceso

Agenda Noción de performance Acceso secuencial Otras formas de acceso Conceptos Índices Optimizador Planes de acceso

Conceptos Noción de performance Normalmente la performance se asocia a la idea de rapidez para realizar un trabajo Es un concepto general que puede tener varias métricas Tiempo de respuesta: tiempo medido desde el punto de vista del usuario desde que envía una solicitud hasta que obtiene una respuesta Throughput: cantidad de trabajo por unidad de tiempo. Según el contexto el trabajo se puede medir en bytes, número de operaciones de E/S, operaciones lógicas, etc

Conceptos Noción de performance La principal causa de una performance pobre es un diseño pobre (normalización, SQL, algoritmos) Ejemplo: el programa que se enlentecía por las tardes Un programa debía generar números secuenciales dentro de cada día El algoritmo consistía en probar el 1, si ya había sido dado probar el 2, si ya había sido dado probar el 3, y así sucesivamente...

Conceptos Acceso secuencial Imagine el siguiente algoritmo interno para resolver una consulta en: personas(id, nombre, apellido, telefono) select telefono from personas where nombre = 'Juan' and apellido = 'López' t := la primer tupla de personas mientras (t sea una tupla) si (t.nombre= 'Juan' y t.apellido = 'López') retorno t.telefono t := siguiente tupla de personas retorno {} ¿Qué puede decir sobre esta forma de acceso?

Conceptos Otras formas de acceso ¿Con qué velocidad buscamos en la guía telefónica? Paso 0: Tenemos N páginas, abrimos al medio Paso 1: Buscamos en N/2 páginas, abrimos al medio Paso 2: Buscamos en N/4 páginas, abrimos al medio Paso k: Buscamos en N/2^k páginas, llegamos a la página! Cuando llegamos: N/2^k = 1 N = 2^k k = log 2 N El número de pasos crece con las páginas, pero de forma logarítmica (mil páginas = 10 pasos, 1 millón: 20 pasos)

Agenda Estructura Acceso por índices Índices implícitos Sentencia CREATE INDEX Mejores prácticas Conceptos Índices Optimizador Planes de acceso

Índices Estructura Las tablas mantienen una columna oculta con un identificador de tupla (llamémosle ROWID) PERSONAS | ROWID | ID | NOMBRE | APELLIDO | TELEFONO | | 10 | 1 | Juan | Martínez | | | 11 | 2 | Rodrigo | Giménez | | | 27 | 3 | María | Pérez | | | 80 | 4 | Juan | López | |

Índices Estructura Los índices (generalmente) son estructuras arborescentes, ordenadas por algunas columnas, y con los ROWID | | Martínez | 10 | | | | Giménez | 11 | | | | Pérez | 27 | | | | López | 10 | |

Índices Estructura Normalmente no son árboles binarios, sino árboles B Estas estructuras deben actualizarse a medida que se modifica la instancia mediante sentencias DML

Índices Acceso por índices Si buscamos por apellido y tenemos un índice por la columna apellido, la búsqueda en el índice será mucho más rápida (orden logarítmico vs. orden lineal) Luego, utilizando el ROWID de las tuplas que matchean con nuestra búsqueda, llegamos a las tuplas en la tabla de forma directa Dependiendo de la consulta, podría ni siquiera ser necesario llegar a la tabla: select count(*) from personas where apellido = 'López';

Índices Índices implícitos Al definir una PK o una UK, los RDBMSs crean índices de forma implícita (si ya no existe uno por esas columnas) Esto es porque el RDBMS debe asegurar que cada tupla tiene valores diferentes por cada clave, o sea que en cada INSERT y UPDATE debe buscar si el nuevo valor existe (y debe hacerlo rápido) El índice es otro objeto de esquema dentro de la base. Los que son creados implícitamente tendrán un nombre sin semántica (e.g. SYS000142)

Índices Sentencia CREATE INDEX Podemos querer crear un índice por columnas que no sean PK ni UK (por ejemplo, para mejorar la performance de consultas por nombre y apellido) create [unique] index on ( [asc|desc],..., [asc|desc] ); Ejemplo create index personas_ape_nom on personas (apellido, nombre); En general, cada RDBMS tiene muchas más opciones

Índices Sentencia CREATE INDEX También podemos querer crear un índice por columnas que sean PK o UK, para asignarles un nombre y evitar que se creen de forma implícita create table PERSONAS (... ); create unique index IX_PERSONAS_ID on personas (id); alter table personas add constraint PK_PERSONAS primary key (id); No se creará un índice implícito porque ya existe uno

Índices Mejores prácticas No siempre es mejor acceder por índice que acceder secuencialmente a la tabla Los índices pueden mejorar la performance de las sentencias que tienen predicado (SELECT, UPDATE, DELETE), pero necesitan ser mantenidos en cada sentencia DML (INSERT, UPDATE, DELETE) Necesitamos tener alguna idea de cuándo conviene crear índices, y qué índices crear

Índices Mejores prácticas Si consultaremos frecuentemente una tabla grande por columnas que no están al comienzo de ningún índice, podemos considerar crear un índice por esas columnas Las columnas más selectivas deberían ubicarse primero Ejemplo: ¿qué índice convendría crear? select nombre, apellido, telefono from personas where departamento = 5 and apellido = 'López'; select count(distinct departamento) from personas; 10 select count(distinct apellido) from personas; 1000

Agenda Función del optimizador Estadísticas Hints Conceptos Índices Optimizador Planes de acceso

Optimizador Función del optimizador El optimizador es quién decide, para cada sentencia, cómo accede a los datos (tablas e índices disponibles), tratando de elegir el mejor algoritmo de acceso A medida que la instancia (y esquema) cambia, el mejor algoritmo de acceso también cambia El optimizador es parte del RDBMS y funciona sólo, sin que debamos hacer nada ¿Cómo hace el optimizador para conocer sobre la instancia?

Optimizador Estadísticas El optimizador se basa en estadísticas que toma de vez en cuando y mediante las cuales sabe sobre la distribución de los datos en las tablas y en las columnas Las estadísticas mantienen datos como el número de tuplas de cada tabla, y de cada columna datos como el menor y el mayor valor, el número de valores distintos, los límites de quintiles, el número de nulls, etc Según el RDBMS, el proceso que recolecta estadísticas podría correr de forma automática (por tiempo o según los cambios) o podríamos tener que correrlo explícitamente

Optimizador Hints Algunos RDBMSs permiten agregar hints (sugerencias) a las sentencias, para sugerirle al optimizador un algoritmo de acceso Esto puede ser útil debido a que el optimizador no siempre elige el mejor plan de acceso posible El optimizador podría decidir mal debido a: Estadísticas desactualizadas Estadísticas con poco nivel de detalle (o sampling) Un error de cálculo :)

Agenda Etapas en la ejecución de SQL Reuso del plan de acceso SQL dinámico y SQL estático Revisión del plan de acceso Conceptos Índices Optimizador Planes de acceso

Etapas en la ejecución de SQL Preparar: Implica tomar el texto del SQL y generar un plan de acceso y variables de bind Ejecutar: Implica seguir el plan de acceso (utilizando las variables de bind) para lograr el objetivo de la sentencia Imagine que en una base se ejecuta veces al día la misma consulta con valores diferentes: select nombre, apellido, telefono from personas where departamento = ? and apellido = ?

Planes de acceso Reuso del plan de acceso El plan de acceso podría reutilizarse Preparar la sentencia una única vez (tal vez en tiempo de compilación) y generar el plan de acceso Ejecutarla N veces, con el plan ya obtenido Esto tiene ventajas (no se incurre en el costo de la preparación) y desventajas (si la instancia cambia, el optimizador no puede ayudarnos porque ya no interviene)

Planes de acceso SQL dinámico y SQL estático Podemos beneficiarnos del uso de SQL estático utilizando código compilado, por ejemplo stored procedures o PreparedStatements en Java

Planes de acceso Revisión del plan de acceso Revisar el plan de acceso de una sentencia es la mejor manera de asegurarse que se está utilizando el mejor plan de acceso posible La forma de hacerlo es diferente en cada RDBMS, aunque normalmente siempre hay alguna interfaz que lo muestra en forma gráfica En el plan de acceso, se debería mirar: El costo (el global, y los pasos más costosos) La existencia de TABLE SCANS

Planes de acceso Revisión del plan de acceso En Oracle, mediante SQL *Plus: SQL> explain plan for select sueldo from empleados where nombre = 'Luis' and apellido = 'Rodriguez'; Explained. SQL> select * from table(dbms_xplan.display); | Id | Operation |Name |Rows|Bytes|Cost (%CPU)|Time | | 0 | SELECT STATEMENT | | 1| 31| 3 (0)|00:00:01 | |* 1 | TABLE ACCESS FULL|EMPLEADOS| 1| 31| 3 (0)|00:00:01 | filter("NOMBRE"='Luis' AND "APELLIDO"='Rodriguez')

Planes de acceso Revisión del plan de acceso En Oracle, mediante SQL Developer

Planes de acceso Revisión del plan de acceso Después de crear un índice, el plan cambia. Primero accede al índice EMPS_NOM_APE y después a la tabla, con el ROWID (directamente a la tupla que se necesita) SQL> create index emps_nom_ape on empleados(nombre, apellido); Index created. Plan de acceso: |Id|Operation |Name |Rows|Bytes|Cost (%CPU)|Time | | 0|SELECT STATEMENT | | 1| 31| 1 (0) | 00:00:01 | | 1| TABLE ACCESS BY INDEX ROWID|EMPLEADOS | 1| 31| 1 (0) | 00:00:01 | |*2| INDEX RANGE SCAN |EMPS_NOM_APE| 1| | 1 (0) | 00:00:01 |