“Tuning” Universidad Nacional Autónoma de México Bases de datos I Posgrado en Ciencia e Ingeniería de la Computación Bases de datos I “Tuning” Sergio Cárdenas

El tuning o también conocido como afinación de bases de datos describe un grupo de actividades utilizadas para optimizar y homogenizar el desempeño de éstas. Usualmente se cree que se trata de afinación de consultas, pero se refiere al diseño de archivos de la base de datos, selección del DBMS, sistema operativo y el CPU que utilizará el DBMS. El objetivo es maximizar el uso de los recursos del sistema para que el trabajo sea lo más eficiente y rápido posible. La mayoría de los sistemas están diseñados para administrar el trabajo eficientemente, pero es posible mejorar mucho el desempeño haciendo ajustes en la configuración de la base de datos y en el DBMS. Las aplicaciones pueden correr significativamente más rápido, afinando el rendimiento, ya que nos permite eliminar cuellos de botella y agregar el hardware apropiado.

Los administradores de bases de datos pueden ajustar los sistemas de bases de datos en tres niveles. El nivel inferior es el nivel de hardware (memoria, discos duros). El segundo nivel 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 tercer nivel es el nivel superior, incluye el esquema y las transacciones. Los tres niveles de ajuste interactúan entre sí; hay que considerarlos en conjunto al ajustar los sistemas. El conjunto exacto de los parámetros de los sistemas de bases de datos que pueden ajustarse depende de cada sistema concreto de éstas. Requisitos para una correcta afinación: Independencia física de los datos. Es la capacidad de modificar el esquema interno sin alterar el esquema conceptual, ni los programas de aplicación. Medios: Para supervisar automáticamente el uso de la base de datos con el fin de que puedan hacerse los ajustes necesarios.

El rendimiento de la mayor parte de los sistemas suele quedar limitado principalmente por el que presenta un componente o unos pocos, denominados cuellos de botella. La mejora del rendimiento de un componente que no sea un cuello de botella hace poco para mejorar la velocidad global del sistema. Por tanto, al ajustar un sistema, primero hay que intentar descubrir los cuellos de botella y luego eliminarlos mejorando el rendimiento de los componentes que los generan. El tiempo global de ejecución pueden modelarse como sistemas de colas. Cada transacción necesita varios servicios del sistema de bases de datos. Cada uno de los servicios tiene asociada una cola, y puede que las transacciones pequeñas pasen la mayor parte del tiempo esperando en las colas, especialmente en las colas de E/S de los discos.

Los logs de transacción y los espacios temporales son los mayores generadores de E/S. E/S es generalmente la más costosa operación en la base de datos, y es generalmente el primer cuello de botella en los resultados encontrados. Esto puede resolverse agregando más discos o usar sistemas RAID. Se debe tener en cuenta que el factor limitador no es la capacidad del disco, sino la velocidad con la que se puede tener acceso a los datos aleatorios. Las tablas y los índices pueden ser colocados en diferentes discos para balancear las E/S y así prevenir una cola de lectura.

El número de operaciones de E/S puede reducirse almacenando más datos en memoria, lo que compensa el gasto extra.

También se pueden ajustar los índices de un sistema para mejorar el rendimiento. Si las consultas constituyen el cuello de botella, se les poder acelerar creando los índices adecuados en las relaciones. Si lo constituyen las actualizaciones, puede que haya demasiados índices, que hay que actualizar cuando se actualizan las relaciones. La eliminación de índices talvez acelere algunas actualizaciones. La elección del tipo de índice también es importante. Algunos sistemas de bases de datos soportan diferentes tipos de índices. Otro parámetro ajustable es la posibilidad de hacer que un índice tenga agrupación. Sólo se puede hacer un índice con agrupación por relación, guardando la relación ordenada por los atributos del índice.

El uso de las vistas puede acelerar enormemente ciertos tipos de consultas, en especial las consultas de agregación. Las vistas deben emplearse con cuidado, dado que no sólo supone una sobrecarga de espacio almacenarlas sino que, lo que es más importante, su mantenimiento también supone una sobrecarga de tiempo. En el caso del mantenimiento inmediato de las vistas, si las actualizaciones de una transacción afectan a la vista, hay que actualizarla como parte de la misma transacción. Por tanto, puede que la transacción se ejecute más lentamente. En el caso del mantenimiento diferido de las vistas, la vista se actualiza posteriormente; hasta que se actualice puede que la vista sea inconsistente con las relaciones de la base de datos. El empleo del mantenimiento diferido reduce la carga de las transacciones de actualización.

