MicroStrategy: Report Caching vs History List
Joaquin Attanasio

Joaquin Attanasio

Business Intelligence Consultant | Microstrategy Expert | Data Specialist

Otros Artículos:

MicroStrategy Report Caching vs History List

Share on linkedin
LinkedIn
Share on facebook
Facebook
Share on twitter
Twitter
Share on whatsapp
WhatsApp

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.  

report-caching-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…  

History List

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”  

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”.

Imagen 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). 

History List Microstrategy Tutorial

Caches

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.

Report Caching Microstrategy

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. 

Report Caching MicroStrategy

¿Qué tienen en común?

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.  

Report Caching Update

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. 

¿En que se diferencian?

Aquí es donde viene lo importante de la cuestión. Hay varios puntos a considerar que diferencian a uno de otros.   

  • Accesibilidad: Cuando se crea un cache, este es utilizado por todos los usuarios que ejecuten el reporte. Por ejemplo, si Juan ejecuta el reporte “A” y luego lo ejecuto yo, podré aprovechar la cache que se ha generado en la primera ejecución. Por el contrario, los mensajes de historial son personales y solo serán accesibles por aquellos usuarios que los ejecutan. 
  • Gestión y mantenimiento: Como comenté anteriormente, hay distintos tipos de caches. Se tienen muchas opciones para administrar y gestionar el uso de caches, mientras que el historial es un poco mas limitado en este sentido. De todas formas, siguiendo con la línea anterior, esto tiene sentido ya que las caches son mucho más globales. 
  • Versatilidad: Una cache puede ser reutilizada en documentos, reportes, usuarios etc. Si un informe tiene algún filtro, se generan distintas caches para cada uno de los filtros (en realidad, para cada variación de la SQL, por lo que también aplican variaciones a nivel de seguridad). Si cambiamos de un filtro a otro, al estar cacheadas ambas opciones la performance se mantendrá optima, mientras que en el history list se re-ejecutaría el informe. 
  • Administración: Mientras que el historial es personal de cada usuario, las caches son gestionadas por los administradores de la plataforma. 
  • Vigencia: Si un reporte, indicador, filtro, atributo, o cualquier otro objeto relacionado con un reporte es modificado, la cache automáticamente queda inválida. 

¿Cuándo conviene utilizar cada una?

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! 

Conclusiones

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! 

Referencias

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *