Base de datos

Clase 3
Agenda de Hoy
1. Particiones de Tablas
2. Optimización de Queries

2
¿Que es una PARTICIÓN?
Partición de Tabla
En ocasiones tenemos tablas muy grandes, con millones de tuplas y queremos
optimizar el rendimiento de dicha tabla. Una forma de optimizar tablas muy
grandes es realizar un particionado de éstas, es decir, subdividir una tabla padre
en varias tablas pequeñas hijas y vaciar la tabla padre utilizando la cláusula ONLY.
El procedimiento es muy sencillo y sistemático.

4
Herencia de Tablas
1. Crear las tablas hijas.
2. Insertar en las tablas hijas los datos de la tabla padre, realizando una
subconsulta según la condición que necesitemos. Por ejemplo, por fechas
anuales.
3. Eliminar los datos de la tabla padre, puesto que debe de quedar
completamente vacía.

5
“ Hay que tener un especial cuidado cuando se eliminen los
datos de la tabla padre, puesto que si realizamos un «delete»
se eliminan todas las filas de la tabla padre y también los
datos de las tablas hijas. Para prevenir que se eliminen los
datos de las tablas hija, tenemos la cláusula ONLY. Con esta
cláusula nos referimos sólo a la tabla padre.

6
Ejemplo
Para que se vea más claro como sería realizar un particionado de tablas muy
grandes, a continuación te dejamos un ejemplo sin utilizar la cláusula ONLY y
otro con dicha cláusula.

Partimos de una base de datos llamada «test» con una tabla «prueba» con
6000000 tuplas y que ocupa 207 MB.

7
Ejemplo
Crear las tablas hijas

Lo primero es crear las 6 tablas hijas heredadas de la tabla padre «prueba»

con una restricción para que chequee el intervalo de filas cuando se inserten
los valores de la tabla padre en la tabla hija correspondiente.

La sentencia SQL es algo similar a esta.

test=# CREATE TABLE prueba_1 (CHECK (col >0 AND col <1000001))
INHERITS (prueba);

8
Ejemplo
Crear reglas adicionales

Para prevenir que no se realice inserciones en la tabla padre y se dirija a las

tablas hijas correspondientes, se crean 6 reglas de forma similar a esta.

test=# CREATE RULE prueba_3_rule AS ON INSERT TO prueba WHERE (col

>2000000 AND col <3000001) DO INSTEAD INSERT INTO prueba_3 VALUES
(NEW.*);

9
Ejemplo
Insertar valores

Procedemos a realizar una inserción en cada tabla hija, realizando una

subconsulta de la tabla padre con el rango de datos correspondiente.

La sentencia SQL quedaría así.

test=# INSERT INTO prueba_6 SELECT * FROM prueba WHERE (col >5000000
AND col <6000001);

10
Ejemplo
Eliminar datos de la tabla padre sin usar la cláusula ONLY.

Si no tenemos cuidado y eliminamos los datos de la tabla padre sin utilizar la

cláusula ONLY, se eliminan tanto los datos de la tabla padre como de las hijas.

test=# DELETE FROM prueba;

DELETE 12000000
test=# SELECT count(*) FROM prueba;
count
——-
0
(1 row)

11
Ejemplo
Eliminar datos de la tabla padre usando la cláusula ONLY.
Al utilizar la cláusula ONLY, nos estamos refiriendo a la tabla padre. Con
esta cláusula sólo se eliminan los 6 millones de tuplas que tiene la tabla
padre.

test=# DELETE FROM ONLY prueba;

DELETE 6000000

test=# SELECT count(*) FROM ONLY prueba;

count
——-
0
(1 row)
12
Ejemplo

Podemos observar que al realizar una consulta sin usar dicha cláusula, el
resultado es la suma de las filas de las tablas hijas.

test=# SELECT count(*) FROM prueba;

count
———
6000000
(1 row)

13
“ Conclusión
Se ha subdividido una tabla con 6 millones de tuplas en 6
tablas, cada una con un millón de filas, que a su vez es posible
particionar cada una de estas tablas hijas en otras tablas de
forma que contenga menos filas. Así con este método se
gana mucho en rendimiento, puesto que a la hora de realizar
una lectura secuencial, son muchas menos tuplas que leer.

14
Ejemplo 2
En empresas con muchas transacciones de datos es conveniente particionar las tablas por fecha.
En el siguiente ejemplo sencillo se tomarán las Ventas por fecha de venta y se realizarán particiones
por mes.