Existen dos enfoques de la mejora del rendimiento de las transacciones: • Mejora de la orientación del conjunto • Reducción de la contención de los bloqueos Los optimizadores avanzados de hoy en día pueden transformar incluso las consultas mal escritas y ejecutarlas de manera eficiente Las consultas complejas que contienen subconsultas anidadas no las suelen optimizar muy bien. Aunque hay un índice que permita el acceso eficiente a las tuplas de una entidad dada, el empleo de varias consultas puede suponer una gran sobrecarga de comunicaciones en los sistemas cliente-servidor. El coste de comunicaciones puede reducirse empleando una sola consulta, capturando los resultados para el lado cliente y pasando por los resultados para hallar las tuplas necesarias.

Otra técnica muy utilizada en los sistemas cliente-servidor para reducir el coste de las comunicaciones y la compilación de SQL, es que las consultas se guarden en el servidor en forma de procedimientos almacenados, que pueden estar compilados anteriormente. Los clientes pueden invocar estos procedimientos en lugar de comunicar consultas enteras. Las transacciones de actualización de larga duración pueden crear problemas de rendimiento con los registros del sistema e incrementar el tiempo que éste tarda en recuperarse de las caídas. Para evitar estos problemas muchos sistemas de bases de datos imponen límites estrictos para el número de actualizaciones que puede llevar a cabo una sola transacción. Puede ayudar fraccionar las transacciones de actualización de gran tamaño en conjuntos de transacciones de actualización de menor tamaño siempre que sea posible.

Otra forma de afinación es optimizar los esquemas de bases de datos. Por ejemplo, considérese la relación cuenta, con el esquema cuenta (número-cuenta, nombre-sucursal, saldo) Donde número-cuenta es la llave. Dentro de las restricciones de las formas normales (BCNF y tercera forma normal) se puede dividir la relación cuenta en dos relaciones: sucursal-cuenta (número-cuenta, nombre-sucursal) saldo-cuenta (número-cuenta, saldo) Las dos representaciones son lógicamente equivalentes, dado que número-cuenta es la llave, pero tienen características de rendimiento diferentes. Si la mayor parte de los accesos a la información de la cuenta sólo examinan número-cuenta y saldo, pueden ejecutarse sobre la relación saldo-cuenta, y es probable que el acceso resulte algo más rápido, dado que no se captura el atributo nombre-sucursal.

Por el mismo motivo, cabrán en la memoria intermedia más tuplas de saldo-cuenta que las correspondientes tuplas de cuenta, lo que vuelve a generar un mayor rendimiento. Este efecto sería especialmente destacado si el atributo nombre- sucursal fuera de gran tamaño. Por tanto, un esquema que consistiera en sucursal-cuenta y saldo-cuenta sería preferible en este caso a otro que consistiera en la relación cuenta. Por otro lado, si la mayor parte de los accesos a la información de la cuenta necesitan tanto saldo como nombre-sucursal, el empleo de la relación cuenta será preferible, dado que se evitará el costo de la fusión de saldo-cuenta y sucursal-cuenta. Además, la sobrecarga de almacenamiento sería menor, ya que sólo habría una relación y no se replicaría el atributo número-cuenta. Otro truco para mejorar el rendimiento es guardar una relación desnormalizada, hay que realizar más esfuerzo para asegurarse de que la relación es consistente siempre que se realice una actualización. Las vistas pueden proporcionar las ventajas que ofrecen las relaciones desnormalizadas, al coste de algún almacenamiento extra

Para comprobar el rendimiento de un sistema de bases de datos incluso antes de instalarlo se puede crear un modelo de simulación del rendimiento de ese sistema. En la simulación se modela cada servicio, como la CPU, cada disco, la memoria intermedia y el control de concurrencia. En lugar de modelar los detalles de un servicio, puede que el modelo de simulación sólo capture algunos aspectos de cada uno, como el tiempo de servicio, es decir, el tiempo que tarda en acabar de procesar una solicitud una vez comenzado el procesamiento. Una vez creado el modelo de simulación para el procesamiento de las transacciones, el administrador del sistema puede ejecutar en él varias pruebas.