INFORME DE PRÁCTICA RENDIMIENTO
KARENTH LIETSEL VARGAS ROJAS
FUNDACIÓN UNIVERSITARIA JUAN DE CASTELLANOS
FACULTAD DE INGENIERÍA
INGENIERÍA DE SISTEMAS
TUNJA
2018
Informe de práctica rendimiento
Karenth Lietsel Vargas Rojas
Código: 1049644801
Presentado al docente
Mg. Julio Alejandro Pinzón
Docente Bases de Datos I
Fundación Universitaria Juan De Castellanos
Facultad De Ingeniería
Ingeniería de sistemas
Tunja
2018
TABLA DE CONTENIDO
INTRODUCCIÓN............................................................................................................................. 1
OBJETIVO GENERAL ................................................................................................................... 1
OBJETIVOS ESPECÍFICOS .......................................................................................................... 1
1. MER y su explicación ................................................................................................................. 2
Figura 1 modelo entidad relación ................................................................................................ 2
2. Localización de cuellos de botella............................................................................................... 4
a. Cuello de botella utilización en un base de datos .................................................................... 4
b. Eliminación cuellos de botella para el rendimiento de la base de datos.................................. 4
3. Parámetros ajustables en DBA .................................................................................................... 5
a. A nivel inferior ........................................................................................................................ 5
b. A nivel de la base de datos ...................................................................................................... 5
c. A nivel superior ....................................................................................................................... 5
a. Memorias intermedias vía Archivo de configuración: ............................................................ 6
b. Niveles de aislamiento vía SQL ............................................................................................ 10
c. Número de conexiones al motor vía Shell ............................................................................ 11
Postgres brinda una ....................................................................................................................... 11
d. Número de lock por transacción vía Archivo de configuración ............................................ 13
PostgreSQL proporciona varios modos de bloqueo para controlar el acceso concurrente a los
datos en tablas. Los bloqueos de consulta proporcionan una forma conveniente de obtener un
bloqueo de PostgreSQL que se aplica por completo, y no bloquea las escrituras en la tabla. ...... 13
5. Ajuste del esquema.................................................................................................................... 17
a. Circunstancias para llevar a cabo una desnormlaizacion en una database ............................ 17
b. Planteamiento del ejercicio de ajuste al esquema. ................................................................ 17
En nuestro MER consideramos una normalización en segunda forma en la tabla proveedor
(cod_prov, nom_prov, num_tel, dirección, cod_ciudad, ciudad) 1NF esta cambio a segunda
forma 2NF porque dada la clave primaria y el atributo que no era constituyente de la clave
primaria (cod_ciudad, ciudad), hará que el atributo no clave dependa de toda la clave primaria en
vez de solo una parte de ella. Ahora teniendo e en cuenta esto desmoralizaremos el modelo para
ver cuantos proveedores se encuentran en una ciudad. ................................................................. 17
c. Desarrollo del ejercicio de ajustes al esquema ...................................................................... 17
6. Ajuste de los índices .................................................................................................................. 19
a. Circunstancias para llevar a cabo un ajuste de los índices de la Base de Datos .................... 19
b. Planteamiento del ejercicio de ajuste de los índices.............................................................. 19
c. Desarrollo del ejercicio de ajuste de los índices.................................................................... 19
7. Ajuste de las transacciones ........................................................................................................ 20
a. Definición .............................................................................................................................. 20
b. Planteamiento del ejercicio utilizando Explain Analize........................................................ 21
c. Desarrollo del ejercicio utilizando Explain Analize .............................................................. 21
d. Explicación de resultados obtenidos. .................................................................................... 22
8. CONCLUSIONES .................................................................................................................... 24
9. BIBLIOGRAFÍA ....................................................................................................................... 24
INTRODUCCIÓN
Una base de datos es un “almacén” que nos permite guardar grandes cantidades de información de
forma organizada para que luego podamos encontrar y utilizar fácilmente, la base de datos suelen ser
una de las áreas potenciales de los cuellos de botellas que hacen que el rendimiento baje y no pueda
ejecutar correctamente los procesos. Por consiguiente, es crucial que la base de datos se ajuste
apropiadamente a la implementación dado esto se realiza una evaluación continua del rendimiento de
la bases de datos por medio de técnicas que miden el rendimiento, ayudando a minimizar los tiempos
de respuesta y a maximizar el rendimiento, obteniendo como resultado un rendimiento óptimo.
OBJETIVO GENERAL
Identificar la funcionalidad del rendimiento en una base de datos.
OBJETIVOS ESPECÍFICOS
Identificar que técnicas de estimación son favorables para el rendimiento de una base de datos.
Determinar los elementos influyentes en el bajo rendimiento en la base de datos.
1
1. MER y su explicación con el cual se desarrollará la práctica. Si se requiere cambiar el MER
para explicar algún punto se incluye el cambio en ítem de “Planteamiento del ejercicio”.
Figura 1 modelo entidad relación
Explicación
SISTEMA PARA INVENTARIOS
Una idea de negocio nace de una problemática, necesidad o querer mejorar algo ya existente en el
ámbito que desee desarrollar el emprendedor; la creación de una empresa requiere unos parámetros,
cómo estará conformada, normalizaciones y que función desempeñara cada área; ya sea área de
producción, área de recursos humanos, área de márquetin y área de finanzas y registro, estas cuatro
áreas son fundamentales para el funcionamiento de la empresa; el objetivo principal es favorecer el
área de contabilidad y registro implementando un sistema de información que nos permitirá conocer
la administración y control de los recursos de la organización productora de pan “Sofis pan”.
2
Investigación Empresarial
Esta empresa está ubicada en el municipio villa de Leyva; organización encargada de la fabricación,
manipulación y comercialización de productos de Cafetería, pastelería, galletería, y panadería.
Proceso de fabricación
Este proceso de producción se encarga de la transformación de recursos o factores productivos en
bienes o servicios, dando a conocer el producto final, en este caso el proceso de creación de pan y
derivados.
Proceso de manipulación
En la manipulación de alimentos se tiene contacto directo con los alimentos durante su preparación,
fabricación y transformación.
Proceso de comercialización
El proceso permite la movilización del producto hasta el consumidor final. En esta parte se realiza la
venta de los productos como desayunos, postres, lácteos, bebidas calientes, bebidas frías, panadería,
entre otros.
Problemática
La situación problema, es la falta de control en el manejo de los diferentes productos de compra o
venta por parte de la empresa, por lo tanto se necesita por medio de un sistema para inventarios, el
cual permitirá garantizar la administración de los bienes.
El inventario es, por lo general, el activo mayor en sus balances generales, y los gastos por inventarios,
llamados costo de mercancías vendidas, son usualmente el gasto mayor en el estado de resultados.
Esto es importante para el funcionamiento de la empresa y por lo tanto se requiere una solución
pronta.
Para iniciar la creación del sistema se debe identificar las identidades que trabajaremos.
La entidad producto
Esta entidad tendrá información como el código producto, descripción producto, cantidad producto,
y costo producto, pero internamente el producto tendrá cada uno de los componentes para su proceso,
a esto se le nombra materia prima. La materia prima o insumos es cada uno de los elementos que se
transforman e incorporan en el producto final.
Entidad factura
El producto puede contener una factura, que se puede considerar a un cliente en caso especial, por lo
tanto la factura contiene numeración de la factura, cantidad del producto, precio total y fecha. Un
producto puede aparecer en una factura y una factura debe contener uno o varios productos.
La relación entre producto y factura crea un detalle “producto has factura”, en donde aparecerá
específicamente la información como el precio unitario, precio total y cantidad del producto el cual
se requiere para tener el control del inventario.
La entidad Cliente
3
La factura se puede considerar siempre y cuando el cliente compre una cantidad alta de productos; el
cliente debe obtener una o varias facturas dependiendo de los productos que haya adquirido.
El cliente tiene información así como número de cliente, Nit, y razón social.
La entidad proveedor
Por cada proveedor habrá Código de proveedor, nombre proveedor, numero teléfono y dirección. Se
necesitará tener estos datos, porque el proveedor, puede brindar cada uno de los elementos o insumos
que debe tener un pedido, para la producción de productos de panadería(harina, huevos, sal, azúcar,
levadura, mantequilla, agua),cafetería (Café, azúcar, aromáticas, mezcladores, toallas desechables,
servilletas, platos, cubiertos y vasos desechables; filtros para cafetera, chocolate), pastelería y
galletería(Leche, harina, huevos, sal, azúcar, levadura, mantequilla, agua, esencias, crema de leche,
hojaldre, arequipe, chocolate, queso, bocadillo, jamón, uvas pasas, almendras, nueces, enmoscadas).
Un proveedor puede aparecer en uno o varios pedidos y uno o varios pedidos lo debe tener un
proveedor.
La entidad ciudad
La cuidad se desprende de la dirección encontrada en la entidad proveedor. Esta tendrá una lista de
ciudades con código de cuidad y nombre de la cuidad. Muchos proveedores requieren estar en una
ciudad y en una ciudad pueden estar uno o varios proveedores.
La entidad pedido
En el pedido habrá un código, cantidad, precio total del pedido y una fecha. Un pedido tiene que
constituirse de uno o varios insumos, el cual se requerirá de un proveedor; el insumo debe constar
de uno o varios pedidos, y un pedido debe aparecer en uno o varios proveedores.
Entidad insumo
El insumo muestra el código, nombre y cantidad total del insumo, los cuales manejaran la información
en relación con el pedido y el proveedor, teniendo en cuenta la relación; se crea un detalle
“insumo_has_pedido”, que contendrá una especificación de la administración de los pedidos
teniendo en cuenta precio total, precio unitario y cantidad de los pedidos. El proveedor puede generar
un pedido y el pedido debe tener por los menos uno o varios insumos.
2. Localización de cuellos de botella
a. Cuello de botella utilización en un base de datos
Un cuello de botella es un fenómeno donde el rendimiento o la capacidad de todo un sistema están
limitado por un único componente, por lo tanto es una disminución en el desempeño de la
aplicación, no una detención de la aplicación, es decir, disminuyen la velocidad de los procesos,
maximizando los tiempos de espera y limitando considerablemente el rendimiento o
productividad. (Sarco, 2009)
b. Eliminación cuellos de botella para el rendimiento de la base de datos El rendimiento del
sistema se puede mejorar identificando las razones por las cuales los cuellos de botella producen
dichas fallas, en SQL Server se encuentra las siguientes:
4
Mediante la supervisión de los tiempos de respuesta para las consultas utilizadas con
frecuencia, puede determinar si es necesario modificar la consulta o los índices de las tablas
donde es necesario ejecutar las consultas.
Mediante la supervisión de las consultas Transact-SQL cuando se ejecutan, puede determinar
si están escritas correctamente y si producen los resultados esperados.
Mediante la supervisión de los usuarios que intentan conectarse a una instancia de SQL
Server, puede determinar si la seguridad está configurada de forma correcta y probar las
aplicaciones o sistemas de desarrollo.
Un disco duro con baja velocidad lo cual provoca por supuesto lentitud a la hora de leer y
escribir en los distintos sectores del disco. (Chaves, 2013).
Solución: un disco dura más rápido o colocar la solución RAID más adecuada para nuestro
diseño de base de datos, generalmente se recomienda un sistema RAID 10 para nuestro archivo
log y nuestros archivos de índices mientras que se recomienda un sistema RAID 5 para nuestros
archivos de datos.
Poca memoria lo cual causa una excesiva paginación.
Solución: agregar más memoria para evitar la cantidad de paginación que tiene que realizar el
procesador.
Una utilización muy alta del procesador que generalmente es causada por tiempos demorados
durante la paginación.
Solución: Agregar más procesadores.
3. Parámetros ajustables en DBA
Los administradores de bases de datos pueden ajustar los sistemas de bases de datos en tres
niveles.
a. A nivel inferior
Es el nivel de hardware. Las opciones para el ajuste de los sistemas en este nivel incluyen
añadir discos o usar sistemas RAID (si la Entrada y salida de disco constituye un cuello de
botella), añadir más memoria si el tamaño de la memoria intermedia de disco constituye un
cuello de botella o aumentar la velocidad del procesador si el empleo de la CPU constituye
un cuello de botella. (Silberschatz, Korth, & Sudarshan, 2002).
b. A nivel de la base de datos
Consiste en los parámetros de los sistemas de bases de datos, como el tamaño de la memoria
intermedia y los intervalos de puntos de revisión. El conjunto exacto de los parámetros de los
sistemas de bases de datos que pueden ajustarse depende de cada sistema concreto de bases
de datos. La mayor parte de los manuales de los sistemas de bases de datos proporcionan
información sobre los parámetros del sistema de bases de datos que pueden ajustarse y sobre
el modo en que deben escogerse los valores de esos parámetros.
c. A nivel superior
Incluye el esquema y las transacciones. El administrador puede ajustar el diseño del esquema,
los índices que se crean y las transacciones que se ejecutan para mejorar el rendimiento. El
5
ajuste en este nivel es, comparativamente, independiente del sistema. (Silberschatz, Korth, &
Sudarshan, 2002).
4. Parámetros ajustables: Todos los nombres de los parámetros distinguen mayúsculas de
minúsculas, excepto los de tipo enumerado. Realizar ajustes a nivel de base de datos en
PostgreSQL puede hacerse por tres vías:
- Archivo de configuración
- SQL
- Shell
a. Memorias intermedias vía Archivo de configuración:
Figura2 Para comenzar con la modificación de los parámetros en el archivo de configuración,
realizamos un ingreso de datos en la tabla proveedor por medio de la cláusula insert, con esto se puede
visualizar un tiempo de ejecución de 94ms aun sin cambiar las propiedades del archivo.
6
Figura 3 Cambio del parámetro shared_buffers = 128M a 1024 MB, Este parámetro es de gran
importancia porque define el tamaño del buffer de memoria utilizado por PostgreSQL, esto tiene gran
efecto en el rendimiento de las consultas, no por aumentar este valor mucho tendremos mejor
respuesta, sino se debe tener en cuenta los Gbytes del servidor para utilizar un valor inicial de Gbytes,
así que en un servidor dedicado podemos empezar con un 25% del total de nuestra memoria.
Figura 4 Cambio del parámetro maintenance_work_mem = 64MB a 256MB Usada en operaciones
del tipo VACUUM, ANALYZE, CREATE INDEX, ALTER TABLE, ADD FOREIGN KEY. Su
7
valor dependerá mucho del tamaño de nuestras bases de datos, esto también tiene que ver con el
servidor y los bytes de memoria, ya que con esto se puede podemos usar 256MB como valor inicial.
Figura5 Cambio del parámetro effective_cache_size = 4GB a 204MB es usado por el planificador
para determinar si un plan de ejecución cabría o no en la RAM. Con un valor muy bajo, los índices
serían sub-utilizados. En un servidor dedicado, se podría partir de la mitad de la memoria instalada.
Figura 6 Cambio de parámetro checkpoint_segments = 3 a 64 Este parámetro es muy importante en
8
una base de datos con numerosas operaciones de escritura (insert,update,delete). Para empezar
podemos empezar con un valor de 64. En grandes databases con muchos Gbytes de datos escritos
podemos aumentar este valor hasta 128-256.
Figura 7 Cambio del parámetro max_connections = 100 Es el número maximo de clientes conectados
a la vez a nuestras bases de datos. Deberiamos de incrementar este valor en proporcion al número de
clientes concurrentes en nuestro cluster PostgreSQL. Un buen valor para empezar es el 100, esto va
a va a impactar el uso de memoria compartida (para casos de extrema alta concurrencia, considerar
uso de pool de conexiones un conjunto limitado de conexiones a una base de datos, que es manejado
por un servidor de aplicaciones de forma tal, que dichas conexiones pueden ser reutilizadas por los
diferentes usuarios).
9
Figura 8 Después del cambio de los parámetros en el archivo de configuración de postgres(
postgresqlconf) se determina que el tiempo de respuestas de la consulta se minimizo mostrando un
mejor rendimiento.
b. Niveles de aislamiento vía SQL:
Figura 9 Haciendo uso de una transacción por medio del nivel de aislamiento REPEATABLE-READ,
la cual lee todos los datos de forma coherente dentro de la misma transacción, teniendo en cuenta esto
10
se realizan las transiciones en las que se muestras la actualización y modificación del insumo además
de la comprobación del aumento en la cantidad del insumo.
Figura 10 Nuevamente realizamos la misma transacción y vemos que su tiempo de respuesta es menor
puesto que se realizaron las modificaciones en el servidor de configuración.
Nota: Los parámetros ajustables son los mismos que se modificaron en el numeral 4 apartado a en las
imágenes 2, 3, 4, 5,6, y 7.
c. Número de conexiones al motor vía Shell
Postgres brinda una Consola (sql Shell) para acceder a los servicios de la datbase, permitiendo facilitar
la forma en que se invocan o ejecutan órdenes y mandatos necesarios para que nuestro motor realice
tareas que necesitamos. (Portilla, 2016).
11
Figura 11 Cuando se carga la consola SQL Shell requiere una configuración para conectarse al
servidor de postgres, validando con ENTER los datos generados en el proceso de instalación: Server
[localhost] ,Database [postgres],Port [5432], Username [postgres], Contraseña para usuario
postgres.El cursor queda en el path postgres=# listo para el ingreso de códigos SQL, en este caso
seleccionamos con la línea select * from pg_settings name like ‘max_con%’ el número máximo de
conexiones concurrentes al motor de la database ,validándolo con enter para poder visualizarlas.
12
Figura 12 Cambio del número de conexiones de 100 a 10 por el comando alter system set
max_connections= 10;
Figura 13 Visualización de las conexiones vía Shell.- Max connections= 10/100.
d. Número de lock por transacción vía Archivo de configuración
PostgreSQL proporciona varios modos de bloqueo para controlar el acceso concurrente a los datos
en tablas. Los bloqueos de consulta proporcionan una forma conveniente de obtener un bloqueo de
PostgreSQL que se aplica por completo, y no bloquea las escrituras en la tabla. (Parker, 2013).
13
Figura 14 Consulta realizada a la tabla proveedor
Proveedores cuyos nombres estén en lista conformada por colcafe y Alqueria. La sentencia in sirve
para comprobar si un valor coincide o no con los elementos de una lista, esto nos devuelven los
valores pertinientes en un tiempo de respuesta de 32ms.
Figura 15 Cambio de la opracion log_lock_waits= off a on esto controla si se produce un mensaje de
registro cuando una sesión espera más tiempo que deadlock_timeout para adquirir un bloqueo. Esto
es útil para determinar si la espera de bloqueo está causando un rendimiento deficiente.
14
Figura 16 Propiedad lock_timeout = 12 ms establece el período de tiempo de espera de bloqueo.
Figura 17 Propiedad dealock_timeout = 1s es la cantidad de tiempo, en milisegundos, para esperar un
bloqueo antes de verificar si hay una condición de interbloqueo, esto lo tiene en cuenta la operación
log_lock_waits.
15
Figura 18 Propiedad max_locks_per_transaction = 20 La tabla de bloqueo compartido rastrea los
bloqueos en los objetos max_locks_per_transaction por lo tanto, no más de este muchos objetos
distintos pueden ser bloqueados en cualquier momento.
Figura 19 Realizamos la misma consulta propuesta en la imagen 14 en esta ejecuciones encontramos
que el tiempo de respuesta es de 31 ms, esto quiere decir que el rendimiento aumneto dado que las
consultas solamente en una tabla no cuentan con un lock, en cambio sí realizamos transacciones
individuales pueden bloquear más objetos siempre que los bloqueos de todas las transacciones estén
en la tabla de bloqueo. Esto no es la cantidad de filas que se pueden bloquear; ese valor es ilimitado
16
El valor predeterminado, 64, generalmente ha sido suficiente en las pruebas, pero es posible que
necesite aumentar este valor si tiene clientes que tocan muchas tablas diferentes en una única
transacción serializable obteniendo interrupciones y disminuyendo el rendimiento.
5. Ajuste del esquema
a. Circunstancias para llevar a cabo una desnormlaizacion en una database
Las reglas de normalización no consideran el rendimiento. En algunos casos, es necesario
considerar la desnormalización estrategia utilizada en una base de datos previamente
normalizada para aumentar su rendimiento. La idea detrás de ella es agregar datos redundantes
donde pensamos que nos ayudarán más. Podemos utilizar atributos adicionales en una tabla
existente, agregar nuevas tablas o incluso crear instancias de tablas existentes. El objetivo
habitual es disminuir el tiempo de ejecución de las consultas haciendo que los datos sean más
accesibles generando informes resumidos en tablas separadas. Hay algunas situaciones en las
que se debería pensar en desnormalización:
Mantenimiento de un histórico: los datos pueden cambiar con el tiempo y tenemos que
almacenar valores que eran válidos cuando se creó un registro. El nombre y apellido de
una persona puede cambiar, un cliente también puede cambiar su nombre comercial o
cualquier otro dato. Los detalles de ciertas consultas deben contener valores que eran
reales en el momento en que se generaron. No seríamos capaces de recrear los datos del
pasado correctamente si esto no es así. Podríamos resolver este problema agregando una
tabla que contiene el historial de estos cambios. Pero en este caso, una consulta podría
ser muy complicada.
Mejorar el rendimiento de las consultas: algunas consultas pueden utilizar varias tablas
para acceder a los datos que con frecuencia necesitamos. Piensa en una situación en la
que tuviéramos que unir 10 tablas para devolver el nombre de un cliente y los productos
que se vendieron. Algunas tablas también podían contener grandes cantidades de datos.
Aceleración de presentación de informes: si necesitamos algunas estadísticas con mucha
frecuencia, crearlas a partir de datos en vivo requiere mucho tiempo y puede afectar al
rendimiento general del sistema.
Tener precalculados valores que utilizamos con frecuencia: algunos valores es posible
que queremos tenerlos listos para no tener que generarlos con datos en vivo.
b. Planteamiento del ejercicio de ajuste al esquema.
En nuestro MER consideramos una normalización en segunda forma en la tabla proveedor
(cod_prov, nom_prov, num_tel, dirección, cod_ciudad, ciudad) 1NF esta cambio a segunda
forma 2NF porque dada la clave primaria y el atributo que no era constituyente de la clave
primaria (cod_ciudad, ciudad), hará que el atributo no clave dependa de toda la clave primaria
en vez de solo una parte de ella. Ahora teniendo e en cuenta esto desmoralizaremos el modelo
para ver cuantos proveedores se encuentran en una ciudad.
c. Desarrollo del ejercicio de ajustes al esquema
17
Figura 20 Consulta select de las tablas proveedor y ciudad se puede ilustrar la unión de forma
normal.
Figura 21 Por medio del join realizamos la desnormalizacion del modelo se realiza la unión de
la tabla proveedor y la tabla ciudad ,como la presentábamos antes de realizar la normalización
obteniendo un tiempo de respuesta de más óptimo en su rendimiento.
d. Explicación de resultados obtenidos.
Demostrando que incrementa el rendimiento luego del ajuste.
18
Aplicando las respectivas configuraciones en el servidor postgres, se determina un mejor
rendimiento, utilizando la sentencia Join en la cual desnormaliza las dos tablas en una
invirtiendo totalmente realizadas durante la normalización por razones de rendimiento.
Dado que en una tabla normalizada el tiempo puede ser mayor dependiendo de cuantos datos
e índices se encuentren para realizar consultas.
6. Ajuste de los índices
a. Circunstancias para llevar a cabo un ajuste de los índices de la Base de Datos para mejorar el
rendimiento.
Los índices son estructuras de datos que permiten seleccionar y clasificar rápidamente las filas
en una tabla de base de datos. Facilitan la recuperación más rápida de datos al proporcionar
búsquedas aleatorias y un fácil acceso a registros ordenados.
El uso de índices a veces puede ser contraproducente. Por ejemplo, si las tablas son
frecuentemente afectadas por sentencias INSERT, UPDATE o DELETE, su rendimiento general
podría disminuir porque los índices deben modificarse después de esas operaciones. Cuando se
necesite realizar una sola inserción de un lote grande, la eliminación temporal de los índices
puede acelerar el proceso; Sin embargo, se debe tener en cuenta que al hacerlo afectará a todas
las consultas que se ejecuten en las tablas afectadas, por lo que sólo debe hacer esto cuando tiene
más de un millón de filas de datos que insertar. (rcanessa, 2016)
b. Planteamiento del ejercicio de ajuste de los índices.
Crear un índice por medio del atributo cant_prod de la tabla factura donde sea menor de 50 la
cantidad del producto comercializado a los clientes.
c. Desarrollo del ejercicio de ajuste de los índices (incluya pantallazos de las sentencias SQL que
se ejecutan y los resultados que generaron dichas sentencias).
19
Figura 22 Consulta realizada a las tablas cliente y factura donde se visualiza los valores de la cantidad
del producto menores a 50 y sus clientes.
Figura 23 Creación del índice index_factura por medio del atributo cant_prod con la cláusula create
index y la consulta anteriormente propuesta en la imagen 22.
d. Explicación de resultados obtenidos.
En la imagen 22 se realiza una consulta que en su tiempo de ejecución demora 19 ms, como
queremos ver si el rendimiento se maximiza o se minimiza creamos un índice sobre un atributo,
luego de esto, se genera la misma consulta observando que el tiempo de respuesta es de 11 ms, lo
anterior describe que el rendimiento obtuvo una mejoría ya que las tablas no contiene una gran
cantidad de datos, si se requiere crear un índice con la interacción de varias tablas y un gran bloque
de datos, el rendimiento seria bajo, por lo que el tiempo de ejecución aumentaría por la búsqueda
de la información.
7. Ajuste de las transacciones – Uso de Explain Analize
a. Definición
Un plan de ejecución PostgreSQL se obtiene usando el comando explain an-tes de la sentencia
SQL., este comando muestra el plan de ejecución que genera el planificador PostgreSQL para la
instrucción suministrada. El plan de ejecución muestra cómo se analizarán las tablas a las que se
hace referencia en la declaración (escaneo secuencial simple, escaneo de índice, etc.) y si se hace
referencia a varias tablas, qué algoritmos de combinación se usarán para reunir las filas
requeridas de cada una tabla de entrada, también se puede realizar por medio de la pantalla
20
principal pgAdmin de postgresql en la herramienta Query donde ejecutamos los comandos SQL
arbitrarios, en esta parte encontramos otra herramienta explain query que permite realizar el plan
o explicación de consulta. (postgresql, 1996). Elegir el plan adecuado para que coincida con la
estructura de consulta y las propiedades de los datos es absolutamente crítico para un buen
rendimiento, por lo que el sistema incluye un planificador La estructura de un plan de consulta
es un árbol de nodos de plan.
b. Planteamiento del ejercicio utilizando Explain Analize
Mostrar la lista de insumos en los pedidos realizados por el proveedor Duitama.
c. Desarrollo del ejercicio utilizando Explain Analize
Imagen 24 Consulta realiza a las tablas, insumo, insumo_has_pedido, pedido, proveedor, ciudad para
buscar la lista de los insumos de los proveedores de la ciudad de Duitama.
21
Imagen 25 Resultado del explain query de la consulta.
d. Explicación de resultados obtenidos.
La estructura de un plan de consulta es un árbol de nodos de plan Los nodos en el nivel inferior del
árbol son nodos de exploración: devuelven las filas sin procesar de una tabla. Existen diferentes tipos
de nodos de escaneo para diferentes métodos de acceso a la tabla: escaneos secuenciales, escaneos de
índice y escaneos de índice de mapa de bits. También hay fuentes de filas que no son de tabla, como
VALUES cláusulas y funciones de devolución de conjuntos FROM, que tienen sus propios tipos de
nodos de exploración. Si la consulta requiere unir, agregar, ordenar u otras operaciones en las filas
sin procesar, habrá nodos adicionales sobre los nodos del análisis para realizar estas operaciones. De
nuevo, generalmente hay más de una manera posible de realizar estas operaciones, por lo que también
pueden aparecer diferentes tipos de nodos.complejo que intenta elegir buenos planes, dado esto las
funciones presentadas y sus resultados se explicaran a continuación:
El nombre de la operación HashAggregate usa una tabla hash temporal para agrupar los registros.
La operación HashAggregate no requiere un conjunto de datos preordenado; en su lugar usa una gran
cantidad de memoria para materializar el resultado intermedio (sin pipeline, es decir, sin tener que
pasar por una transformación un flujo de datos siendo la entrada de cada una la salida de la anterior)de
cualquier forma, la salida no está ordenada.
Los resultados de la ejecución de la operación HashAggregate (cost=53.07..53.15 rows=8
width=76)son el coste asociado, la estimación del número de filas y la anchura de la fila esperada.
La parte más crítica de la pantalla es el costo estimado de ejecución de la sentencia, que es la
suposición del planificador sobre cuánto tiempo llevará ejecutar la declaración (medida en unidades
de captaciones de página de disco). En realidad, se muestran dos números: el tiempo de inicio antes
de que se pueda devolver la primera fila 53.07, y el tiempo total para devolver todas las filas 53.15,
la estimación del número de filas es sólo el valor que se muestra en ambas partes, tanto en la cantidad
estimada como en la real eso permite encontrar con rapidez las estimaciones incorrectas de
22
cardinalidad, es decir el grado de participación de las entidades en una relación y la anchura de filas
esperadas es el tamaño de las filas generadas por el nodo del plan (en bytes) tomando como referencia
la anchura del elemento o caracter contenedor, básicamente, cada fila devuelta tendrá 76 bytes. Esto
se puede ver en las operaciones nested loop,has cond, Seq sacan, hash,seqsacan on ciudad, index sacn
usig ifx pedio on pedido, index scan using ifk dee on insumo has pedido y index scan using insumo
pkey on insumo pero con diferentes valores ya que realiza formas diferentes de búsqueda.
Nested loop esta operación une dos tablas es buscar el resultado desde una tabla y después
seleccionar la otra tabla por cada fila de la primera, proporciona un buen rendimiento si la sentencia
guía devuelve un resultado pequeño. Por otra parte, el optimizador podría escoger un algoritmo de
unión totalmente diferente, como un “hash join” (descrito en la próxima sección), pero eso solo sería
posible si la aplicación usara una unión para avisar a la base de datos sobre qué datos se necesitan
realmente.
La unión hash o Has carga los registros candidatos desde un lado de la unión, dentro de la tabla hash
(marcado con Hash dentro del plan), los cuales se prueban, para cada registro, contra el otro lado de
la unión. Un enfoque bastante diferente para optimizar el rendimiento de una unión “hash join” es
minimizar el tamaño de la tabla hash. Este método funciona porque una unión “hash join” óptima es
posible solamente si la tabla hash entera cabe en memoria. El optimizador utilizará automáticamente
el lado más pequeño de la unión para la tabla hash.
Has cond acceder a sus datos más rápidamente por medio de la unión delos índices de la tabla
provvedor y la tabla ciudad
Seq scan (escaneos secuenciales) Este plan significa que Postgres leerá toda la tabla para encontrar
lo que estamos buscando, es decir, la consulta. Ese enfoque parece ineficiente dado el índice que ya
tenemos. Seq Scan escanea la relación (ciudad) entera tal y como se almacena en disco (como TABLE
ACCESS FULL).
Filter es bastante útil cuando desea contar los registros específicos al ejecutar un grupo, proporciona
una mejor manera de tratar con las funciones.Index Scan
Index Scan realiza el recorrido del B-tree, lee todos los nodos hoja para encontrar todas las entradas
que coincidan y recupera los datos correspondientes de la tabla usando la llave foránea en la tabla
pedido.
Index cond El nodo del plan secundario visita un índice de la tabla proveedor para encontrar las
ubicaciones de las filas que coinciden con la condición del índice (proveedor cod prov=
proveedor.cod prov), y luego el nodo del plan superior en realidad obtiene esas filas de la tabla.
Index Scan Usa la llave foránea en la tabla detalle insumo has pedido haciendo un tratamiento de
la otra condición como un filtro, esto mismo lo va a realizar con Index cond pedido cod pedido=.cod
pedido visita el índice, Index scan usando la llave foránea insumo relizando otro tratamiento de la
ondicion filtro index con y por ultimo Index cod insumo= insum has pedido.insumo cod insumo
asumiendo el último plan a comprobación de este índice. Tod esto lo debe realizar si hay índices en
varias columnas a las que se hace referencia en WHERE el planificador deberá visitar ambos índices
23
ejecutando hasta su finalización costo total y el recuento de filas y ancho dado por terminado el
análisis de planificación.
8. CONCLUSIONES
Es realmente fundamental entender cómo el rendimiento afecta a una base de datos por medio
de los cuellos de botellas y las formas de solución como los parámetros de ajustamiento que
ayudan a maximizar el desempeño del rendimiento en el tiempo de respuesta de las interacciones
con la database ,esto es de suma importancia a la hora de acceder información y realizar cambios
para superar con creces las necesidades de rendimiento
9. BIBLIOGRAFÍA
Chaves, O. (17 de Abril de 2013). chavez-atienzo-2013.blogspot.com.co. Obtenido de chavez-
atienzo-2013.blogspot.com.co: http://chavez-atienzo-
2013.blogspot.com.co/2013/04/rendimiento-de-una-base-de-datos.html
Diaz, A. (5 de Septiembre de 2009). highscalability.wordpress.com. Obtenido de
highscalability.wordpress.com:
https://highscalability.wordpress.com/2009/09/05/cuellos-de-botella-en-sqlserver/
24
Parker, D. (7 de Noviembre de 2013). hashrocket.com. Obtenido de hashrocket.com:
https://hashrocket.com/blog/posts/advisory-locks-in-postgres
Portilla, L. (26 de Abril de 2016). www.unipamplona.edu.co. Obtenido de
www.unipamplona.edu.co:
http://www.unipamplona.edu.co/unipamplona/portalIG/home_74/recursos/administraci
on-bases-de-datos/16052015/t4_shell.jsp
postgresql. (n/a de n/a de 1996). www.postgresql.org. Obtenido de www.postgresql.org:
https://www.postgresql.org/docs/9.1/static/using-explain.html
rcanessa. (13 de Mayo de 2016). internetrcc.com. Obtenido de internetrcc.com:
https://internetrcc.com/2017/07/como-mejorar-rendimiento-bases-de-datos/
Sarco, J. P. (14 de Agosto de 2009). Testing en Español. Obtenido de Testing en Español:
https://josepablosarco.wordpress.com/2009/08/14/cuellos-de-botella-bottlenecks/
Silberschatz, A., Korth, H. F., & Sudarshan, S. (2002). FUNDAMENTOS DE BASES DE DATOS. Madrid:
McGRAW-HILL.
Winand, M. (12 de Mayo de 2010). use-the-index-luke.com. Obtenido de use-the-index-luke.com:
https://use-the-index-luke.com/es/sql/plan-de-ejecucion/postgresql/operaciones
25
