LABORATORIO 8. Optimización de Consultas SQL a través de herramientas del SMBD PostgreSQL GUÍA DE LABORATORIO Nº 8 Actividad de Proyecto No. 10: desarrollar mantenimiento preventivo, correctivo o proactivo para garantizar niveles de servicio requeridos por la organización.
Optimización de Consultas SQL a través de herramientas del SMBD PostgreSQL Estructura de contenidos. 1. Introducción...3 2. Objetivos...4 3. Consideraciones...5 4. Procedimiento...6 4.1. Manipulación de índices en PostgreSQL...6 4.1.1. Consulta de índices creados en PostgreSQL...7 4.1.2. Creación de índices...9 4.1.3. Modificación de índices existentes...11 4.1.4. Borrado de índices...12 4.2. Optimización de consultas en PostgreSQL...12 4.2.1. Afinamiento de PostgreSQL para ejecución de consultas... 13 4.2.2. Modificaciones del modelo de la base de datos...14 4.2.3. Optimización de consultas en PostgreSQL...14 5. Evidencias a entregar...19 2
1. Introducción. En este laboratorio se abordará el tema de la optimización de consultas con las herramientas del SMBD PostgreSQL con el fin de mejorar la eficiencia en los tiempos de respuesta de la base de datos usando los recursos disponibles, en algunas ocasiones la complejidad de la consultas puede ser causante de una baja en el rendimiento del sistema, por tal motivo este laboratorio está diseñado para el conocimiento de las herramientas y métodos para que las BD alcancen un alto grado de eficiencia. El tener el SMBD en óptimas condiciones depende en gran parte del diseño de la estructura y de los objetos incorporados a las Bases de Datos, el siguiente laboratorio abarca los temas de creación de índices, herramientas para la optimización y algunas recomendaciones en el uso de las base de datos. 3
2. Objetivos. Objetivo General. Aplicar técnicas para optimizar la estructura de la base de datos y las consultas, a partir del uso de herramientas de monitoreo para mejorar el rendimiento y garantizar consistencia e integridad en los datos. Objetivos Específicos. Usar los recursos para optimizar la base de datos, mediante las herramientas disponibles en el sistema. Utilizar herramientas para mejorar la definición y ejecución de consultas en la base de datos. Hacer uso de índices para mejorar el desempeño a nivel de ordenamientos y consultas en una Base de Datos. Analizar la estructura de la base de datos para mantener al mínimo las lecturas en disco y mejorar los tiempos de respuesta. 4
3. Consideraciones. Antes de realizar los procedimientos planteados en este laboratorio, se sugiere revisar los siguientes aspectos: Ítem Soporte Teórico Descripción Previo al desarrollo de este laboratorio debe haber revisado: AA10OA1.Optimización de Bases de Datos AA10OA2. Índices Manejo de sentencias SQL. Productos requeridos Base de datos de la Secretaria de Salud de la alcaldía de San Antonio del SENA o en su defecto el script de construcción de esta base de datos. Base de datos de la Secretaria de Hacienda de la alcaldía de San Antonio del SENA o en su defecto el script de construcción de esta base de datos. Script con 5 consultas a optimizar sobre la base de datos de la secretaría de Hacienda, suministrada en el laboratorio. Herramientas SW Se requiere tener instalada y configurada la Máquina virtual proporcionada en la plataforma, con el SMBD osgresql instalado. 5
4. Procedimiento. Este laboratorio está diseñado para abordar desde un enfoque practico la optimización de consultas en PostgreSQL, durante su desarrollo se abordaran los siguientes temas: manipulación de índices, herramientas para la optimización de la BD, recomendaciones para optimizar el diseño de bases de datos y consultas. A continuación se describen las acciones que se deben desarrollar como parte de este laboratorio: 4.1. Manipulación de índices en PostgreSQL. Ingrese al administrador gráfico pgadmin3 de PostgreSQL y conéctese a la base de datos secsalud, verifique que las tablas se encuentran correctamente creadas. En el explorador de objetos de la ventana principal del pgadmin3 seleccione la base de datos de la secsalud y pulse el botón el botón que lleva por icono una lupa con la sigla SQL, tal como lo indica la siguiente gráfica: Importante: Tenga en cuenta que en el explorador de objetos debe estar seleccionada la siguiente ruta: secsalud Schemas Public Tables, antes de pulsar el botón Execute Query. Imagen 1. Explorador de objetos 6
4.1.1. Consulta de índices creados en PostgreSQL. En la ventana que se carga, seleccione la pestaña SQL Editor y escriba la Sentencia No.1, posteriormente pulse el botón Execute query para ejecutar la sentencia. Sentencia No.1 SELECT indexname, tablename, indexdef FROM pg_indexes; Imagen 2: Consulta de índices Al ejecutar la sentencia que se encuentra en la Imagen 2, se visualiza un listado de los índices que existen en PostgreSQL, en el cual se puede determinar el nombre que recibe el índice, la tabla sobre la que esta definido y el tipo de índice. Los registros seleccionados en gris, corresponden a los índices que crea automáticamente PostgreSQL, cada vez que se define un campo como llave primaria PRIMARY KEY en cualquiera de las tablas de la base de datos de la secsalud. Los demás registros que muestra la consulta, corresponden a los índices que se crean sobre las tablas que hacen parte del catalogo de PostgreSQL, los cuales son necesarios para que el SMBD funcione correctamente. 7
Si se necesita obtener los índices creados sobre una tabla en particular, se ejecuta la siguiente sentencia especificando en ella el nombre de la tabla que se requiere: SELECT indexname, indexdef FROM pg_indexes WHERE tablename = nombre_tabla ; Escriba y ejecute en una ventana del SQL Editor la sentencia No.2 para obtener los índices que existen sobre la tabla hitorialpersona : Sentencia No.2 SELECT indexname, indexdef FROM pg_indexes WHERE tablename = historialpersona ; Imagen 3: Consulta de índices sobre una tabla En una ventana del SQL Editor escriba y ejecute la siguiente sentencia: Sentencia No.3: SELECT p.idpersona AS IDpersona, p.nombre, p.apellido, e.nombre AS EPS, ep.descripcion AS EstadoPersona, ta.descripcion FROM persona p INNER JOIN historialpersona hp ON hp.idpersona=p.idpersona INNER JOIN eps e ON e.ideps=hp.ideps INNER JOIN estadopersona ep ON ep.idestadopersona=hp.estadopersona INNER JOIN tipoafiliado ta ON ta.idtipoafiliado=hp.tipoafiliado ORDER BY p.apellido; 8
Después de ejecutar la sentencia No. 3 en el pgadmin3 se obtiene una salida en la sección Data Output, similar a la siguiente imagen, la cual permite observar en la parte inferior derecha que la ejecución de la consulta tomo 40 ms para recuperar 7 registros de la base de datos. 4.1.2. Creación de índices. Imagen 4. Salida de la sentencia No.3 La sintaxis general para crear índices en PostgreSQL es la siguiente: CREATE [ UNIQUE ] INDEX nombre_índice ON tabla [ USING nombre_acceso ] ( columna [ nombre_operador] [,...]) Identificar el campo de la tabla sobre el que se debe crear el índice, requiere de un análisis minucioso del diseño de la base de datos, en el que se contemplen la lógica y requerimientos para los que fue construida, esto con el fin de seleccionar el campo que ofrezca mayor rendimiento al momento de recuperar los datos por medio de las consultas. La sentencia SQL que se proporciona a continuación crea en la base de datos secsalud un índice llamado indicehp sobre el campo idpersona de la tabla historialpersona ; este tipo de índice permite indexar campos con valores que no son únicos o que se repiten dentro de la tabla. Escriba y ejecute en el SQL Editor la siguiente sentencia: Sentencia No.4: CREATE INDEX indicehp ON historialpersona (idpersona); 9
Imagen 5. Creación de índice En el modelo de la base de datos de la secalud, todas las transacciones en que esta involucrado el afiliado, generan un nuevo registro dentro de la tabla historialpersona el cual se identifica mediante un consecutivo único dentro de esta tabla, por esta razón, cualquier sentencia que incorpore una búsqueda por el campo idpersona resulta ineficiente de no implementar un índice, debido a que se deben recorrer todos los registros de la tabla para encontrar aquellos que corresponden al numero de identificación del afiliado. Después de crear el índice sobre el campo idpersona de la tabla historialpersona, ejecute de nuevo la sentencia No.3 que fue proporcionada anteriormente. Posteriormente observe la parte inferior derecha de la sección Data Output, en la que se encuentran los datos correspondientes a la ejecución de la consulta, la cual indica que tomo 20 ms para recuperar 7 registros de la base de datos; la mitad del tiempo que la consulta que se ejecutó antes de haber creado el índice. 10
Imagen 6: Sentencia No.3 después de crear el índice 4.1.3. Modificación de índices existentes. Mediante la ejecución de la sentencia No. 5 se cambiara el nombre del índice indicehp a idafiliado. Sentencia No.5: ALTER INDEX indicehp RENAME TO idafiliado; Imagen 7. Modificación del índice Consulte los índices que están creados sobre la tabla historialpersona, ejecutando de nuevo la Sentencia No.2 y verifique que el nombre del 11
índice indicehp ha sido cambiado a idafiliado. 4.1.4. Borrado de índices. Mediante la ejecución de la sentencia No.6 se borrara el índice que lleva por nombre idafiliado. Sentencia No.6: DROP INDEX idafiliado; Imagen 8. Borrado de índice Consulte los índices que están creados sobre la tabla historialpersona, ejecutando de nuevo la Sentencia No.2 para verificar que el índice idafiliado ha sido borrado. 4.2. Optimización de consultas en PostgreSQL. El proceso de optimización de consultas en PostgreSQL contempla tres aspectos que permiten mejorar el rendimiento del SMBD cuando se ejecuta consultas; el primero de ellos se enfoca en el afinamiento del SMBD para la ejecución de las consultas, el segundo aborda los cambios sobre el modelo de la base de datos y el tercero se centra en hacer mas eficiente la forma en que se escribe la consulta. Es importante aclarar que la estrategia seleccionada para la optimización de consultas puede contemplar uno o mas de los aspectos mencionados anteriormente. 12
4.2.1. Afinamiento de PostgreSQL para ejecución de consultas. El proceso de afinamiento de PostgreSQL para la ejecución de consultas consiste en detectar las consultas que consumen demasiados recursos cuando son ejecutadas; para ello es necesario que abra el archivo postgresql.conf que se encuentra en la siguiente ruta C:\dataPostgreSQL, posteriormente modifique los siguientes parámetros: log_min_duration_statement = 500; log_statement = all El parámetro log_min_duration_statement habilita el log de registro para las consultas que superan los 500 milisegundos durante su ejecución y log_statement controla el tipo de sentencias SQL sobre las que se desea realizar seguimiento dentro del log. Habilitar el log para realizar seguimiento de las consultas demoradas, permite analizar el comportamiento de las misma mediante la reproducción del estado problemático, esto con el fin de crear o borrar índices y reescribir la consulta si es el caso. Otro aspecto que se tiene en cuenta para afinar el rendimiento de PostgreSQL al ejecutar consultas, es aumentar la memoria compartida del mismo, para realizar este procedimiento se debe editar el parámetro shared_buffers dentro del archivo postgresql.conf Este parámetro requiere un valor mínimo de 128 KB para que postgres pueda iniciar, aunque el valor configurado por defecto es 32 MB; por razones de rendimiento este valor se debe calcular de la siguiente forma: shared_buffers = shared_buffers_default X max_connections shared_buffers = 128 KB X 1000 shared_buffers = 128.000 KB El tamaño de la memoria compartida para 1000 conexiones concurrentes al servidor de base de datos es de 128 MB. Recuerde que el valor del parámetro max_connections se definió en el Laboratorio 7 - concurrencia y bloqueos y este lo que determina es el numero máximo permitido de conexiones concurrentes al servidor de base de datos. 13
4.2.2. Modificaciones del modelo de la base de datos. En ocasiones el diseño de las bases de datos se realiza omitiendo algunos postulados básicos para la construcción de las mismas, de manera que se obtiene como resultado modelos que son poco óptimos para la consulta de los datos que se almacenan dentro de estos esquemas. Cuando suceden errores en el diseño que afectan directamente el rendimiento del sistema computacional durante el proceso de consulta, es inevitable que la solución de fondo a este problema implique realizar reingeniería sobre los esquemas de la base de datos, de forma que los nuevos diseños garanticen el acceso a los mismos, sin ir en detrimento del rendimiento. Existen otros casos en que los requerimientos del modelo de negocio cambian y el diseño inicial de la base de datos ya no responde a las necesidades actuales de la organización, en este tipo de situaciones es común que se empiecen a realizar maniobras sobre los datos que comprometen el rendimiento de la base de datos cuando se realizan acciones de consulta. En ambos casos la experticia del DBA es un factor que permite identificar rápidamente si el problema de rendimiento durante los procedimientos de consultas está asociado a un diseño deficiente o al cambio en los requerimientos de negocio, de cualquier forma se requieren habilidades para realizar modificaciones sobre el diseño de la base de datos. 4.2.3. Optimización de consultas en PostgreSQL. La sintaxis para utilizar el comando EXPLAIN es la siguiente: EXPLAIN [ ANALYZE ] [ VERBOSE ] sentencia Los parámetros que acepta se describen a continuación: ANALYZE: Llevar a cabo el comando y mostrar los tiempos de ejecución reales. VERBOSE: Incluir la lista de columnas de salida para cada nodo en el árbol del plan. 14
Sentencia: Cualquier sentencia SELECT, INSERT, UPDATE, DELETE, VALUES, EXECUTE, DECLARE, o CREATE TABLE AS, cuyo plan requiera analizar. El comando EXPLAIN muestra en pantalla el plan de ejecución que construye el planeador de PostgreSQL antes de ejecutar sentencias SQL, esto permite establecer anticipadamente el comportamiento que tendrán las tablas y los índices cuando se ejecute la sentencia. El costo estimado de ejecutar una sentencia SQL es uno de los datos mas significativos que proporciona el comando EXPLAIN, puesto que con esté, es factible analizar y realizar cambios sobre la forma en que esta escrita la sentencia, de manera que sea mas eficiente su ejecución. Escriba y ejecute en una ventana del SQL Editor la siguiente sentencia: Sentencia No.7: EXPLAIN SELECT p.idpersona AS IDpersona, p.nombre, p.apellido, e.nombre AS EPS, ep.descripcion AS EstadoPersona, ta.descripcion FROM persona p INNER JOIN historialpersona hp ON hp.idpersona=p.idpersona INNER JOIN eps e ON e.ideps=hp.ideps INNER JOIN estadopersona ep ON ep.idestadopersona=hp.estadopersona INNER JOIN tipoafiliado ta ON ta.idtipoafiliado=hp.tipoafiliado ORDER BY p.apellido; 15
Imagen 9: Resultado de ejecutar la Sentencia No.7 La imagen 9 muestra la captura de pantalla del pgadmin3 después ejecutar la sentencia No.9, en la cual se usa el comando EXPLAIN sobre una consulta que esta accediendo a la base de datos de la secsalud. En la imagen se observa el plan de ejecución que construye el planeador de postgres para ejecutar la sentencia; a continuación describimos cada uno de los datos suministrados de izquierda a derecha para la cada fila: 1. Costo de iniciación estimado antes de que la primer fila pueda ser devuelta. 2. Costo total estimado para devolver todas las filas. 3. Numero estimado de filas de salida. 4. Ancho promedio estimado de la filas de salida (en bytes). Estos mismo datos se repiten para cada uno de los elementos que aparecen en el plan de ejecución. Es importante entender que el costo de un nodo de nivel superior incluye el costo de todos sus nodos secundarios, por lo tanto la primera fila de la imagen contiene los datos calculados de todo el 16
plan de ejecución para esa sentencia. Usando el comando EXPLAIN en combinación de la opción ANALYZE se produce que la sentencia SQL además de ser calculada sea ejecutada realmente en postgres. Además esta muestra la duración total medida para cada nodo (en milisegundos) y el número total de filas devueltas realmente. Esto es útil para verificar si las estimaciones realizadas por el planeador mantienen proporción con las obtenidas en la realidad. Escriba y ejecute en una ventana del SQL Editor la siguiente sentencia: Sentencia No.8: EXPLAIN ANALYZE SELECT p.idpersona AS IDpersona, p.nombre, p.apellido, e.nombre AS EPS, ep.descripcion AS EstadoPersona, ta.descripcion FROM persona p INNER JOIN historialpersona hp ON hp.idpersona=p.idpersona INNER JOIN eps e ON e.ideps=hp.ideps INNER JOIN estadopersona ep ON ep.idestadopersona=hp.estadopersona INNER JOIN tipoafiliado ta ON ta.idtipoafiliado=hp.tipoafiliado ORDER BY p.apellido; 17
Imagen 10: Resultado de ejecutar la Sentencia No.8 18
5. Evidencias a entregar. La lista de evidencias para este laboratorio es: Archivo postgres.sql con los parámetros de gestión de consultas modificados. Documento de control de cambios de creación de índices. En este documento se deben exponer las mejoras a ser incorporadas a la Base de Datos de la secretaría de Salud de la alcaldía de San Antonio del Sena, detallando el comportamiento antes y después de crear índices. De igual forma se deben efectuar mediciones (tiempos de respuesta, Uso de memoria, etc.) y el análisis que permitan evidenciar la importancia de los cambios realizados presentándolos en el documento. Presentación electrónica que muestre las tareas de optimización de diez consultas SQL asociadas a la secretaría de Hacienda, de las cuales cinco (5) son suministradas en el laboratorio y las restantes deben ser propuestas por el aprendiz. Cada consulta debe ser exhibida en una diapositiva exponiendo el planteamiento original y la versión final producto de las recomendaciones dadas por las herramientas del SMBD. En la diapositiva también se debe documentar la mejora incorporada y justificar el por qué según su criterio. 19