Nueva Semana, nuevo artículo: ¡Bienvenidos nuevamente a #BestInMicro! Un espacio donde iré escribiendo sobre distintos tópicos relativos a MicroStrategy, su uso, mejores prácticas y funcionalidades para poder aprovechar al máximo la herramienta.
Hoy entraré en un tema que es un poco más conocido, pero a su vez muy complejo: las VLDBs, un conjunto de opciones tan diversas como potentes, que pueden tener un impacto determinante a la hora de definirlas en un proyecto o en una conexión en particular. Pero vamos de a poco…
VLDB es un acrónimo para “Very Large DataBase”. Permiten modificar la sentencia SQL generada por el motor SQL y analítico de MicroStrategy. Es decir, podemos definir el orden en que se realizan las operaciones, nivel de optimización, de joins, pasos intermedios, Hints, y muchas más cosas que incluso entran en una complejidad avanzada.
El control preciso de estas opciones puede tener efectos drásticos en el rendimiento de la herramienta (¡para bien y para mal si no se usan correctamente!), por lo que hoy hablaré un poco sobre cómo funcionan, dónde y cómo pueden configurarlas y algunas de las configuraciones más comunes para modificar.
Pues esta es una excelente pregunta. Este es un ejemplo que me sucedió hace unos días: Por definición de arquitectura, un proyecto tiene seteado que el cruce por defecto entre objetos sea tipo inner join, pero por un requerimiento especifico se necesitaba que se hiciera un cruce tipo outer. Si bien esto puede modificarse a nivel indicador, por ejemplo, puede tener impacto en otros reportes, por lo que necesita ser definido para este informe en particular.
Aquí nos encontramos con un conflicto: a nivel de proyecto tenemos una definición, pero a nivel de informe otra. ¿Cuál manda sobre cuál? ¿Es posible definirlo a distintos niveles
Pues sí. Hay un orden de prioridades para las VLDB, que lo encontramos descripto en la KB14830:
Yendo de arriba hacia abajo, comenzamos con el nivel del reporte. Sería el nivel más específico. Todas las preferencias definidas a este nivel (es decir, en cada informe), sobrescribirán las que vienen definidas en niveles inferiores (según el gráfico), pero valga la redundancia, afectaran sólo al reporte en cuestión. Y lo mismo sucede con las Templates (o plantillas en castellano). Exceptuando que para un informe en particular se defina una propiedad VLDB distinta, un template puede ser creado para definir ciertas propiedades que queramos definir de base a la hora de crear un reporte, sin que estas se apliquen a todos los nuevos informes (¡ni a los existentes, por supuesto!).
Continuando con la jerarquía, llegamos a las propiedades a nivel objeto. Y sé que es aquí donde me dirán: ¡pero Joaquin, en la nota técnica dice claramente “metric”! ¿por qué dices “objeto”? Y es aquí donde explico que a este nivel no solo los indicadores tienen propiedades VLDB, sino que también hay otros objetos como atributos o transformaciones. Entonces es importante comprender que a veces el agregar un atributo a un reporte puede cambiar su comportamiento en relación a como se calculan otros atributos.
Luego, podríamos decir que casi en simultáneo vienen Proyecto y DBI. Digo esto porque solo se puede aplicar una instancia de base de datos principal para cada proyecto… pero dependiendo distintas configuraciones se puede aplicar una u otra DBI.
Además, la configuración a nivel de proyecto contiene propiedades VLDB relacionadas con el motor analítico y de reportes MDX. Y añado, como dato de color, que al modificar una VLDB a este nivel es necesario reiniciar el IS para que los cambios tengan efecto.
El nivel de DBMS (base de datos) más básico donde se definen las propiedades. Es el que fija los estándares generales. Por defecto vienen definidos por MicroStrategy, optimizado para la base de datos y su versión.
Por defecto, todas las propiedades están regidas por la del nivel superior. Esto se ve reflejado en el checkbox “Usar valor heredado predeterminado para todas las propiedades de VLDB”
Si se edita la configuración para una propiedad VLDB en el nivel de un objeto en particular (ya sea una métrica, template, proyecto, etc.), cualquier objeto por encima en la jerarquía VLDB toma automáticamente la configuración personalizada como el valor heredado.
Lo cierto es que no. Hay cientos de distintas posibilidades dentro de las propiedades VLDB. Incluso, muchas de ellas están ocultas por defecto para intentar simplificar las posibilidades, sino también para evitar que por modificar sin comprender que se está haciendo pueda generar errores de mayor impacto.
Por otro lado, tampoco tenemos las mismas opciones si definimos VLDBs a nivel de reporte que a nivel de indicador, por ejemplo.
Por esto, les recomiendo que analicen bien cuando editar VLDBs para definir las bases de un proyecto, o si son casos más “excepcionales”, y por sobre todo comprender el impacto que puede tener modificarlas.
A continuación, dejaré solo algunos de los casos que me he encontrado con más frecuencia o que también me han resultado útiles, pero recuerden que, dependiendo de la base de datos, de su arquitectura, del modelo, etc., lo que puede ser optimo en algún caso puede ser muy malo para otros.
Pre/Post Statements: Esta propiedad nos permite inyectar distintas sentencias o líneas de código a la hora de atacar la base de datos, y está distribuida por niveles, lo que permite decir cuándo es que se ejecutará este código. Esto nos permite generar customizaciones al SQL ejecutado y si se sabe dónde y qué utilizar, puede terminar con grandes ventajas de performance. O también puede ser como logging, para llevar un registro de que se ejecuta, quien y analizar el impacto que tiene sobre el warehouse.
Para bases de datos SQL podemos agregar el SQL HINT a esta funcionalidad. A continuación, muestro un ejemplo, ¡pero las opciones y variaciones son muchísimas! ¿Cómo lo utilizan ustedes? ¿Alguna sugerencia?
Metric Join Type: esta es una de las más “populares”, y su sencillez no opaca el impacto que genera. Siempre es buena práctica tener en claro cuál será la mejor configuración y definirla. Por defecto, viene definida como Inner, pero rara vez he mantenido esta configuración.
Antes:
Después:
Cartesian Join Warning: Esta propiedad es importante si, por ejemplo, se tienen usuarios que crean reportes sin tener una buena comprensión de cómo funciona internamente una consulta. El hecho de tener distintos reportes con Cross join puede tener impactos muy grandes en la performance de la herramienta y la base de datos, es por esto que es una buena práctica deshabilitarlas, y en todo caso habilitarla a nivel reporte para situaciones particulares.
Bueno, finalizando con el artículo de esta semana. Los invito a que busquen más información en algunos sitios que les dejo aquí debajo que me sirvieron como apoyo para no dejarme nada importante de lado y no se olviden de dejarme cualquier pregunta o comentario, tema que les interese que escriba o que les resulte relevante. ¡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.
