En la actualidad, con el concepto de Big Data para muchas empresas nace la necesidad de administrar y manipular grandes volúmenes de información para el análisis y toma de decisiones orientadas al negocio. DB2 10.5 con Aceleración BLU ofrece nuevamente una opción más para hacer frente a esta necesidad de una manera fácil y rápida. Es también conocido como base de datos en memoria o almacenamiento por columnas.

Jorge Daniel Anguiano Morales, Consultor Certificado IM DB2 para LUW, IBM México

Jorge AnguianoSe desempeña como Database Migration Specialist para Information Management en IBM para México y Latinoamérica y ha trabajado 17 años con distintas Tecnologías de la Información como Analista, Diseñador, Desarrollador e Implementador de Sistemas. Cuenta con certificaciones en IBM DB2 para LUW de la versión 9.7 - 10.1, IBM IT Specialist, OPEN Group Master IT Specialist y OCP en Oracle.



25-11-2013

¿Qué significa BLU?

BLU es una nueva tecnología desarrollada por IBM e integrada directamente dentro del motor de DB2. BLU es un nuevo motor de almacenamiento que permite guardar la información en forma columnar y así hacer la explotación de la información de una manera fácil y rápida. Esta característica incrementa el performance, ahorros en almacenamiento, optimización del uso de memoria, mejorar el I/O de manera eficiente y explotando las capacidades del CPU.

El concepto de BLU también surge de la idea de almacenar la información por columnas y de las pruebas realizadas al ejecutar una consulta en 10TB de información arrojando el resultado en menos de un segundo. Sus siglas en inglés son Unique Blink, lo que significa un solo parpadeo para ver el resultado de una consulta. Otro significado se deriva en (B)ig Data, (L)ightning Fast (velocidad del rayo) y (U)ltra Easy (Ultra fácil).

DB2 BLU esta diseñado bajo las siguientes ideas:

  1. Simple y fácil de usar
  2. Compresión extrema
  3. Almacenamiento de la información por columnas
  4. Salto de datos (Data Skipping)
  5. Paralelismo multiprocesamiento
  6. Explotación del CPU
  7. Datos en memoria

Idea 1. Simple y fácil de usar

DB2 10.5 con Aceleración BLU esta diseñado para bases de datos de tipo OLAP (On Line Analytics Process), es decir para la parte de analíticos. Es simple y fácil porque solo se requiere cambiar el valor de la variable de registro DB2_WORKLOAD antes de crear la base de datos. Al crear la base de datos DB2 configurará los parámetros necesarios para el uso óptimo de analíticos y también tomará en cuenta las características del Hardware.

Para verificar el valor de la variable de registro DB2_WORKLOAD se ejecuta el siguiente comando:

$ db2set –all

Figura 1.

En la figura anterior observamos que la variable DB2_WORKLOAD no está configurada. Para configurar el valor de la variable de registro DB2_WORKLOAD a ANALYTICS y verificar que la variable de registro se haya cambiado ejecutamos el siguiente comando:

$ db2set DB2_WORKLOAD=ANALYTICS

$ db2set -all

Figura 2.

Para que el valor de la variable de registro tenga efecto hay que dar de baja la Instancia y levantarla nuevamente.

$ db2stop

$ db2start

Ahora solo se necesita crear la base de datos, crear las tablas y realizar la carga de datos. En este ejemplo, vamos a crear una base de datos llamada "pbacol".

$ db2 CREATE DATABASE PBACOL COLLATE USING IDENTITY PAGESIZE 32K

Conectarse a la base de datos para verificar que los parámetros que se configuraron al momento de crear la base de datos sean correctos.

$ db2 connect to pbacol

Los parámetros que DB2 configura automáticamente son los siguientes:

$ db2 get db cfg | grep –Ei --color “Database page size|dft_table_org|dft_degree|dft_extent_sz|catalogcache_sz|sortheap|util_heap_sz|auto_reorg|sheapthres_shr”

Figura 3.

Nota: El valor de cada uno de los parámetros dependerá de la capacidad de memoria y de los recursos del sistema. Cada uno de estos parámetros se configura durante la creación de la base de datos.

A continuación se describe el objetivo de cada uno de ellos.

Tamaño de páginas (Database page size)

  • Tamaño de páginas (Database page size)

Grado de paralelismo (DFT_DEGREE)

  • El valor default es 1 sin embargo DB2 lo pone en ANY, lo cual significa que el optimizador determina el grado del intra-partition paralelismo basado en el número de procesadores y el tipo de consulta que se ejecute.