CREATE TABLE sale (

sale_date date not null,
country_code text,
product_sku text,
units integer
) PARTITION BY RANGE (sale_date);

15
Ejemplo 2
Se crear las tablas particionadas por cada mes según el rango de fechas deseado
Puede ser por (mes, año, rango fijo)

CREATE TABLE sale_201901 PARTITION OF sale

FOR VALUES FROM ('2019-01-01') TO ('2019-02-01');

CREATE TABLE sale_201902 PARTITION OF sale

FOR VALUES FROM ('2019-02-01') TO ('2019-03-01');

16
Ejemplo 2
Se crearon ambas particiones de la tabla sale

Es buena estrategia realizar consultas directamente en las particiones para el mes requerido en vez
de la tabla original..

17
Referencias

https://www.postgresql.org/docs/9.1/ddl-inherit.html

https://www.postgresql.org/docs/9.1/ddl-partitioning.html

18
Optimización de queries
optimización
Ya que aprendiste muchas formas de seleccionar datos y estás empezando a
hacer SELECTs a través de múltiples tablas, es un buen momento para hablar
acerca de la eficiencia de tus consultas de SQL.
¿Qué tan rápido se ejecutan? y ¿podrían ejecutarse más rápido?

SQL es un lenguaje declarativo: cada consulta declara que queremos que haga el
motor de SQL, pero no dice cómo. Sin embargo, resulta que el cómo, el "plan", es lo
que afecta la eficiencia de las consultas, así que es bastante importante.

20
optimización
Consulta no optimizada

5 segundos x 20,000 usuarios = 100,000 segundos ~ 27 horas

21
Optimización - Identificar consultas Lentas
▸ Postgres
▸ Log_min_duration_statement
▹ Logs statements that have taken 500 milliseconds
▸ MySql
▹ Log-slow-admin-statements
▹ Log_queries_not_using_indexes
▸ Otras Herramients
▹ MRTG,MUNIN, CACTI

22
Optimización - ENtender lo que está pasando
“Utilizamos un método para entender el plan de la consulta”

▸ PostgreSQL : explain consulta

▸ MySQL: explain consulta
▸ MS-SQL: CTRL+M (include actual execution plan)
▸ Oracle: explain plan consulta

23
Optimización - CASO 1
▸ La tabla País posee índice
▸ La tabla Ciudad no posee índice

24
Optimización - ENtender lo que está pasando

25
Optimización - ENtender lo que está pasando
“Creamos el Índice en faltante el la tabla Ciudad para optimizarlo”

26
 Optimización - CASO 2

“En ambas consultas la diferencia importante es el

orden de aparición de id_producto y id_etiqueta”

27
Optimización - Caso 2

28
Optimización - CAS0 2
“Creamos el Índice en faltante id_etiqueta para optimizarlo”

29
 Optimización - Caso 3 - Subquery
Subquery: “Queremos saber el producto mas caro que vendimos”

30
 Optimización - Caso 3 - Subquery
Subquery: “Queremos saber el producto mas caro que vendimos”

31
 SOLUCIÓN DE OPTIMIZACIÓN PARA EL CASO 3
▸ Usar Joins siempre que sea posible, cuando no sea posible usa una consulta
anidada en el FROM Creando una tabla

▸ Evitar consulta anidadas en el SELECT ni en el WHERE

32
 Otros TIPS
▸ Hacer un buen modelo (normalizado) de base de datos (No incluido en este curso).
“Debe llevarse a la 5 Forma Normal.”
▸ Desnormalizar si hace necesidad
▹ Si una tabla tiene muchos campos que la mayoría son dejado en blanco (null)
▹ Entonces hacer una relación (1:1) [master::detalle] (más información en
memoria)
▸ Calcular datos que son utilizados mucho cada hora (siempre y cuando sea
posible).
▸ Utilizar los tipos de datos correctos (datos grandes → consume más espacio en
memoria→consultas más lentas)
33
Otros TIPS
“Nunca usar índices dentro de una función”

34
 eNTender INTERNAMENTE EL MANEJADOR de BD
Usar instrucciones específicas del motor de base de datos que utilicemos

35
 Concluimos
▸ Primero identificamos las consultas lentas
▸ Revisar el plan de ejecución de las consultas lentas (explain)
▸ Aplicar cualquier de las estrategias:
▹ Uso de indices
▹ Desnormalizar
▹ Uso de indices
▹ Tener en cuenta los tips vistos anteriormente.

36
Gracias!
Preguntas?

37