Índices Columnstore (3)

Dirigido a: Administradores de Bases de Datos
Autor: Pablo F. Dueñas Campo

Hasta ahora hemos estado viendo qué es un índice columnstore y qué lo ha motivado. Pero no nos hemos puesto manos a la obra todavía. No hemos visto las ventajas que pueden tener ni sus desventajas ni cómo solucionarlas. En esta fase práctica vamos a analizarlos en profundidad.

Introducción

Hasta donde hemos visto, los índices columnstore son bastante prometedores para consultas ad hoc de almacenes de datos. Pero va siendo hora de dejarnos de promesas y arremangarnos para ver lo que realmente da de sí esta nueva tecnología y si las ventajas merecen la pena frente a sus deficiencias. Este análisis lo vamos a llevar a cabo con un caso que nos propone Microsoft. Sea representativo o no es lo de menos, nos indicará si en ciertos casos es ventajoso así como un sistema para analizarlos en entornos reales.

Creación de índices columnstore

Lo primero es crear un índice columnstore y comparar dicha creación con los índices tradicionales. Vamos a seguir el ejemplo propuesto por Microsoft y vamos a crear una tabla FactResellerSalesCS como copia de dbo.FactResellerSales, y a cargarla con los mismos datos. La tabla está en la base de datos DW que se puede obtener de Microsoft.

Lo primero que hacemos es vaciar la caché de datos por si acaso. Luego activamos las estadísticas para tener una idea real de lo que pasa por detrás. Por último creamos el índice con casi todas las columnas. La estadística que nos va a importar ahora es el tiempo que se tarda en construir el índice.

Vamos a compararlo con un índice normal sobre una sola columna. Aunque no se muestre, en todas las ocasiones se va a limpiar la caché de datos para ver el comportamiento real:

Se tarda bastante menos. Pero si tenemos en cuenta que el índice columnstore que hemos creado es sobre 24 columnas, vemos que no es tan ineficiente su creación. ¿Por qué? Vamos a verlo inmediatamente.

Pero antes señalemos el uso del procesador. En el índice columnstore es del 60% y en el normal del 40%. Esto era de esperar, pues el índice columnstore además tiene que comprimir los datos, lo que conlleva un mayor uso del procesador.

Espacio en disco

Saber cuánto ocupa un índice es muy fácil, sobre todo uno que no es agrupado.

Vemos que aparecen los dos índices que hemos creado –más otro sobre la columna UnitPriceDiscountPct –, que el primero dice que es del nuevo tipo columnstore y el segundo y tercero no es agrupado –el índice cero es la tabla cuando es un montón–. Pero la segunda consulta no nos da los datos del índice columnstore. Ahora veremos el porqué. Pero antes, el índice 3 usa 245 páginas de las que 4 son de índice propiamente dicho y 241 las ocupan las hojas. Por lo tanto, ocupa 1.960 KB de espacio.

Los índices columnstore se componen en dos partes: los segmentos y los diccionarios. Para calcular el tamaño total del índice hay que usar dos vistas del sistema:

• sys.column_store_segments: Contiene la información de los segmentos del índice, una fila por cada columna. Si consultamos el índice que hemos creado vamos a ver que está la información de 25 filas. ¡Pero nuestro índice sólo tenía 24! Ya dijimos que si no se incluía la clave primaria, se añadía automáticamente al índice. Pero esta tabla es un montón, por lo que la fila 25, que no está en ninguno de los diccionarios (primario ni secundario), es la referencia a las filas.

• sys.column_store_dictionaries: Contiene la información de los diccionarios. En este caso sólo hay uno:

La columna para la que creamos el índice único es la número 10 de nuestro índice columstore. Si sumamos lo que ocupan los segmentos y el diccionario, vemos que son 139 KB. Es decir, algo más de un 7% de lo que ocupa el índice normal. Si nos vamos a la columna 16, entonces tenemos 1.344 KB frente a 2’6 KB lo que supone una compresión francamente agresiva. Ahora entendemos por qué el índice columnstore solamente tardó 4-5 veces lo que el índice sobre una columna: la compresión hace que haya que grabar mucha menos información, por lo que lo que se usa de más el procesador queda mucho más que compensado con lo que se ahorra en escritura.

Para averiguar el tamaño total del índice columnstore, usamos la siguiente consulta, viendo que ¡sólo usa algo más que un solo índice sobre una de las columnas! –vale, era la más grande de todas, pero es una sola–:

Eficiencia

Ya hemos visto que la eficiencia en disco es notable. Por eso, una de las críticas que han surgido frente a estos índices se diluye bastante: sí es cierto que tarda, pero mucho menos que un índice tradicional equivalente.

Por último, vamos a ver la velocidad de respuesta de estos índices. Lo hacemos con una consulta sencilla:

que vamos a aplicar a la tabla sin índices:

con dos índices, uno sobre cada columna

y con un único índice columnstore:

Vemos que para resolver esta consulta se necesitan dos índices normales, pero solo uno de columna. Si nos fijamos, aunque los índices normales tienen más lecturas, al final tardan menos por no tener que descomprimir los datos. Esto nos confirma dos cosas: que un índice especializado es más eficiente y que los índices de columna están mucho más indicados para almacenes de datos donde las consultas son más variables.

Conclusión

La tecnología xVelocity proporciona unas ventajas importantes en los almacenes de datos o cualquier base de datos que no sea OLT, dado que con un solo índice se puede atender múltiples tipos de consultas. Simplifica la programación, el mantenimiento y, sobre todo, permite que se pueda pasar a los usuarios finales la formulación de consultas y análisis de datos al no verse afectado el rendimiento.

> Ver primera parte del artículo
> Ver segunda parte del artículo
> Deseo conocer más sobre Índices Columnstore