Parámetro SHEAPTHRES_SHR

  • Este parámetro representa un soft limit en el monto total de la memoria compartida de base de datos que puede ser utilizado por el sort memory en cualquier momento. El soft limit es un límite flexible aplicado a una sesión o proceso. DB2 reserva áreas de memoria para operaciones como un Sort el cual puede ser reservado a nivel instancia o base de datos. A nivel instancia el sort memory es controlado por el parámetro SHEAPTHRES_SHR.

Parámetro SORTHEAP

  • Este parámetro define el número máximo de páginas de memoria privada o compartida que una operación consumirá.

Parámetro CATALOGCAHCE_SZ

  • Este parámetro especifica el espacio máximo en las páginas que el catalog cache puede utilizar desde las bases de datos.

Parámetro UTIL_HEAP_SZ

  • Este parámetro indica el monto máximo de memoria que puede ser utilizado simultáneamente por el Backup, Restore y Load, incluyendo también el Load Recovery. Este parámetro hay que cambiarlo tan alto como sea posible, de acuerdo a la memoria disponible en el Servidor. Se recomienda ajustar este parámetro antes y después del proceso de LOAD. El Utility Heap es utilizado como el área de trabajo para construir el encoding values para las tablas organizadas por columna (Compresión). Una buena regla es tener por lo menos un millón de páginas para UTIL_HEAP_SZ durante el primer LOAD de una tabla organizada por columna. Si la base de datos tiene más de 128 GB de memoria disponible entonces se recomienda configurar a cuatro millones de páginas durante el primer LOAD de cualquier tabla organizada por columna. Si ya existe una base de datos el valor de UTIL_HEAP_SZ debe ser igual a AUTOMATIC.

Parámetro DFT_EXTENT_SZ

  • Este parámetro ajusta por default el tamaño del Extent de los Table Space.

Parámetro AUTOMATIC_REORG

  • Este parámetro configura en automático la reorganización de tablas para tablas organizadas por columna (Habilita en automático la reclamación de espacio). Al habilitarse este parámetro también se habilita el parámetro AUTO_MAINT=ON.

Parámetro DFT_TABLE_ORG

  • Por último, este parámetro cambia el valor default a COLUMN para la creación de nuevas tablas. Esto significa que al crear una nueva tabla no es necesario especificar que los datos serán almacenados de manera columnar, DB2 lo hará de forma automática. Simplemente se utiliza la sintaxis normal.

Ejemplo

$ db2 “CREATE TABLE t1 (Clave INTEGER, Nombre VARCHAR(20))”;

Cabe destacar que esto no es una limitante para DB2. Se pueden crear también tablas organizadas por RENGLÓN simplemente especificando.

$ db2 “CREATE TABLE t2 (Clave INTEGER, Nombre VARCHAR(20)) ORGANIZE BY ROW”;

Si verificamos cómo se crearon las dos tablas anteriores podemos observar que la tabla T1 está organizada por Columna y la tabla T2 por Renglón.

$ db2 “SELECT VARCHAR(tabname,10) Tabla, tableorg Organizado FROM syscat.tables WHERE tabname IN (‘T1’,’T2’)”

Figura 4.

Una vez que los parámetros se han configurado y se ha creado la base de datos solo es necesario crear las tablas y cargar los datos. Una de las características más importantes de DB2 con aceleración BLU es que no se requiere la creación o el uso de:

  • Índices
  • Particionamiento de tablas
  • MQT (Material Query Tables) o Vistas materializadas
  • MDC (Multi Dimensional Cluster)
  • Hints
  • Ejecución estadísticas
  • Vistas

Para la migración de la información a tablas organizadas por columna se recomienda utilizar el comando LOAD, el cual se explica más adelante.


Configuración manual

Si por algún motivo no se puede actualizar la variable DB2_WORKLOAD se sugiere realizar lo siguiente:

1.- Crear una base de datos con UNICODE. Este es un esquema de codificación universal de caracteres escritos y textos que permiten el intercambio de datos a nivel universal.

$ db2 CREATE DATABASE PBACOL COLLATE USING IDENTITY PAGESIZE 32 K

2.- Actualizar los parámetros a nivel Instancia y a nivel Base de datos:

$ db2 update db cfg for pbacol using DFT_DEGREE ANY

$ db2 update db cfg for pbacol using DFT_EXTENT_SZ 4

3.- Incrementar el parámetro CATALOGCACHE_SZ 20%

4.- Asegurarse que el parámetro SORTHEAP y SHEAPTHRES_SHR no están configurados en AUTOMATIC

5.- Configurar el parámetro UTIL_HEAP_SZ a un número grande de uno a cuatro millones de páginas

6.- Configurar el parámetro AUTO_REORG a ON

7.- Asegurarse que el parámetro SHEAPTHRES está configurado a 0

8.- Asegurarse que INTRAQUERY PARALLELISM está habilitado. Esto puede ser configurado a nivel Instancia, Base de datos o Aplicación.

9.- Habilitar SYSDEFAULTMANAGEDSUBCLASS

$ db2 ALTER THRESHOLD SYSDEFAULTCONCURRENT ENABLE


Idea 2 Compresión Extrema

Adicional a las características de compresión de versiones anteriores, como por ejemplo DB2 10.1 Adaptive Compression, DB2 10.5 ha implementado nuevos algoritmos de compresión con la cual se incrementa la tasa de compresión y, por consiguiente, el performance. El nuevo algoritmo de compresión se llama codificación Huffman. Consiste en una cadena de datos con una serie de 0 a 1, en el cual cada caracter es asignado a 8 bits y a su vez podemos separar un caracter de otro por la ruptura de 8 trozos de bits. Sin embargo, la codificación Huffman es un número variable de bits de cada caracter dependiendo de la frecuencia.

DB2 utiliza secuencias de caracteres de acuerdo con la probabilidad de ocurrencia para utilizar menos bits y así lograr una compresión extrema. La siguiente figura se muestra para efectos ilustrativos.

Figura 5.

La codificación es siempre un valor de la columna entera y ayudará a tener menos I/O, mejor uso de la memoria, un uso más eficiente del CPU y por supuesto un mejor rendimiento. Otra característica es que permite el uso de predicados y Joins sobre los datos codificados, es decir sin tener que descomprimir los datos.

Ejemplo:

$ db2 “SELECT COUNT(1) FROM proyectos WHERE nombre = 'Armando'”

DB2 codificará el nombre ‘Armando’ y lo comparará con los datos codificados de la columna al realizar el COUNT. En una consulta los datos serán descomprimidos hasta el momento en que el resultado será enviado al usuario.

La compresión en versiones anteriores a la 10.5 es opcional, es decir, nosotros podemos habilitar o deshabilitar la compresión para una tabla. En DB2 10.5, la compresión no es opcional, es decir, siempre los datos serán comprimidos al momento de ser insertados y/o actualizados en la tabla. En la siguiente consulta podemos observar tablas organizadas por renglón y columna.

$ db2 “SELECT VARCHAR(tabschema, 20) Esquema, VARCHAR(tabname,20) Tabla, tableorg Organizado, compression Compresion FROM syscat.tables WHERE TYPE = ‘T’ AND tabname LIKE ‘S’ AND tabschema = ‘DB2INST1’”

Figura 6.

Nota: Observe que la columna COMPRESION para la tabla SALES está en blanco. Esto significa que los datos están siempre comprimidos

Para hacer la compresión de la información en tablas organizadas por columnas se crea un diccionario por columna. A continuación se muestra una comparativa con tablas organizadas por renglón y columna.

Figura 7.

Cómo verificar el porcentaje de codificación de tablas organizadas por columna

Ejecutando la siguiente consulta se puede determinar el porcentaje y el nivel.

Figura 8.
Figura 9.

Idea 3 Almacenamiento de la información por Columnas

En conjunto con la codificación y el almacenamiento por columnas nos permite obtener mayor compresión pero también minimizar la Entrada/Salida al disco para realizar consultas a grandes volúmenes de información. Se mejora la Entrada/Salida porque solo se leen las columnas que desea consultar. DB2 trabaja directamente sobre los datos de las columnas y a medida que la consulta avanza menos registros se clasificarán, por lo tanto, el trabajo para acceder al conjunto de páginas para la siguiente columna se reducirá.

Los registros y las columnas no están juntos sino hasta que el resultado de la consulta se devuelve al usuario final o cuando se realiza un Join con una tabla organizado por renglón.

