Tomar la decisión acertada: Comprimir ó no un índice

Los índices de las tablas serán siempre un tema de discusión y discordia. A pesar de existir un conjunto de reglas básicas, los criterios utilizados para determinar su creación, aplicación y administración, pueden ser tan distintos y distantes unas de otras. En algunas ocasiones podría ser difícil, llegar a un punto intermedio, en donde todos los puntos de vista, sean simplemente aceptados, sin que exista de por medio, la famosa pregunta: Porqué?.

Veamos tenemos los siguientes tipos de índices:

1. Bitmap Indexes
2. Index Organised Table
3. Partitioned Indexes
4. Reverse Key
5. LOB Index
6. Compressed
7. Function-Based Indexes
8. Descending
9. Virtual Indexes
10. Bitmap Join Indexes
11. Domain Indexes
12. Btree

Cada uno de estos tipos de índices tienen su característica especial, desde el más simple como lo es el tipo "Btree" que dicho sea de paso es el sistema de indexación de facto de Oracle, hasta los más complejos, como los índices "Bitmap Join" y "Domain". La disponibilidad de cada uno de ellos, depende del tipo de motor de base de datos que estemos empleando. ( One Edition, SE, EE ). La sintáxis para cada uno de estos tipos de índices e información adicional, la pueden observar en el sitio tahiti.oracle.com y pueden utilizar como referencia el manual de "Oracle® Database Performance Tuning Guide11g Release 2 (11.2)"

Ahora, la razón de ser de este post, va dirigida a encontrar un criterio que me índique de manera sencilla y simple, cuando y como utilizar el atributo de compresión de un índice.?

Para muchos, el crear un índice, es como servirse un café en la mañana, en el desayuno cuando sales para el trabajo. Del corre corre, posiblemente no hayas captado el olor y saber, que tanto apreciamos, aquellas personas que disfrutamos de buen café, al inicio de nuestra jornada de trabajo.

Si eres catador de esta bebida, sabrás, que un buen café no requiere de endulzantes para ser digerido y que el exceso de dulce, puede hechar a perder ese sabor, tan particular que tiene la bebida.

Sin temor a equivocarnos, un índice es como una taza de café. Si empleas más allá de las columnas realmente necesitadas o te equivocas a la hora de escogerlas, el resultado, puede ser simplemente desastrozo.

Para crear un índice, es necesario que conozca a detalle, las características que encierra cada columna de tu tabla. Estamos hablando por ejemplo, del tipo de dato almacenado, el nivel de "selectividad" de las columnas, el comportamiento que puede tener las columnas en cuanto a ser candidatas a cambios en su contenido, entre otras.

Una columna en una tabla que se utilizada para guardar el tipo de dato de "sexo", tiene un comportamiento semejante a un dato binario. Sólo dos posibles valores pueden ser asociados a los cientos de registros que podrían llegar a existir en la tabla.

Una columna que sea utilizada para guardar el tipo de dato con elementos como ID, número de seguro social y pasaporte de una persona, será un valor único entre todos los posibles registros que sean almacenados en ella.

Entre el tipo de dato "sexo" y "pasaporte", cuál es el más selectivo entre ellos.? En Oracle, cuando realizamos una consulta sobre una tabla y la misma regresa más del 5% de los registros totales de la misma, es FTS ( Full Table Scan ) por regla, para hablarlo en términos beisboleros.

FTS significa mayor cantidad de I/O, CPU y Memoria utilizados para devolver los datos. En pocas palabras, FTS puede generar una disminución del rendimiento global a nivel de la base de datos.

La respuesta a la pregunta es: pasaporte, ya que este campo, me permitirá devolver una y sólo una concurrencia de valor en toda la tabla, para la constante ingresada. Será menor la cantidad de bloques que deba leer, menor la utilización de CPU y por ende también, menor cantidad de memoria física utilizada, en el área de ordenamiento de datos y de estructuras de memoria de la sesión del usuario.

Podemos obviar del todo, utilizar valores de columnas con bajo nivel de selección.? La respuesta es no. Tipos de datos como, país, estado, provincia, departamento y compañía, son algunos ejemplos, de campos utilizados comúnmente en nuestros diseños de tablas.

Ahora bien, lo que si puede darse, es que necesitemos hacer una búsqueda de datos, utilizando el ID de un empleado, su departamento y compañia a la que pertenece. Si necesitaramos crear un índice, la sentencia sería:

create index id_busqueda_01_idx on empleados(no_cia, depto, id_empleado) compress 2;

En este caso, los dos primeros campos, son campos con un bajo nivel de selección. Si para este ejemplo, tenemos que no_cia es un varchar2(3), depto varchar2(20), id_empleado varchar2(12), con la sentencia anterior, le estamos pidiendo al motor de la base de datos, que elimine la duplicación de llaves para los dos primeros campos, que no son únicos en la definición del índice. Este atributo, puede producir, que el tamaño del índice, pueda estar por debajo del 50% del tamaño normal, que podría requerir, sino se comprime dichas columnas.

Ahora, cuando debo utilizar este atributo y cuando no. Alguién por ahí dijo, "Hágalo fácil, para que funcioné". Utilice el atributo de compresión, sólo y sólo si, los valores de las columnas involucradas en la compresión, no sufrirán constantes cambios, o sea, actualizaciones.

Si las columnas son objeto de frecuentes actualizaciones de información, no deben ser comprimidas, cuando forme parte de un índice.

Que de la taza de café, que tome el día de hoy, pueda disfrutar su sabor y olor, como nunca lo ha hecho.