Diapositiva 1

1
Universidad Nacional Autónoma de México
Posgrado en Ciencia e Ingeniería de la Computación
Bases de datos I
Tuning
Sergio Cárdenas
2
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.
3
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.
4
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.
5
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.
6
El número de operaciones de E/S puede reducirse
almacenando más datos en memoria, lo que
compensa el gasto extra.
7
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. L
a 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.
8
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.
9
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.
10
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.
11
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-cuent
a (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.
12
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
13
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.