Ventajas

  • Minimiza la E/S porque solo ejecuta las operaciones de E/S en columnas y valores que utiliza la consulta.
  • Extrema la compresión porque empaqueta más valores de datos dentro de pequeños montos de memoria o disco.
  • El uso de Predicados, Join y Scan trabaja directamente sobre las columnas y sobre datos codificados lo que incrementa el performance. Los datos son descomprimidos hasta el momento en que son devueltos al usuario final.
  • Mejora la densidad de la memoria porque los datos almacenados por columnas se mantienen comprimidos en la memoria.
  • Eficiencia el cache debido a que no hay necesidad de utilizar más memoria y ancho de banda para columnas que no son necesarias.
  • Generalmente, ocupan menos espacio que las tablas organizadas por renglón. Sin embargo, si una tabla organizada por renglón tiene pocos registros ocupara más espacio.
  • Cada tabla organizada por columna tiene una tabla auxiliar llamada Synopsis. Esta tabla ocupa el 0.1% del tamaño actual.

Las columnas se almacenan por separado y se empaquetan en diferentes Buffer en la memoria. Supongamos que se ejecuta la siguiente consulta:

$ db2 “SELECT nombre FROM proyectos WHERE nombre = 'Armando'”

DB2 utilizara ancho de banda, E/S y buffer de memoria solo para la columna nombre.

Figura 10.
Figura 11.
Figura 12.
Figura 13.

Cómo migrar información a DB2 BLU

Existen diferentes formas de migrar la información hacia DB2 con Aceleración BLU.

Cuando la base de datos es nueva se requiere ejecutar los siguientes pasos:

  • Configurar la variable de registro DB2_WORKLOAD=ANALYTICS
  • Detener y levantar la Instancia
  • Crear la base de datos con UNICODE
  • Crear las Tablas
  • Carga la información

Si DB2_WORKLOAD=ANALYTICS al crear cualquier tabla DB2 por default creará las tablas organizadas por columna, de lo contrario en la sentencia CREATE TABLE se deberá especificar ORGANIZED BY COLUMN. Caso contrario, si no desea utilizar tablas organizadas por columnas deberá especificar en la sentencia CREATE TABLE … ORGANIZED BY ROW.

Forma 1

1.- Crear en la base PBACOL la tabla empleado y cargar sus datos. El script empleado.sql contiene la definición de la tabla:

Figura 14.
Figura 15.

El resultado indica que la tabla empleados ha sido creada por default organizada por columna sin haber especificado ORGANIZE BY COLUMN.

2.- El último paso es cargar los datos. Se puede hacer mediante el uso del comando LOAD tal cual como se realiza en versiones previas a la 10.5.

$ db2 “LOAD FROM empleados.txt OF DEL MESSAGES empleados.log INSERT INTO empleados”

Figura 16.

De esta forma los datos de la tabla Empleados quedan organizados por columna. Este es un ejemplo sencillo para ilustrar que el proceso de cargar datos en una tabla organizada por columna, es fácil y sencillo como si se estuviera trabajando en una tabla organizada por renglón.

¿Qué cambios hay en el comando LOAD?

Hay un cambio interno en el comando LOAD, pero se utiliza de la misma forma como se utiliza en versiones anteriores. Antes de cargar los datos en DB2 10.5, hay una nueva fase llamada ANALYZE. Esta fase solo aplicará para tablas organizadas por columna y se encargará de lo siguiente:

  1. Convertir los datos con formato organizados por renglón a formato organizado por columna.
  2. Construir los Histogramas para dar un seguimiento a los valores que se repiten en las columnas.
  3. Crear el diccionario de compresión por columna basado en los Histogramas.

Una vez que la fase de ANALYZE ha terminado la fase de LOAD se encargara de lo siguiente:

  1. Convertir los datos organizados por renglón a organizados por columna.
  2. Las páginas de datos se construyen utilizando el diccionario de compresión.
  3. Actualizará la tabla de Synopsis (ver más detalle en el tema Data Skipping).
  4. Construirá las llaves para mapear las páginas y los índices únicos.

La siguiente figura muestra un ejemplo de una carga de datos en una tabla organizada por columna donde se aprecia la fase de ANALIZE.

Figura 17.

La información se almacenará en conjunto de Extents y Páginas separadas por cada columna. El número de secuencia de una tupla TSN (Tuple Sequence Number) se almacenará con los datos de columna en una página. El TSN es una liga entre las columnas de una página dentro de un renglón.

