Pasos para optimizar una base de datos

Pasos para optimizar una base de datos

Cuántas veces hemos oído la frase “la base de datos va lenta” como si en el ciclo de vida de una petición que realiza un cliente hasta que obtiene los resultados solo existiera la base de datos (BD)

Muchas veces esta afirmación es cierta y la base de datos presenta, por decirlo suavemente, algún que otro dato problema de rendimiento, pero lo cierto es que más veces de lo que parece no todo es culpa de la BD, e incluso en ocasiones, es lo más sano que hay en el sistema.

En la optimización de una base de datos intervienen todos los elementos que forman parte del recorrido de una petición, es decir, cuando el usuario hace click en un enlace desencadena unos procesos de red, código y base de datos que hacen que a medida que realiza el recorrido y hasta que la información solicitada vuelve al usuario van sumando milisegundos hasta llegar a los segundos de demora que el usuario al final percibe.

La idea es optimizar todo este proceso para ir “arañando” milisegundos al todo el recorrido de una petición.

¿Cómo optimizamos una base de datos?

Primero hay que conocer el sistema, hay que estudiar y aprender cómo está construido el sistema que se quiere optimizar.

Difícilmente podremos arreglar algo que no conocemos. Después de conocer todos los elementos que intervienen en el recorrido de una petición tendremos que enfocarnos en tres áreas diferenciadas, actuar en cada una de ellas por separado nos ayudará a mejorar el rendimiento:

Servidores, redes: Una red bien dimensionada nos hará ganar velocidad, aquí hay que tener en cuenta entre otras cosas:

• Dimensionamiento de los servidores, no podemos tener en producción un servidor con 2 CPU y 2 GB de ram con todo al 100% 24×7. Los servidores deben de ir holgados en recursos.

• Separar las aplicaciones comunes en diferentes servidores.

• Configurar siempre que sea posible redes internas con IPs privadas, excepto servidores Web o balanceadores de carga.

• Utilizar CDN para imágenes y recursos estáticos

• En cloud utilizar zonas próximas a donde estáis ubicados y utilizar réplicas en diferentes zonas del mundo si la aplicación es global.

Código: Igual que la red y servidores, el código juega un papel importante en el rendimiento de todo el ciclo de vida de la aplicación y muy particularmente en el rendimiento de la BD.

Aquí hay que tener en cuenta cosas como:

• Cuando se utilicen ORMs como Doctrine o Illuminate intentar ejecutar las consultas construidas de forma manual, que no las genere el ORM, de esta forma se evita el tiempo invertido en construir la consulta.

• Nunca utilizar * y siempre poner un alias en las tablas. Por ejemplo esta consulta:

Select * from usuarios

El motor de base de datos no sabe que quieres y qué campos son de la tabla usuarios tendrá que identificar esos campos para realizar la consulta. Tiempo extra de procesamiento.

• Pedir solo los campos necesarios a la base de datos y no traerlos todos si no los necesitamos.

• Utilizar frameworks ligeros en la medida que sea posible, cuanto más código tenga el framework más tiempo de procesamiento.

• Cachear todo lo que sea posible.

Base de datos: Y llegamos al culpable, en teoría. Aquí también hay cosas que mirar y revisar indistintamente del motor de base de datos porque sirve para todos.

• Índices, es una obviedad pero hay que decirlo. Hay que indexar la BD correctamente e ir renovando esos índices con procesos nocturnos para que estén actualizados.

• Se que esto no va a gustar mucho pero evitar los UUID y/o varchars para las claves primarias y poner siempre ids numéricos, los números indexan más rápidamente que un alfanumérico, también se ordenan más rápidamente de los UUID.

• Relacionar las tablas con foreign key numérica, igual que en el anterior apartado evitar los UUID porque son mas lento.

• Utilizar cuando podáis procedimientos almacenados. Por múltiples motivos se gana en velocidad de procesamiento.

• Cuando las bases de datos ya son considerablemente grandes a veces es aconsejable desnormalizar la base de datos para evitar JOINS y sobre cargar las consultas.

Esto es un pequeño extracto de lo que se puede hacer para optimizar ya no solo una BD sino todo un conjunto de recursos y aplicaciones de la empresa.

Cada una de estas acciones por sí sola va a solucionar muy poco pero el conjunto de ellas hará que se note y se incremente la velocidad no solo de la base de datos sino también de todo el sistema. Tenemos que dejar de verlo todo por separado y empezar a pensar en un conjunto de elementos que es nuestra infraestructura tecnología y que todos los elementos que la componen influyen en los demás.

Que una aplicación vaya o se note lenta es una muy mala, muy mala experiencia de usuario.

Más artículos de Alex Arenols