En primer lugar, reconozcamos que tenemos un problema de rendimiento. Todos los datawarehouse tienen un problema de rendimiento. Ninguno va excesivamente rápido. Siempre se puede mejorar. Es más, la falta de problemas de rendimiento suele esconder un problema mucho mayor y de más difícil solución… la falta de uso del sistema.
Si has llegado hasta esta página intentando resolver los problemas de rendimiento de tu sistema Business Intelligence, lamento decirte que no encontrarás la respuesta en este post. La respuesta está en todos los demás: Modeliza correctamente, y el sistema funcionará como debe.
Personalmente, creo que la mejor estrategia para afrontar los problemas de lentitud pasa por monitorizar continuamente el sistema. Debemos conocer cuantas consultas se están ejecutando diariamente, y cuanto tiempo requiere cada consulta. Si hacemos esto, sabremos como de mal va el sistema, y podremos fijarnos objetivos. En el último proyecto datawarehouse que he participado, hubo un momento en el que 85 % de las consultas tardaban menos de 1 minuto, y sin embargo muchos usuarios se quejaban de la lentitud del sistema. El 5% de las consultas tardaban más de 30 minutos. Para mejorar la situación, analizamos diariamente estas consultas… en ocasiones eran problemas en la manera de hacer las consultas por parte de los usuarios, y otras veces era un problemas de modelización. Educando a los usuarios, y con pequeños cambios en el modelo dimensional pudimos ofrecer una mejora significativa a los usuarios. Menos del 1 % de las consultas seguían tardando más de 30 minutos. Afortunadamente, seguíamos teniendo problemas de rendimiento, porque lo contrario sería señal de que dejaron de utilizar el sistema :-)
Los problemas siempre son del software, del hardware, o del informático. El usuario nunca se equivoca. Distingo, pues, estas 3 causas de problemas de rendimiento:
- Dificultad de uso de la herramienta Business Intelligence, lo que provoca consultas incorrectas o sin sentido por parte de los usuarios
- Modelización deficiente (falta de agregados, falta de índices, etc.)
- Hardware insuficiente (el sistema debe dimensionarse en función del volumen a información a gestionar y el número de usuarios activos)
En particular, ante un problema de rendimiento, debe evitarse cometer el error número 3 de esta serie sobre cómo no construir un datawarehouse:
Error 3: Omitir las tablas agregadas y comprimir las tablas de dimension para afrontar los problemas de rendimiento.
Efectivamente, las tablas agregadas proporcionan una mejora inmediata (y en muchas ocasiones espectacular) en el rendimiento (siempre y cuando la herramienta de BI sea capaz de aprovecharse de estos agregados, que debe serlo). En primer lugar, deben considerarse mejoras en la modelización y descartar nuevas y caras inversiones en hardware.
Si el sistema no está bien modelizado, seguirá funcionando mal después de una ampliación de discos, de RAM o de CPU. La ampliación de hardware sólo puede justificarse ante un aumento del volumen de información a gestionar y/o en el número de usuarios del sistema.
También debo decir que el uso de tablas agregadas tiene un coste. Las tablas agregadas añaden complejidad al sistema, ya que son nuevos elementos que deberán mantenerse y actualizarse indefinidamente. Las tablas agregadas sólo son útiles si efectivamente se usan, y reducen considerablemente el número de registros de la tabla detallada.