Recomendaciones antes de ejecutar el LOAD

  • El parámetro UTIL_HEAP_SZ debe ser tan grande como sea posible. Se recomienda que sea por lo menos de un millón de páginas. Si el Servidor de la base de datos tiene más de 128GB en RAM, se recomienda que el valor de este parámetro sea por lo menos de cuatro millones de páginas.
  • Modificar el parámetros BLOCKNONLOGGED a NO
  • LOAD REPLACE RESETDICTIONARY siempre reconstruirá el diccionario con nuevos datos.
  • LOAD REPLACE RESETDICTIONARYONLY crea el diccionario de datos sin cargar datos.
  • LOAD REPLACE KEEPDICTIONARY utiliza el diccionario existente y comprime los datos.
  • No se requiere ejecutar las estadísticas.
  • Debe existir suficiente espacio en el directorio temporal de carga para almacenar en caché los datos.
  • Para obtener una mayor tasa de compresión se recomienda cargar grandes volúmenes de información durante la primera carga.
  • No se recomienda cargar un subconjunto pequeño de datos en la primera carga, ya que puede provocar una compresión baja en los diccionarios.
  • La compresión a nivel página se utiliza para los nuevos valores no cubiertos por el diccionario a nivel columna.
  • Tener suficiente memoria incrementará el performance durante el proceso de carga, mejor compresión de tablas y mejor desempeño en la ejecución de consultas.
  • Al final del proceso de LOAD reducir el tamaño del parámetro UTIL_HEAP_SZ para tener mayor SORTHEAP para el uso de consultas.

Cómo verificar el tamaño físico de tablas organizadas por renglón sin compresión

Ejecutando la siguiente consulta se puede determinar el tamaño.

$ db2 “SELECT SUM(data_object_p_size + index_object_p_size + long_object_p_size + lob_object_p_size + xml_object_p_size) FROM sysibmadm.admintabinfo WHERE tabschema = ‘DB2INST1’

Cómo verificar el tamaño físico de tablas organizadas por renglón con compresión

Ejecutando la siguiente consulta se puede determinar el tamaño.

$ db2 “SELECT SUM(data_object_p_size + index_object_p_size + long_object_p_size + lob_object_p_size + xml_object_p_size) FROM sysibmadm.admintabinfo WHERE tabschema = ‘DB2INST1’

Cómo verificar el tamaño físico de tablas organizadas por columna

Ejecutando la siguiente consulta se puede determinar el tamaño.

$ db2 “SELECT SUM(col_object_p_size + data_object_p_size + index_object_p_size) FROM sysibmadm.admintabinfo WHERE tabschema = ‘DB2INST1’

Cómo verificar el porcentaje de páginas almacenadas

Con la siguiente consulta podemos verificar cuantas paginas almacenadas y la tasa de compresión de una tabla (No incluye índices).

$ db2 “SELECT VARCHAR(tabname,60) Tabla, pctpagessaved Porc_Paginas, 1.0 / (1.0 - pctpagessaved/100.0) Tasa_Compresion FROM syscat.tables WHERE tabname = ‘EMPLEADO’ AND tableorg = 'C'”

Cómo verificar el tamaño de almacenamiento de una tabla organizada por columna y la compresión obtenida

Con la siguiente consulta podemos verificar el tamaño de las tablas y la compresión obtenida.

$ db2 "SELECT VARCHAR(a.tabname,10) Tabla, col_object_p_size tamanio_tabla, data_object_p_size tamanio_datos, index_object_p_size tamanio_indice, (col_object_p_size + data_object_p_size + index_object_p_size) tamanio_total, DEC(1.0/(1.0-(pctpagessaved*1.0)/100.0),31,2) tasa_compresion, pctpagessaved porc_paginas_guardadas FROM syscat.tables a, sysibmadm.admintabinfo b WHERE a.tabname = b.tabname AND a.tabname LIKE 'SA%'"

También se puede obtener la información a través del uso del Table Function ADMIN_GET_TAB_INFO y la vista ADMINTABINFO.

¿Se puede utilizar el IMPORT e INGEST en lugar de LOAD?

Es posible utilizar las utilerías IMPORT o INGEST para la carga de datos. Sin embargo hay que realizar los siguientes pasos antes de utilizar estas utilerías.

1.- Ejecutar primero el LOAD REPLACE RESETDICTIONARYONLY el cual solo leerá los datos a cargar para crear el diccionario de datos (No cargará datos).

2.- Ejecutar la carga de datos con IMPORT o INGEST.

Forma 2

Convertir una tabla existente organizada por renglón a organizada por columna. Para esto se puede utilizar la utilería db2convert, la cual convierte una tabla y sus datos a una tabla organizada por columna sin afectar la disponibilidad de los datos. El comando db2convert tiene varias características entre ellas no afectar la disponibilidad de los datos durante el proceso de conversión, convierte tablas individuales, esquemas completos o todas las tablas de una base de datos.

