El arte de reducir costes y mejorar el rendimiento de grandes sistemas

De un correcto diseño del modelo de datos, de la gestión de la base de datos y de cómo los programas accedan y procesen dichos datos dependerá que un sistema informático sea estable, eficaz, seguro y rápido, evidentemente siempre que el hardware, las comunicaciones y la tecnología utilizada sea la adecuada.

Pero el objetivo no es únicamente que el sistema funcione correctamente y sin ningún tipo de errores, sino que el rendimiento sea óptimo. Cuando estamos ante grandes sistemas que realizan centenares o miles de operaciones por segundo ese rendimiento óptimo es esencial para mejorar tiempos de respuesta de aplicaciones, evitar colisiones, reducir consumo y a su vez ahorrar costes (en la mayoría de los casos basados en Millones de Instrucciones Por Segundo -MIPS-, Millones de Service Units –MSU-, etc).

Tomemos por ejemplo el gestor de bases de datos DB2, uno de los más utilizados en el entorno de grandes sistemas, y una de las especialidades de quien escribe estas líneas. Posiblemente las características más interesantes de DB2 sean la estabilidad, con más de 30 años en el mercado (la versión 1 vio la luz en el año 1983, la versión más reciente es la 11, y de media aparece una nueva versión cada tres años); la solidez dado que es utilizada por las mayores entidades de este pequeño planeta y en sistemas en donde un fallo o una indisponibilidad de información de una hora puede llegar a ser sinónimo de desastre, de pérdidas económicas y la mayoría de veces se convierte en noticia (imagine por un momento una caída de dos horas de un sistema de control de vuelos o de un sistema financiero); la capacidad demostrada de gestionar grandes volúmenes de información (un sistema puede contener hasta 65.217 bases de datos, a su vez una base de datos puede almacenar miles de tablas -hasta 32.767 objetos- y una tabla puede almacenar varios centenares de miles de millones de filas; hasta 16.384 Gb de información); y todo ello unido a una gran velocidad de proceso.

Imaginemos por un momento un proceso diario que trata las operaciones cuyo importe de la operación multiplicado por 10 coincide con una variable proporcionada. Teniendo en cuenta que desde el punto de vista lógico la condición de la instrucción SQL sería “WHERE IMPORTE * 10 = variable”, dicha construcción será considerada por el sistema como Stage 2, no utilizando un posible índice formado por la columna “Importe”. Si la convertimos en “WHERE IMPORTE = variable / 10” será considerada Stage 1, utilizará dicho índice, los resultados devueltos por la condición serán los mismos y la mejora de tiempo -en un ejemplo de varias decenas de millones de filas- será del 99,92%. Es decir, el proceso diario que anteriormente tardaba 20 minutos tras el cambio tardará algo menos de 1 segundo.

Posiblemente sea fácil detectar que 20 minutos para ese proceso diario es mucho tiempo, se analice, se acabe aplicando el cambio anterior y el proceso pase a tardar pocos segundos. Pero quizás pase más desapercibido -entre los miles de programas que acaban ejecutándose cada noche en una gran entidad- si ese proceso nocturno que se ejecuta de forma automático tarda 5 minutos. Tal vez durante mucho tiempo, o quizás de por vida, acabe tardando 5 minutos cuando podría estar tardando 0,24 segundos: se habrá asumido que 5 minutos es lo normal. Posiblemente nos sorprenda más ese tiempo/consumo adicional (traducido en muchas entidades por coste) del “no cambio” durante un año: 109.412 segundos, es decir, algo más de 30 horas.

Otro punto interesante, o más bien fascinante, por poner otro ejemplo, es el impacto negativo de los índices en el rendimiento de las operaciones de Insert, Delete y Update (en este último caso, si se modifican datos de las columnas incluidas en los índices). Posiblemente el consumo de dichos Inserts/Deletes/Updates, salvo que no se realicen masivamente en un momento determinado pase también desapercibido. Podríamos considerar como cifra tentativa que cada índice adicional empeorará el rendimiento de las operaciones indicadas anteriormente en un 30%.

Consideremos que el tiempo en realizar un Insert es de 0,1 milisegundos (es decir, el sistema bajo unas condiciones determinadas es capaz de realizar 10.000 inserts por segundo). Aunque la velocidad aparentemente es sorprendente, si nuestro sistema realiza a lo largo del día 90 millones de inserts en una tabla concreta, esta cantidad representará 9.000 segundos al día, es decir 2,5 horas que posiblemente pasen desapercibidas al estar repartidos a lo largo del día. Podríamos considerar que si la tabla tiene 3 índices más el tiempo por Insert pasará a ser -de forma aproximada- de 0,19 milisegundos, es decir, se habrá pasado de 9.000 a 17.100 segundos. Imaginemos por un momento que la aplicación necesita un índice adicional para un nuevo proceso que se ejecuta varias veces al año: este nuevo índice hará que el tiempo por Insert se incremente a 0,22 milisegundos, es decir, un impacto negativo de unas 275 horas al año. Aunque este ejemplo podría considerarse sencillo, sería necesario analizar el uso, coste, beneficio que proporciona, criticidad y un largo etcétera de ejes de cada uno de los índices así como si son técnicamente necesarios. Tal vez se crearon hace bastantes años y funcionalidades aparecidas en versiones más recientes (tales como Reverse Scan, Include Columns o muchas otras) los pueden hacer innecesarios hoy en día: podríamos prescindir de algunos de ellos sin que las aplicaciones que los utilizan sufran ningún impacto negativo, y por el contrario de forma automática mejore el rendimiento de dichos Inserts/Deletes y posiblemente Updates.

Estos no dejan de ser un par de ejemplos sencillos de oportunidades de optimización entre centenares de combinaciones más complejas: ¿es posible optimizar los objetos de las bases de datos y los accesos a la información?, ¿utilizan los procesos el camino más recto?, ¿reside en memoria la información más accedida?, ¿existen cuellos de botella, sobre todo en dispositivos de almacenamiento?, ¿se aplican correctamente las funcionalidades interesantes que ofrecen las nuevas versiones? Todo ello teniendo como común denominador miles de programas que acceden a datos, muchos de ellos con una alta criticidad, miles de tablas de datos, centenares de bases de datos y miles de índices.

Desde GFT se pone un gran énfasis en que se utilicen las mejores técnicas (ejemplo de ello son los 18 cursos de formación, siguiendo el ejemplo de DB2, realizados internamente a lo largo de este año y sobre esta base de datos), y se trabaja activamente en garantizar un óptimo rendimiento de las aplicaciones para mejorar el tiempo de respuesta de las mismas, ahorrar consumo y a su vez, y de forma directa, ahorrar costes. La cuestión sencilla es, ¿por qué utilizar una bombilla incandescente de 60 vatios si posiblemente una bombilla LED de 10 vatios proporciona el mismo servicio y gasta 6 veces menos?