Hablando un poco de técnicas de optimización, hoy vengo a hablar un poco de dos funcionalidades muy similares dentro de la herramienta. Básicas para cualquier usuario, y aún vale destacar su importancia, similitudes, diferencias y también sus riesgos, ya que ponen en riesgo la veracidad de la información que se muestra. Hoy, cara a cara y frente a frente, les traigo el primer combate de la temporada: Caches vs History list.
Quizás muchos han escuchado nombrar alguno, ambos o ninguno, pero la cantidad de usuarios que veo re-ejecutar una y otra vez los mismos reportes, incluso muchos quejándose de las demoras que conlleva, es mucho mayor de lo que se imaginan. Y ya que estamos con la temática, vamos a presentar a los contrincantes…
Habrán notado que, en el home de cada proyecto, por defecto tenemos (además de shared reports, my reports, etc) un directorio llamado “History List”
Este es un repositorio de reportes y documentos pre-ejecutados. ¿A que me refiero con eso? Pues sencillo. MicroStrategy nos da la opción de al ejecutar algún objeto, en lugar de quedar esperando hasta que termine lo enviamos al “history list”.
Cuando enviamos un reporte al history list (o historial), este se sigue ejecutando por detrás y queda almacenado en el historial. De modo que cuando queramos ir a revisar el resultado, podemos ir a la carpeta y allí encontraremos el reporte ya ejecutado.
Este tipo de acciones es vital a la hora de ejecutar informes que tardan mucho en ejecutarse, donde se corre el riesgo que haya algún timeout en la conexión y se pierda lo que se esta ejecutando. Cuando enviamos un informe o un documento al historial, este se continuará ejecutando hasta que termine sin importar si nos desconectamos, se corta la sesión o continuamos trabajando con otros reportes.
Lo importante aquí es entender que, al enviar un informe al historial, es como si le estuviesen haciendo una foto totalmente independiente al resto de los objetos. Es decir, si ejecutan un documento y lo envían a historial, luego pueden tomar el documento y modificarlo, borrarlo o cambiarle la información que muestra. Pero cuando vayan al historial, la versión que encontrarán es exactamente la que existía cuando hicieron el click en primer lugar.
Y es por esto que cada mensaje de historial (es así como se llama cada objeto que enviamos) tiene su fecha y hora. Si envían un mismo reporte o documento a historial dos veces, en lugar de sobrescribirse se crearán dos registros distintos (es posible definir un límite de registros por reporte, pero estamos hablando de forma genérica).
Si vamos a la definición directa, “Una caché es un conjunto de resultados que se almacena en un sistema para mejorar el tiempo de respuesta en solicitudes futuras.”
Microstrategy tiene distintos tipos de caché, pero en este momento nos enfocaremos sólo en el cache de reportes, y ya en un futuro entraré en detalle de cómo funcionan los distintos tipos de caché en la herramienta.
Con el almacenamiento en caché, los usuarios pueden recuperar resultados guardados en archivos en el Intelligence Server en lugar de volver a ejecutar consultas en una base de datos. Esto significa, que al ejecutar un informe que tiene una cache asociada, en lugar de ejecutar el reporte y esperar hasta que finalice, la información sale prácticamente al instante.
La cache se crea cuando el reporte se ejecuta por primera vez. Aquí, el informe demora lo que tarda en generarse, pero genera una cache, por lo que la próxima vez que se ejecute en lugar de hacer la consulta contra el warehouse, se mostrará directamente el resultado almacenado.
Lo cierto es que, para que un informe almacene caches, este debe estar habilitado. A nivel de proyecto, se puede definir un comportamiento por defecto, pero también se puede definir a nivel de informe.
Pues tal como se imaginarán, ambos métodos nos ayudan a optimizar el rendimiento y el tiempo de respuesta de los informes que ejecuta un usuario. Tienen como propósito final mejorar el tiempo de respuesta de una consulta en las solicitudes posteriores.
Si vamos a un nivel más técnico, historial está estrechamente relacionado con la funcionalidad de caching. Si lo pensamos, el historial está formado por mensajes que apuntan a resultados de informes, y estos se encuentran almacenados como “cachés de historial”. Por lo tanto, cuando se elimina un mensaje del History list, también se elimina la caché de Historial a la que apunta el mensaje.
Volviendo a lo que aplica a funcionalidad, ambos pueden generarse tanto en el momento de ejecución, así como también pueden ser planificados.
Por ejemplo, si quisiera que un informe (digamos que tarda 2 horas en finalizar) se ejecute automáticamente a las 6 am para tener los datos de la jornada anterior, se planifica a esa hora para que cuando llego a las 8 a la oficina ya está el informe listo y en cuestión de segundos ya puedo estar ejecutándolo dentro de la herramienta, por lo que podemos utilizar filtros de visualización o crear documentos y gráficos basados en dicho reporte sin tener que esperar a que se ejecute cada vez… suena interesante, ¿no?
Y de la misma forma, a ambos se les puede asignar una vigencia. Es decir, se puede dar un periodo de validez en el que podrán ser utilizados.
Aquí es donde viene lo importante de la cuestión. Hay varios puntos a considerar que diferencian a uno de otros.
Como se imaginarán, hay distintos escenarios, y dependiendo de cada uno es conveniente (o posible) utilizar cada una.
En condiciones generales, si un reporte es utilizado de forma masiva, quizás habilitar caches es lo ideal, mientras que si lo que interesa es tener la foto del momento específico de forma personal para analizarlo más tarde, o para asegurarse que el informe no se interrumpirá ante cualquier eventualidad, pues ya con enviarlo al historial es suficiente.
Lo cierto es que hay que tener mucho cuidado con ambas. Como dije antes, una cache puede quedar invalidada si se cambia algo en los objetos o Query relacionada al reporte, pero si los datos son actualizados, no hay nada que lo indique, por lo que pueden estar visualizando y analizando datos antiguos… y eso puede tener un impacto enorme en muchos casos. Así que ya saben, ¡ojo!
Como dije antes, al final de día son dos formas que nos brinda MicroStrategy de optimizar la ejecución de reportes. Ambos son complementarios, es decir, no es que hay que elegir entre una opción y otra, sino que cada usuario y cada proyecto elegirá basándose en sus propias necesidades.
Ya me dirán ustedes que piensan, ¿conocían ambos métodos?¿Cual usan con mas frecuencia? ¿Hay alguna característica que no conocían y que me esté faltando?
¡Espero que les haya resultado útil! ¡Hasta la próxima!
* Tu información será utilizada exclusivamente para contactarte en relación al Business Data Master. No hacemos spam ni compartimos datos con terceros.
