Técnicas de estimación para
medir el rendimiento de la base de datos
La evaluación continua del rendimiento de la base de datos
ayuda a minimizar los tiempos de respuesta y a maximizar el rendimiento,
obteniendo como resultado un rendimiento óptimo. El tráfico de red, la E/S de
disco y el uso de la CPU eficientes son factores clave para obtener un buen
rendimiento. Es necesario analizar a fondo los requisitos de las aplicaciones,
comprender la estructura lógica y física de los datos, evaluar el uso de la
base de datos y negociar contrapartidas, como el procesamiento de transacciones
en línea (OLTP) frente a los sistemas de ayuda a la toma de decisiones.
Las condiciones cambiantes se traducen en cambios en el
rendimiento. En sus evaluaciones, los cambios de rendimiento se aprecian a
medida que el número de usuarios aumenta, los métodos de acceso y conexión de
los usuarios cambian, el contenido de la base de datos crece, las aplicaciones
cliente cambian, los datos de las aplicaciones cambian, las consultas son más
complejas y el tráfico de red crece. Con la ayuda de las herramientas de SQL
Server para supervisar el rendimiento, puede asociar algunos cambios del
rendimiento con las condiciones cambiantes y las consultas complejas. A
continuación se muestran algunos escenarios a modo de ejemplo:
• 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.
El tiempo de respuesta se mide como el tiempo necesario para
devolver la primera fila del conjunto de resultados al usuario, en forma de
confirmación visual de que se está procesando una consulta. El rendimiento es
el número total de consultas controladas por el servidor durante un periodo
determinado.
A medida que aumenta el número de usuarios, aumenta la
competencia para obtener recursos de un servidor, y esto hace que el tiempo de
respuesta aumente y el rendimiento global disminuya.
Si trabajas habitualmente con MySQL probablemente habrás
escuchado queMySql no es la elección acertada para manejar tablas con mas de
1,000.000 de registros.
Pero entonces porque MySql es el motor de compañías como
Google, Yahoo o Technorati,
El motivo de este gran rendimiento es que estas tablas que
tienen cientos de millones de registros están diseñadas y entendidas para
trabajar con MySql.
Por ello para trabajar con tablas muy grandes debemos tener
en cuenta tres claves: Buffers, Índices y Consultas.
Buffers
Un buffer es una ubicación de la memoria reservada para el
almacenamiento temporal de información digital.
La primera cosa que deberíamos tener muy clara es el hecho
de que hay una gran diferencia entre “Datos que están en memoria” y “Datos que
no están en memoria”.
Pongamos que comenzamos con un tamaño de memoria y notamos
un descenso gradual del rendimiento porque la base de datos está creciendo, la
solución sería asegurarnos que tenemos memoria suficiente para el volumen de
datos que estamos utilizando.
Índices
Los índices son usados para encontrar rápidamente los
registros que tengan un determinado valor en alguna de sus columnas. Sin un
índice, MySql tiene que iniciar una búsqueda por el primer registro yleer toda
la tabla para encontrar los registros relevantes.
Un error común es pensar que los índices no afectan en
tablas con poco volumen de datos, aún en tablas pequeñas (1.000 registros) es
por lo menos 100 veces más rápido leer datos utilizando un índice, sin este
índice estaríamos haciendo una lectura secuencial.
Por lo tanto queda claro que los índices son realmente
eficaces para acelerar el acceso a datos.
Consultas
La optimización de las consultas podría ser el punto más
extenso de los tres por la gran variedad de posibilidades que tenemos a la hora
de optimizar consultas.
Puedes conseguir que MySQL rinda a buen rendimiento con
grandes cantidades de datos pero para ello debes tener en cuenta sus
limitaciones y saber cuales son las características que ofrecen mejor
rendimiento.
Rendimiento transaccional
Se debe comprobar que el SGBD puede efectuar la cantidad
necesaria de transacciones por unidad de tiempo, para proporcionar a los
usuarios un tiempo de respuesta adecuado. En general, este punto es difícil de
definir teóricamente. En primer lugar, porque la información necesaria para
calcular la carga de transacciones que deberá soportar el sistema, es compleja
y difícil de obtener y, en segundo lugar, porque las medidas de transacciones
por segundo, que ofrecen los distintos fabricantes, no siempre son comparables.
Además, el rendimiento de un mismo SGBD es ampliamente
variable, según las características de la máquina en la que esté instalado
(capacidad y velocidad de los discos, cantidad de memoria, potencia de la UCP,
etc).
Por todo ello, lo más conveniente es diferir la resolución
sobre este punto, hasta que se pueda comprobar experimentalmente realizando una
prueba en la propia instalación.
A pesar de lo comentado, existen varias pruebas de
rendimiento (benchmark) estándar que ofrecen datos útiles. Los más interesantes
para SGBDs, son los del Transaction Processing Performance Council, organismo
fundado en 1988, al que pertenecen más de cuarenta fabricantes de plataformas
físicas y lógicas de bases de datos, que ha definido especificaciones de
benchmarks estándar para sistemas de proceso de transacciones en entornos
comerciales.
A continuación, se relacionan dichas pruebas de rendimiento:
Técnicas de estimación del tiempo de respuesta
Componentes del tiempo de respuesta de la base de datos
El tiempo que tarda el DB2 en preocsar una petición SQL se
divide en:
1. Tiempo de ejecución de las instrucciones correspondientes,
es decir, tiempo de consumo del procesador(CPU)
2. Tiempo esperando algun suceso. Aquí puede habir multiples
causas, pero las mas importantes y comunes son dos:
a) Tiempo de espera de las operaciones de entrada / salida,
es decir, espera por los accesos a disco.
b) Tiempo de espera por algun recurso que esta bloqueado.
Estos tiempos de espera los registra el DB2 Performance Monitos en el epígrafe
de tiempos de clase 3.
En resumen, para evaluar el diseño físico, como ya hemos
dicho, hay que estimar el rendimiento que vamos a obtener. Esto implica estimar
el tiempo de respuesta de los programas en sus peticiones de datos, para lo
cual simplificaremos considerando solamente los tres componentes citados: CPU,
E/S y bloqueos.
http://www.tufuncion.com/optimizar_MySQL
http://msdn.microsoft.com/es-mx/library/ms179440(v=sql.105).aspx
http://www.ongei.gob.pe/publica/metodologias/Lib5083/cap2063.HTM
Libro:
Bases de datos relacionales: diseño físico: Orientada al DB2
para z/OS de IBM)
By Enrique Rivero
Cornelio, Carlos Guardia Rivas, José Carlos Reig Hernández
No hay comentarios:
Publicar un comentario