""

Índices B-tree vs Bitmap: Consecuencias de la Indexación - Estrategia de Indexación para su Parte de Oracle Data Warehouse 2

En mi blog anterior B-árbol vs índices de mapa de bits - Estrategia de indexación para su Oracle Data Warehouse Respondí a dos preguntas relacionadas con la indización: ¿Qué tipo de índices podemos utilizar y en qué tablas / campos debemos usarlos. Como prometí al final de mi blog, ahora es el momento de responder a la tercera pregunta: ¿cuáles son las consecuencias de la indexación en términos de tiempo (tiempo de consulta, tiempo de creación de índice) y almacenamiento?

Consecuencias en términos de tiempo y almacenamiento

Para abordar este tema utilizaré una base de datos de prueba con un esquema en estrella muy simplificado: 1 tabla de hechos de los saldos de las cuentas de Libro mayor y 4 dimensiones - la fecha, la cuenta, la moneda y la rama banco).

Esquema simplificado de la estrella

Para dar una idea del tamaño de la tabla, Fact_General_Ledger tiene 4,5 millones de filas, Dim_Date 14 000, Dim_Account 3 000, Dim_Branch y Dim_Currency menos de 200.

Supongamos aquí que los usuarios pueden consultar los datos con filtro en la fecha, código de sucursal, código de moneda, código de cuenta y los niveles 3 de la jerarquía de balance (DIM_ACCOUNT.LVLx_BS). Suponemos que las descripciones no se utilizan en los filtros, sino sólo en los resultados.

Aquí está la consulta que usaremos como referencia:

Seleccionar

d.date_date,

a.account_code,

b.branch_code,

c.currency_code,

f.balance_num

de fact_general_ledger f

unirse a dim_account a en f.account_key = a.account_key

join dim_date d en f.date_key = d.date_key

unirse a dim_branch b en f.branch_key = b.branch_key

unirse a dim_currency c en f.currency_key = c.currency_key

Dónde

A.lvl3_bs = 'Depósitos con bancos' y

D.date_date = to_date ('16/01/2012', 'DD / MM / YYYY') y

b.branch_code = 1 y

C.currency_code = 'QAR' - Vivo en Qatar ;-)

Entonces, ¿cuáles son los resultados en términos de tiempo y almacenamiento?

Comparación de tiempo y almacenamiento

Algunas de las conclusiones que podemos extraer de esta tabla son:

  • Using indexes pays off: queries are really faster (about 100 times), whatever the chosen index type is.

  • En cuanto al tiempo de consulta, el tipo de índice no parece importar realmente para las tablas que no son tan grandes. Probablemente cambiaría para una tabla de hechos con 10 mil millones de filas. No obstante, parece existir una ventaja para los índices de mapa de bits y, especialmente, para los índices de combinación de mapa de bits (consulte la columna de costes del plan de explicación).

  • El almacenamiento es claramente a favor de los índices de combinación de mapa de bits y mapa de bits

  • El tiempo de construcción del índice es claramente a favor de b-tree. No he probado el tiempo de actualización del índice, pero la teoría dice que es mucho más rápido para los índices b-tree también.

Ok, estoy convencido de usar índices. ¿Cómo puedo crear / mantener una?

La sintaxis para crear índices b-tree y bitmap es similar:

Crear índice de mapa de bits Index_Name ON Nombre de tabla (FieldName)

En el caso de los índices b-tree, simplemente quite la palabra "Bitmap" de la consulta anterior.

La sintaxis para los índices de combinación de mapa de bits es más larga pero sigue siendo fácil de entender:

Crear índice de mapa de bits ACCOUNT_CODE_BJ

on fact_general_ledger (dim_account.account_code)

de fact_general_ledger, dim_account

donde fact_general_ledger.account_key = dim_account.account_key

Tenga en cuenta que durante su ETL, es mejor dejar / deshabilitar sus índices de combinación de mapa de bits / mapa de bits y volver a crearlos / reconstruirlos después, en lugar de actualizarlos. Se supone que es más rápido (sin embargo no he hecho ninguna prueba).

La diferencia entre drop / re-create y disable / rebuild es que cuando se deshabilita un índice, se mantiene la definición. Así que necesitas una sola línea para reconstruirla en lugar de muchas líneas para la creación completa. Sin embargo, los tiempos de generación del índice serán similares.

Para eliminar un índice: "drop index INDEX_NAME"

Para deshabilitar un índice: "alter index INDEX_NAME inutilizable"

Para reconstruir un índice: "alter index INDEX_NAME rebuild"

Conclusión

La conclusión es clara: ¡UTILICE LOS ÍNDICES! Cuando se usan correctamente, pueden aumentar realmente los tiempos de respuesta a las consultas. Piense en usarlos en su ETL también: hacer búsquedas puede ser mucho más rápido con los índices.

Si desea ir más lejos, sólo puedo recomendarle que lea la Guía de almacenamiento de datos de Oracle. Para conseguirlo, sólo busque en Internet (y no olvide especificar la versión de su base de datos - 10.2, 11.1, 11.2, etc.). Es un documento bastante interesante y completo.

EspañolEnglish