Rendimiento de una base de datos

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.