Larry Higa’s Ratio, Product Join Indicator and Unnecessary I/O Indicator.

24 marzo \24\+02:00 2020

En Teradata (y en la mayoría de los RDBMS), el consumo de CPU y las actividades de I/O son métricas básicas cuando se trata de analizar el rendimiento de un sistema.
En todos los sistemas Teradata hay tareas que tienden a ser “CPU-bound” y otras tienden a ser “I/O-bound“. Es una buena idea determinar qué tareas encajan en cada categoría.
Las métricas de CPU e I/O se utilizan para hacerse una idea acerca de la eficiencia de las “queries” a la hora de consumir recursos de CPU e I/O. Estas métricas se pueden calcular fácilmente a partir de las tablas y vistas DBQL / PDCR utilizando las columnas AMPCpuTime y TotalIOCount.

Larry Higa’s Ratio (LHR).

Larry Higa era un especialista en temas de rendimiento de Teradata que encontró muy útil relacionar las métricas de CPU e I/O de una manera simple.
El Ratio de Larry Higa (Larry Higa’s Ratio – LHR) es un índice empírico que muestra la tasa de CPU frente a I/O.
La experiencia muestra que la mayoría de las solicitudes de SQL consumen alrededor de 1 segundo de CPU por cada 1000 operaciones de I/O. La desviación de esta constante indica predominio de CPU o I/O, lo que significa un consumo de recursos desequilibrado.

Product Join Indicator (PJI).

El “Product Join Indicator” es la aplicación del principio LHR desde el punto de vista del consumo de CPU:

PJI = CPU Seconds * 1000 dividido por I/O.

Esto se traduce a las columnas DBQLogTbl como: PJI = (1000 * AmpCPUTime) / NullIfZero (TotalIOCount)

Un PJI relativamente alto para una consulta significa que la consulta está usando mucho CPU para las operaciones de I/O dadas.
El valor umbral para considerar PJI “alto” es algo difuso. Algunos dicen 3, algunos dicen 6, algunos dicen 10 … Pero en general, cuanto mayor es PJI menor es la eficacia en el uso de los recursos de CPU (se consume demasiada CPU).

No obstante, podemos encontrar “falsos positivos” en los PJI.
Las “queries” pueden arrojar falsos positivos PJI (alto consumo de CPU por I/O) cuando hay en ellas:
· Agregaciones grandes o muchos grupos de agregación (GROUP BY).
· Numerosos SUBSTRINGS.
· Cláusulas CASE.
· Uso de INDEX / POSITION en cadenas de caracteres.
· Operaciones aritmeticas.
· Comprobaciones de filas duplicadas (INSERTAR filas con el mismo “rowhash” en tablas SET con NUPI).
· Tareas de compresión / descompresión de bloque de datos para actividades de compresión a nivel de bloque (BLC – “block level compression”).

Unnecessary I/O Indicator (UII).

El “Unnecessary I/O Indicator” es la aplicación del principio LHR desde el punto de vista de I/O:

UII (Unnecessary I/O Indicator) = I/O dividida por (CPU Seconds * 1000).

Esto se traduce a las columnas DBQLogTbl como: UII = TotalIOCount / (1000 * NullIfZero (AMPCpuTime))

Cuando una “query” presenta un UII alto generalmente significa que se leen muchos bloques de I/O, pero en realidad se procesa un número relativamente pequeño de filas. Un ejemplo podría ser un “full table scan” que devuelva un resultado de unas pocas filas. En este caso el uso de un índice (secondary, join index…) podría reducir el consumo de I/O. igual que con el PJI, el valor umbral para considerar un UII “alto” también es difuso pero, en general, cuanto mayor es el UII, mayor es la sobrecarga de I/O provocada por una “query”.

Algunas acciones pueden ayudar a reducir el UII:
· Agregar índices secundarios, join indexes, hash indexes, sparse indexes.
· Recopilación / actualización de estadísticas en todas las columnas de “JOIN” y de selección (WHERE).
· Elegir los tipos de datos (y los juegos de caracteres) correctos para limitar el almacenamiento necesario para las columnas y filas.
· Usar MVC (“multi value compression”) para reducir el tamaño de fila y obtener más filas por bloque.
· Usar PPI (y column-PPI).
· Aumentar el tamaño de los “datablocks”.
· Usar el modelo de datos en tercera forma normal (3NF) para obtener filas más pequeñas, más filas por bloque, menos I/O y desnormalizar después si es necesario.
· Aumentar la memoria del nodo, para ampliar el tamaño de la caché FSG.
· BLC también puede ayudar a reducir I/O y aumentar la utilización de FSG.

Saludos.

Carlos.


Teradata available for Google Cloud

5 noviembre \05\+02:00 2019

La oferta de Teradata “on cloud”  se amplía. Hace ya tiempo que Teradata Vantage está disponible para AWSMicrosoft Azure, y ahora lo va a estar también en Google Cloud.

Más información en la nota de prensa.

Saludos.

Carlos.


Teradata New Developer Site

4 noviembre \04\+02:00 2019

Teradata tiene un nuevo “Developer Site”.

TeradataDeveloperSite

Se accede por aquí: https://www.teradata.com/Developer o por aquí: https://developer.teradata.com/

… ¡y en “dark mode”!

Saludos.

Carlos.

 


Hewlett Packard compra MapR

6 agosto \06\+02:00 2019

Hewlett Packard acaba de comprar MapR.

Después de la fusión de Cloudera con HortonWorks parece que el mundo del Hadoop tal y como fue pensado (open-source, commodity hardware, community mantained…) ha tenido mejores épocas, si no es que ha pasado a mejor vida.

Saludos.

Carlos.


Zapas Nuevas

2 agosto \02\+02:00 2019

Adidas Solar Glide, son básicamente las mismas Supernova con las que he corrido este último año.

Saludos.

Carlos.


Time to die…

24 julio \24\+02:00 2019

“Todos esos momentos se perderán en el tiempo, como lágrimas en la lluvia. Es hora de morir” 😪😪😪

https://www.fotogramas.es/noticias-cine/a28496491/rutger-hauer-muere-blade-runner/

Saludos.

Carlos.


Cloudera kaputt?

11 junio \11\+02:00 2019

Pues parece que muy bien no está…

… y MapR tampoco parece estar mucho mejor…

Y esto del hadoop era lo que iba a borrarnos del mapa a nosotros los dinosaurios de los Datawarehouses. En fin…

Saludos.

Carlos.