¿Por qué se utiliza el índice de mapa de bits en el almacenamiento de datos?

Estoy completamente en desacuerdo con la respuesta de Corrin Lakeland (los votos positivos me asustan, teniendo en cuenta las credenciales).

En primer lugar, comencemos con lo básico. Cuando indexa un campo en una tabla RDBMS, puede crear uno de dos tipos de índices: 1) B-Tree y 2) Bitmap. Ambas son estructuras de datos sobre cómo se almacenan los índices.

1) un B-Tree almacena los valores indexados en un árbol equilibrado. Esto hace que los elementos de inserción / actualización / eliminación del árbol O (log n) por fila completen el tiempo de ejecución con O (n) en el espacio de almacenamiento. Dado que a menudo hará inserciones / actualizaciones en un Data Warehouse y el almacenamiento crecerá bastante rápido (piense en big data), B-Tree es una buena solución general.

Árbol B

2) Un índice de mapa de bits crea una matriz de todos los valores posibles de un campo con cada fila de ese campo. En esta matriz, se almacena un valor de 1 o 0, el valor es un 1 si el valor de este campo de base de datos = el valor de la columna de la matriz.

es decir: Digamos que tengo un campo llamado género en mi tabla de empleados, los valores posibles son masculino, femenino, desconocido.

Digamos que hay 4 empleados, Bob, John, Jenny, Uber.

El índice de mapa de bits se verá así:

hombre | mujer | desconocido

Bob 1 | 0 | 0 0

Jenny 0 | 1 | 0 0

Juan 1 | 0 | 0 0

Uber 0 | 0 | 1

Ese es un índice de mapa de bits. Cuando el índice se activa (es decir, desea todas las empleadas), el motor de la base de datos solo buscará en la columna femenina del mapa de bits y devolverá filas que = 1. Esto es mucho más rápido en comparación con un árbol B, mientras que debe atravesar el árbol, encuentre el nodo, compare todas las letras del campo de género para darse cuenta de que sí, de hecho Bob es un hombre.

Para n filas en la tabla, Bitmap tiene una complejidad de tiempo de ejecución de O (n), ya que solo busca una vez por fila. Para un árbol B, es O (n log n) ya que atravesar el árbol B es O (log n) por fila, luego hay n filas para buscar.

Desafortunadamente, puede ver que si tengo un millón de filas, tendré 3 x 1 millón de valores en el índice de mapa de bits, mientras que el árbol B tendrá solo 1 millón (es O (n)). Si uso esto en un campo con 50 valores diferentes, tendré 50 millones de valores que deben almacenarse, mientras que el árbol B todavía tendrá 1 millón.

No se recomienda el uso de índices de mapa de bits en campos con una gran cantidad de valores únicos.

Por lo tanto, puede ver que esto no tiene absolutamente nada que ver con si sabe de antemano qué campos se utilizarán en una cláusula where.

La razón por la que se utilizan los índices de mapa de bits en DW es que, en DW, puede (y debe) crear campos de soporte para facilitar la consulta. Por ejemplo, si los usuarios hacen muchas preguntas comunes como ¿este empleado cumplió con el punto de referencia? ¿Esta venta tuvo devoluciones parciales / completas? Crearía campos como IS_ABOVE_BENCH_MARK o IS_REFUNDED; donde los valores de esos campos son 1 o 0. Entonces, cuando realice una consulta, solo dirá IS_ABOVE_BENCH_MARK = 1, otorgue bonificación … o algo así.

Esto significa que todos estos campos pueden tener un índice de mapa de bits, ya que USTED está controlando que los valores sean limitados (sí, es un índice de mapa de bits en un campo de bits).

Esta es solo una idea aproximada, ya que las ideas de índice pueden volverse muy complicadas (por ejemplo, ¿cómo se vincula el valor a la fila? ¿Cómo se ve un índice B-Tree en múltiples campos y cómo funciona eso donde no lo hago? tiene todos los campos en la consulta?). Se pone desordenado.

Así que voy a detenerlo aquí y decir que es por eso que usamos el índice de mapa de bits en DW.

Porque los almacenes de datos manejan muchas consultas inesperadas. Un sistema OLTP puede ocuparse de consultas desagradables, pero no cambian mucho, por lo que los índices y los modelos de datos se pueden diseñar a su alrededor.

Los almacenes de datos deben manejar todo lo que les arrojes. La mayoría de las veces es una tabla de hechos unida a un montón de tablas de dimensiones, pero luego debes tener en cuenta la cláusula where. Los índices de mapa de bits son ideales ya que pueden ser una combinación de prácticamente cualquier cosa de las tablas de origen.

Puede decir 3 campos diferentes en una cláusula where y encontrar extremadamente rápidamente qué filas satisfacen los tres. Si siempre tuvo los mismos 3 campos, un índice compuesto sería mejor, pero cuando no tiene idea de qué tres campos se consultarán, un mapa de bits es realmente el único camino a seguir. Tenga en cuenta que esto está comenzando a cambiar a medida que las bases de datos en columnas se vuelven más populares.

Rendimiento * pensó que esto es discutible [1].

* Donde la mayoría de las tablas consisten en campos que tienen baja cardinalidad, es decir, un conjunto limitado de valores distintos. Por ejemplo, campos como IsSmoker , IsMarried, etc. → S / N o campos como Género → M / F / U.

[1] ¿Por qué los índices de baja cardinalidad afectan negativamente el rendimiento?