En el siguiente ejemplo convertiremos la tabla SALES que esta organizada por renglón a columna.

1.- Verificar que la tabla a convertir este organizada por Renglón.

$ db2 “SELECT VARCHAR(tabschema, 20) Esquema, VARCHAR(tabname,20) Tabla, tableorg Organizado FROM syscat.tables WHERE tableorg = ‘R’ AND TYPE = ‘T’ AND tabname LIKE ‘S’ AND tabschema = ‘DB2INST1’”

Figura 18.

2.- Convertir la tabla SALES organizada por renglón a organizada por columna. Donde –d es el nombre de la base de datos, -z es el esquema en donde se encuentra la tabla y –t la tabla que deseamos convertir.

$ db2convert –d SAMPLE –z DB2INST1 –t SALES

Al inicio del proceso usted podrá observar lo que se muestra en la figura siguiente, y conforme progresa la conversión de los datos se podrá observar el porcentaje del progreso de la conversión. Una de las ventajas es que podemos continuar con la operación del negocio, es decir, se pueden seguir realizando transacciones (INSERT, UPDATE, DELETE, SELECT) durante el proceso de conversión.

Figura 19.
Figura 20.

La columna InitSize específica el tamaño original antes de la conversión, la columna FinalSize indica el tamaño final después de la conversión, la columna CompRate indica el porcentaje que se obtuvo de compresión y finalmente el estado en el que la conversión terminó.

Nota: Como se comentó al inicio del artículo, si una tabla contiene pocos registros y se convierte a organizada por columna el tamaño de la tabla puede ser mayor al de una tabla organizada por renglón. En el ejemplo anterior la tabla SALES solo se utilizó para efectos ilustrativos porque contiene solo 41 registros.

Si ejecutamos nuevamente la consulta del paso uno, observaremos que la tabla SALES ya no se muestra. Para verificar que la tabla SALES fue convertida a organizada por columna podemos ejecutar la siguiente consulta:

$ db2 “SELECT VARCHAR(tabschema, 20) Esquema, VARCHAR(tabname,20) Tabla, tableorg Organizado FROM syscat.tables WHERE tableorg = ‘C’ AND TYPE = ‘T’ AND tabname LIKE ‘S’ AND tabschema = ‘DB2INST1’”

Figura 21.

Idea 4 Salto de datos (Data Skipping)

Esta es otra de las características de DB2 con Aceleración BLU, la cual nos permite acceder a la información de una forma rápida sin el uso de índices. DB2 BLU no es para consultas que solo extraen uno o dos registros (probablemente mediante el uso de un índice). En tablas organizadas por renglones se utilizan los índices para saltar directamente a los datos y así obtener la información de una manera natural. Cuando no podemos utilizar índices en tablas organizadas por renglón se realiza un Full Table Scan con el cual lee toda la información de la tabla para regresar solo los registros que se requieren. DB2 utiliza el algoritmo Utilizado Más Recientemente MRU (Most Recently Used) para mantener las páginas en el Buffer Pool para las cargas de trabajo transaccionales utilizando tablas organizadas por renglón.

Como se ha mencionado al inicio de este articulo DB2 con Aceleración BLU está diseñado para cargas de trabajo Analíticos y para Data Mart que utilizan operaciones como Sumas, Agrupaciones, Agregaciones, Ordenamientos, Rangos de datos, entre otros. En ausencia de índices para tablas organizadas por columna DB2 realiza el salto de datos (Data Skipping) mediante el uso de los datos de la tabla Synopsis para la columna que se accede. La tabla Synopsis es mantenida automáticamente por DB2 durante las operaciones de INSERT, UPDATE y DELETE. Cada registro en la tabla Synopsis está ligado a una cierta porción de registro de datos (usualmente cada 1024) y el índice de mapa relaciona estos a los bloques físicos en el disco. En la siguiente figura se ilustra un ejemplo.

Figura 22.

El Salto de datos detectará automáticamente gran parte de los datos que no cumplen con la consulta. También se logran ahorros de Entrada/Salida, RAM y CPU. Tampoco se requiere de la intervención del DBA para la creación y mantenimiento de la tabla Sinopsys, está se creará automáticamente al Cargar o Insertar datos.

