Rendimiento de una base de datos
Técnicas de estimación para medir el rendimiento de la
base de datos:
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, si
diseñamos considerando lo que puede y no puede hacer el motor de base de datos
probablemente consigamos un buen rendimiento, cualquier sistema de
administración de Bases de Datos es distinto con respecto a los otros, lo que funciona
bien y es eficaz en Oracle ó PostgreSQL no debe ser lo que mayor rendimiento
ofrezca en 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.
Cuando
MySql encuentra un índice en una columna lo utiliza en lugar de hacer un
escaneo completo de la tabla (leer todos los registros de la tabla de manera
secuencial). Esto reduce los tiempos de CPU y las operaciones de
“lectura/escritura en disco”.
Para
verlo lo mejor es explicarlo con datos, comenzamos con una tabla que tiene 100
Bytes por registro y suponiendo que tenemos 100MB/segundo de velocidad de lectura
por lo que calculando llegamos a la conclusión de que podemos conseguir
1,000.000 de registros por segundo (Tablas tipo MyISAM).
Estimación de Rendimiento
Una
de las tareas principales del DBA es el monitoreo de rendimiento y afinamiento
de la base de datos. Sin embargo, la gestión de rendimiento de la mayoría de
las organizaciones es reactiva. Los problemas de rendimiento pueden ser
causados por cualquier componente de las TIC: servidores, red, SO, clientes o
base de datos. Poseer una sólida comprensión de la infraestructura de TI
permite a los DBA’s responder eficazmente cuando surgen problemas de
rendimiento.
Rendimiento
es la celeridad con la que la DBMS atiende la demanda de los usuarios. Cinco
factores que influyen en el rendimiento de base de datos:
•
Carga de trabajo.
•
Capacidad del computador
•
Recursos adicionales de hardware y software.
•
Optimización
•
Contención.
Un
código SQL pobremente ejecutado puede causar los siguientes problemas que
afectan al rendimiento:
•
Búsquedas secuenciales en las tablas.
•
La falta de índices adecuados.
•
Creación de índices inapropiados.
•
No utilizar los índices disponibles.
•
Estadísticas de base de datos no actualizadas.
•
Junturas de tablas en un orden no óptimo
Desde
la perspectiva de la optimización del rendimiento de bases de datos, el DBA se
concentrará en primer lugar en las causas más probables de los problemas de
rendimiento, como es el código SQL.
Encontrar
el código que produce los problemas es muy difícil ya que éste puede estar
escondido en uno de los cientos o incluso miles de programas, en alguna
aplicación o en una consulta de AdHoc.
Para
detectar en dónde están los problemas se deben utilizar herramientas de
monitoreo que vienen con las DBMS, también se pueden adquirir herramientas de
empresas independientes. Normalmente, en estas herramientas se califican a las
instrucciones SQL, en base a la cantidad de recursos que consumen, identifican
a los programas y usuarios que las ejecutan. La correcta codificación y puesta
a punto de sentencias SQL requiere de un gran esfuerzo. La estimación del
rendimiento de una aplicación no solo comprende el análisis del código SQL. La
aplicación debe ser revisada totalmente y no solo una parte con el fin de
aumentar el rendimiento. El análisis debe mostrar el efecto global de las
consultas y como afectan unas a otras. Crear un método de rendimiento seguro es
iterativo y se debe cooperar entre DBA, SA, y desarrolladores.
Tipos de Optimización del Rendimiento
Una
aplicación de base de datos puede afinarse en tres áreas:
1. Ajuste del sistema
El
DBMS puede y debe ser ajustado para asegurar un rendimiento óptimo. El software
de otros sistemas con los que interactúa el DBMS incluye: el sistema operativo,
software de red, sistemas de colas de mensajes, middleware y procesadores de
transacciones.
2. Ajuste de base de datos
El
rendimiento puede verse afectado por el diseño físico de la base de datos,
incluyendo la normalización, almacenamiento en disco, el número de tablas,
diseño de índices, y el uso de DDL y sus parámetros asociados.
LA
revisión de los índices es necesaria para evitar impactos negativos en la
modificación de datos.
3. Ajuste de las aplicaciones
Muchas
herramientas de terceras partes puede gestionar con eficacia el rendimiento de
las aplicaciones de base de datos de misión crítica:
•
Monitores de rendimiento.
•
Herramientas de estimación de rendimiento.
•
Herramientas de planificación de la capacidad.
•
Análisis de SQL y herramientas de ajuste.
Optimizar
el tiempo de consultas
Recomendación
para crear consultas
•
Revisar siempre el plan de ejecución de las consultas para que identifiques
como SQL está viendo la consulta y veas la manera de mejorar el rendimiento.
•
Tratar de no utilizar cursores, ya que impactan al rendimiento.
•
Sub-Consultas transfórmalas en “JOINS”. Muchas veces las sub-consultas con
sentencias “IN” se vuelven muy lentas.
•
Evitar consultas que generan bloqueos.
•
Evitar el uso de “NOT IN”, usar mejor “EXISTS” o “NO EXISTS”.
•
Evitar usar “SUBSTRING” dentro de un “WHERE”
•
Usar “ORDER BY” solo si es absolutamente necesario.
•
No usar el comando “GROUP BY” sin una función de agregación.
•
Consultar únicamente las filas y columnas requeridas. No usar un “SELECT”.
Disponer
de índices en los campos adecuados optimizará sus resultados:
•
Para mejorar una consulta (SELECT), hay que crear un índice sobre los campos
que son utilizados en las búsquedas (los que aparecen en las cláusulas WHERE o
JOIN).
•
Utilice índices sobre campos con valores únicos. Los índices funcionan peor si
el campo tiene valores duplicados.
•
Trate de que los índices sean cortos. Si indexa un campo de texto, evite
hacerlo sobre campos de longitud variable, y acorte siempre el tamaño del
índice a lo que considere más adecuado. Por ejemplo, si un campo CHAR tiene 200
caracteres y sabe que los valores se distinguen en los primeros 20 caracteres,
indexe sólo hasta dicho tamaño de campo. Ahorrará espacio y ganará velocidad de
respuesta.
•
No cree índices innecesarios. Estos se actualizan con cada cambio en la tabla
asociada y pueden ralentizar las modificaciones de la misma.
Bibliografía
