On my previous blog post B-tree vs Bitmap indexes - Indexing Strategy for your Oracle Data Warehouse I answered two questions related to Indexing: Which kind of indexes can we use and on which tables/fields we should use them. As I promised at the end of my blog, now it´s time to answer the third question: what are the consequences of indexing in terms of time (query time, index build time) and storage?
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
The conclusion is clear: USE INDEXES! When properly used, they can really boost query response times. Think about using them in your ETL as well: making lookups can be much faster with indexes.
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.