Cada vez que se crea una tabla organizada por columna o se convierte una tabla organizada por renglón a organizada por columna se creará la tabla Synopsis. Por cada columna se guarda un valor mínimo y un valor máximo, y por cada 1024 registros. No hay que preocuparse por el tamaño de la tabla Synopsis debido a que solo representa 0.1% del tamaño de la tabla del usuario. En el siguiente ejemplo veremos como al crear una tabla, DB2 en automático crea la tabla Synopsis.

1.- Crear una tabla llamada EMPLEADOS organizada por columna.

$ db2 “CREATE TABLE empleados (empleado INTEGER, nombre VARCHAR(20), sueldo DECIMAL(8,2), puesto VARCHAR(20) ORGANIZE BY COLUMN”

2.- Verificar que la tabla empleados se haya creado como tabla organizada por columna junto con su tabla Synopsis.

$ db2 “SELECT VARCHAR(tabschema,20) Esquema, VARCHAR(tabname,40) Tabla, tableorg Organizada_Por FROM syscat.tables WHERE tabname LIKE ‘%EMPLEADOS’”

Figura 23.

3.- Cargar 5000 registros en la tabla de empleados, la tabla empleados contiene las columnas Empleado, Nombre, Sueldo y Puesto. Para efectos de prueba se improvisan los datos.

$ db2 LOAD FROM empleados.txt OF DEL INSERT INTO empleados

Figura 24.

4.- Consultar la información de empleados

$ db2 “SELECT * FROM empleados”

Nota: Si por algún motivo recibe el error SQL0955C Sort memory cannot be allocated to process the statement. Reason code = 3, deberá modificar los parámetros SORTHEAP y SHEAPTHRES_SHR.

5.- Revisar como DB2 administra de forma automática la tabla Synopsis para la tabla de empleados.

$ db2 “SELECT * FROM SYSIBM.SYN131111202122858670_EMPLEADOS”

Figura 25.

En la tabla Synopsis hay que observar lo siguiente:

  • La tabla Synopsis no contendrá columnas de tipo VARCHAR. En la tabla empleados existe el Nombre y Puesto del empleado, y estas columnas no son creadas en la tabla Synopsis.
  • En la tabla Synopsis se crea un registro por cada 1024 registros de la tabla de usuario (Ver columnas TSNMIN y TSNMAX). Esto es el meta-data lo cual significa cuáles rangos de valores existen en las partes de la tabla de usuario.
  • Permite a DB2 saltar porciones de datos cuando se consulta información.
  • Beneficia la agrupación de datos.

6.- Ejecutar una consulta para verificar que el acceso a la información se realiza por columna. La siguiente consulta mostrará el total de empleados por puesto, sueldo actual y la suma total por puesto de aquellos empleados que estén entre los rangos 1550 y 3680.

$ db2 “SELECT Puesto, COUNT(empleado) Total_Empleados, SUM(sueldo) / COUNT(empleado) Sueldo_Por_Empleado, SUM(sueldo) Total FROM empleados WHERE empleado BETWEEN 1550 AND 3680 GROUP BY puesto”

Figura 26.

Cómo verificar que el acceso a la información se realiza por Columna

Para verificar que el acceso a la información se realiza por Columna hay que generar el plan de ejecución y verificar que el SCAN se realice sobre el nuevo operador CTQ, el cual indica la transición de procesamiento entre los datos organizados por columnas y por renglón.

1.- Eliminar los datos de la tabla donde se guardan los planes de ejecución. Si por algún motivo la tabla no existe será necesario ejecutar el script “db2 –tvf EXPLAIN.DDL” que se encuentra en el directorio SQLLIB del producto DB2.

$ db2 “DELETE FROM explain_instance”

2.- Generar el plan de ejecución para la consulta que deseamos verificar.

$ db2 “explain plan for SELECT Puesto, COUNT(empleado) Total_Empleados, SUM(sueldo) / COUNT(empleado) Sueldo_Por_Empleado, SUM(sueldo) Total FROM empleados WHERE empleado BETWEEN 1550 AND 3680 GROUP BY puesto”

3.- Mandar a un archivo el plan de ejecución.

$ db2exmft –d sample -1 –o empleados.exfmt

4.- Editar el archivo empleados.exfmt y verificar el plan de ejecución. Observe que existe el operador CTQ (Column Table Queue) el cual es el operador óptimo para el procesamiento de datos por columnas y también el encargado del procesamiento de datos entre renglones y columnas.

Figura 27.

Idea 5 Paralelismo multiprocesamiento

Otra de las características de DB2 con Aceleración BLU es que al ejecutar las consultas automáticamente son paralelizadas con los procesadores del equipo logrando así una excelente escalabilidad de multiprocesamiento. Los datos son cuidadosamente colocados y alineados poniendo atención en los atributos físicos del servidor sin la necesidad de particionar los datos en diferentes servidores.

Figura 28.

Un agente independiente por cada núcleo o procesador puede recuperar datos de columnas individuales. Cada agente trabaja en diferentes funciones de la consulta. Antes de llegar al operador CTQ los datos son procesados por núcleo y por último en un plan de ejecución el operador REBAL indica que múltiples procesadores se están utilizando.


Idea 6 Explotación del CPU

Como se mencionó al inicio, IBM ha creado esta tecnología para consultas analíticas donde ha realizado pequeños cambios al motor de la base de datos para que en tiempo de ejecución se realice el procesamiento con vectores, es decir con una sola instrucción obtengo múltiples datos, también llamado SIMD (Simple Instruction Multiple Data). Con estos cambios se logran profundas optimizaciones para el uso del multiprocesamiento y uso de la memoria. El SIMD significa que una misma operación es ejecutada en múltiples elementos de datos simultáneamente y con esto incrementar el performance hasta en 25% más que la versión 10.1. Se ejecutan instrucciones especiales a nivel Hardware para hacer el uso de SIMD, como por ejemplo: Evaluación de predicados, Agrupación, Joins, entre otros. El siguiente ejemplo solo es para efectos de ilustrativos de como sería el uso SIMD.

Ejemplo: Supongamos que tenemos los siguientes empleados y deseamos buscar al empleado 2131.

Figura 29.

Sin el uso de SIMD se ejecutarían ocho instrucciones u ocho comparaciones.

Figura 30.

Mientras que con el uso de SIMD solo se ejecutarían dos instrucciones o dos comparaciones.

Figura 31.

Con una instrucción se multiplica el poder del CPU y puede obtener resultados de todos los valores en el registro. Hoy en día hay CPU’s que están construidos con las capacidades de ejecutar SIMD. En el apartado de Hardware se pueden ver los modelos que traen estas características.


Idea 7 Datos en memoria

Por último y no menos importante, podemos tener datos efectivos en la memoria, es decir datos que solo son necesarios (No hay necesidad de asegurar que todos los datos caben en la memoria). DB2 con Aceleración BLU está diseñado como una base de datos en memoria con la habilidad de tener más tamaño de tablas en memoria si la memoria lo permite. Con los nuevos algoritmos el 80-100% de los datos pueden estar ahora en el Buffer Pool en comparación con el 15 o 50% para las tablas organizadas por renglón. DB2 incluye un nuevo algoritmo Scan Friendly el cual incluye una nueva selección de víctimas para mantener un óptimo porcentaje de páginas en memoria. Los RDMS tradicionales utilizan el algoritmo LRU (Lost Recently Used) para desalojar los datos que no han sido consultados últimamente debido a que no es posible conservar todos los datos en memoria, solo selecciona la última página utilizada recientemente. Mientras que el algoritmo MRU (Most Recently Used) mantiene los últimos datos utilizados en memoria no siendo la mejor manera. Un punto clave en el diseño de DB2 10.5 es que funciona muy bien en ambos casos, cuando los datos se ajustan en la memoria y también cuando no se ajustan. Con esta característica también se obtiene el beneficio en la reducción de acceso al disco (Entrada/Salida).


IBM Optim Query Tuner

Es una herramienta que nos permite evaluar aquellas tablas que son candidatas a ser convertidas a organizadas por columna. También analiza los SQL de una carga de trabajo y estima el costo de ejecución de tablas organizadas por columna y renglón.


Conclusión

DB2 10.5 con Aceleración BLU abre camino a la nueva era del concepto de bases de datos en memoria donde solo se tiene en memoria lo que se necesita para la explotación de la información de una manera fácil, rápida y sencilla. No solo hace una explotación óptima de la memoria, sino también la explotación de todos los recursos del sistema (discos, procesadores, paralelismo, entre otros.) para la consulta y análisis de grandes volúmenes de información de forma rápida para ayudar en la toma de decisiones. Con esta nueva tecnología se contribuye todavía más en la reducción de costos en almacenamiento de la información, incremento de performance y en la reducción de tiempo y administración en tareas para la optimización de consultas analíticas.


Referencias

Information Center DB2 10.5

DB2 with BLU Acceleration

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Information mgmt
ArticleID=954454
ArticleTitle=Cómo utilizar DB2 10.5 con Aceleración BLU
publish-date=11252013