Maestría en Bioinformática

Bases de Datos y Sistemas de Información

Nociones de performance

Ing. Alfonso Vicente, PMPalfonso.vicente@logos.com.uy

Agenda

Noción de performance Acceso secuencial Otras formas de acceso

ConceptosÍndices

OptimizadorPlanes de acceso

Agenda

Estructura Acceso por índices Índices implícitos Sentencia CREATE INDEX Mejores prácticas

ConceptosÍndices

OptimizadorPlanes de acceso

Agenda

Función del optimizador Estadísticas Hints

ConceptosÍndices

OptimizadorPlanes 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

OptimizadorPlanes de acceso

Agenda

Noción de performance Acceso secuencial Otras formas de acceso

ConceptosÍndices

OptimizadorPlanes 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 personasmientras (t sea una tupla)

si (t.nombre= 'Juan' y t.apellido = 'López') retorno t.telefonot := 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 = log2 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

OptimizadorPlanes 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 | 5551122 |+----------+----------+----------+----------+----------+| 11 | 2 | Rodrigo | Giménez | 5553344 |+----------+----------+----------+----------+----------+| 27 | 3 | María | Pérez | 5556677 |+----------+----------+----------+----------+----------+| 80 | 4 | Juan | López | 5558899 |+----------+----------+----------+----------+----------+

Í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 <nombre>on <table> ( <col1> [asc|desc], ..., <colN> [asc|desc] );

• Ejemplo

create index personas_ape_nomon 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_IDon personas (id);

alter table personasadd constraint PK_PERSONASprimary 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; 10select count(distinct apellido) from personas; 1000

Agenda

Función del optimizador Estadísticas Hints

ConceptosÍndices

OptimizadorPlanes 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

OptimizadorPlanes de acceso

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 10.000 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 |----------------------------------------------------------------------

1 - 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 |--------------------------------------------------------------------------------