Índice de almacenamiento Exadata

Los índices de almacenamiento son una función de Exadata diseñada para mejorar el rendimiento mediante la reducción de la E/S de disco.

A diferencia de los índices tradicionales de árbol B o mapa de bits, los índices de almacenamiento no almacenan valores específicos para ayudar a encontrar registros; en su lugar, rastrean los valores mínimos, máximos y nulos de los datos en trozos de almacenamiento de 1 MB.

Así es como funcionan:

Mecanismo de prefiltrado: Los índices de almacenamiento actúan como un filtro previo. Cuando se ejecuta una consulta, Exadata comprueba los predicados (por ejemplo, las condiciones de la cláusula WHERE) con los metadatos almacenados en los índices de almacenamiento (valores mínimos, máximos y nulos). Si el índice de almacenamiento muestra que ningún dato de un fragmento de almacenamiento de 1 MB coincide con las condiciones de la consulta, ese fragmento se omite, eliminando la necesidad de leerlo del disco.
Función de sólo memoria: Los índices de almacenamiento se guardan íntegramente en la memoria de las células de almacenamiento y nunca se escriben en disco. Esto los hace volátiles, lo que significa que deben reconstruirse después de reiniciar un servidor de almacenamiento.
Ocho columnas: Un índice de almacenamiento puede rastrear hasta ocho columnas de una tabla. No almacena los detalles de cada columna, sino que mantiene dinámicamente las que se consultan con más frecuencia.
Optimización de consultas: Los índices de almacenamiento son especialmente beneficiosos cuando se utilizan con Smart Scans, una función de Exadata que permite que el procesamiento de consultas se realice en el servidor de almacenamiento. Al filtrar previamente los datos irrelevantes, los índices de almacenamiento ayudan a Smart Scans a reducir la cantidad de datos procesados y devueltos a la capa de base de datos.
Tratamiento de los nulos: Los índices de almacenamiento también proporcionan una optimización única para las consultas que implican valores nulos, permitiendo búsquedas más rápidas en columnas que contienen nulos al eliminar las regiones no nulas de ser leídas.

Índice

En la práctica, los índices de almacenamiento pueden mejorar drásticamente el rendimiento.

Son más eficaces cuando los datos de las regiones de almacenamiento están bien agrupados u ordenados.

Sin embargo, existen limitaciones: no funcionan con determinados tipos de datos (por ejemplo, los CLOB) ni con operadores de comparación (por ejemplo, "!=").

En resumen, los índices de almacenamiento ayudan a reducir la E/S de disco al permitir que el sistema Exadata omita la lectura de regiones de almacenamiento que no pueden contener datos relevantes, lo que se traduce en un aumento significativo del rendimiento de las consultas.

Ejemplo de índice de almacenamiento Exadata

He aquí un ejemplo para ilustrar cómo funcionan los índices de almacenamiento en Exadata:

Escenario

Supongamos que tiene una tabla pedidos que contiene las siguientes columnas:

orden_id
fecha_pedido
customer_id
importe_total

La tabla tiene 1 millón de filas y los datos están distribuidos en varias regiones de almacenamiento de un sistema Exadata.

Consulta

Ejecute la siguiente consulta para recuperar los pedidos realizados en un intervalo de fechas específico:

SELECT * 
FROM orders 
WHERE order_date BETWEEN '2024-01-01' AND '2024-01-31';

Comportamiento del índice de almacenamiento

Creación de índices de almacenamiento: Exadata crea automáticamente índices de almacenamiento cuando se accede con frecuencia a la tabla.
Por cada trozo de 1 MB de datos almacenados en las celdas de almacenamiento, Exadata registra el mínimo y máximo valores para el fecha_pedido columna.

Ejemplo de índice de almacenamiento para una región de almacenamiento:
- Región 1: MIN(fecha_pedido) = '2023-11-15', MAX(fecha_pedido) = '2024-02-10'
- Región 2: MIN(fecha_pedido) = '2024-03-01', MAX(fecha_pedido) = '2024-03-31'
- Región 3: MIN(fecha_pedido) = '2023-10-05', MAX(fecha_pedido) = '2023-11-01'
Ejecución de consultas: Cuando ejecuta la consulta para buscar pedidos de enero de 2024, Exadata busca primero en los índices de almacenamiento.
- Región 1 contiene fechas comprendidas entre '2023-11-15' y '2024-02-10'por lo que esta región se leerá ya que incluye parte de enero de 2024.
- Región 2 contiene fechas comprendidas entre '2024-03-01' y '2024-03-31'por lo que Exadata se salta esta región completamente porque queda fuera del intervalo de consulta.
- Región 3 contiene fechas comprendidas entre '2023-10-05' y '2023-11-01'por lo que Exadata se salta esta región ya que es irrelevante para la consulta.
Reducción de datos: En lugar de escanear toda la tabla, Exadata sólo lee las regiones relevantes del disco.
Esto reduce la E/S, acelera la consulta y optimiza el rendimiento del sistema.

Beneficio

En este caso, como Exadata omitió regiones de almacenamiento irrelevantes (Región 2 y Región 3), la consulta finaliza más rápido, lo que se traduce en unos costes de E/S significativamente menores.

Este es un ejemplo de cómo los índices de almacenamiento ayudan a Exadata a omitir datos innecesarios y mejorar el rendimiento de las consultas.

DDL de creación de tablas e índices:

A continuación se muestra un ejemplo del lenguaje de definición de datos (DDL) para crear el archivo pedidos y cómo se crearía un índice en ella (si fuera necesario).

Tenga en cuenta que índices de almacenamiento en Exadata no son creados explícitamente por un DBA.

El software de almacenamiento de Exadata los gestiona automáticamente en función de los datos a los que se accede.

Sin embargo, también mostraré cómo se crearía normalmente un índice si se trata de un entorno sin Exadata.

Ejemplo de DDL para `pedidos` Cuadro

CREATE TABLE orders (
    order_id       NUMBER PRIMARY KEY,
    order_date     DATE,
    customer_id    NUMBER,
    total_amount   NUMBER(10, 2)
);

Esto crea una pedidos mesa con un clave primaria en orden_id.

En fecha_pedido será la que intervenga en el filtrado de consultas del ejemplo.

Nota sobre los índices de almacenamiento en Exadata

En Exadata, tú no crear manualmente índices de almacenamiento.

Exadata las gestiona automáticamente en memoria en función de las consultas que acceden con frecuencia a determinadas columnas.

No se puede controlar la creación del índice de almacenamiento como se hace con los índices tradicionales (por ejemplo, B-tree o bitmap).

Ejemplo de creación de índice tradicional (si se utiliza un sistema que no sea Exadata)

Si quisiera crear un índice de árbol B tradicional en fecha_pedidoescribirías algo así:

CREATE INDEX idx_order_date 
ON orders (order_date);

Este índice tradicional ayuda a optimizar las consultas que filtran en el fecha_pedidopero funciona de forma diferente a índices de almacenamiento.

Cómo funcionan los índices de almacenamiento en Exadata

Con Exadata, no es necesario crear un índice explícito en fecha_pedido para beneficiarse de los índices de almacenamiento.

El sistema Exadata crea y utiliza dinámicamente índices de almacenamiento en el nivel de la celda de almacenamiento siempre que detecte que una determinada columna (como fecha_pedido) se consulta con frecuencia.

Realiza un seguimiento de los valores mínimos y máximos de cada bloque de almacenamiento, lo que permite al sistema omitir bloques irrelevantes durante una consulta.

Resumiendo:

Índice tradicional: Se crea manualmente (como se muestra en el ejemplo anterior).
Índice de almacenamiento (Exadata): Gestionado automáticamente por el sistema, no requiere DDL.

Si ejecuta su base de datos en una máquina Exadata, sólo tiene que ejecutar sus consultas y Exadata utilizará automáticamente índices de almacenamiento para optimizarlas en función de los patrones de consulta.

Cómo comprobar si se ha utilizado un índice de almacenamiento

En Oracle Exadata, los índices de almacenamiento son gestionados automáticamente por el sistema, pero usted puede monitorizar y comprobar si los índices de almacenamiento están siendo utilizados durante la ejecución de consultas utilizando varias herramientas de monitorización y vistas.

He aquí algunas formas de verificar si se ha creado o utilizado un índice de almacenamiento durante la ejecución de una consulta:

1. V$SESSTAT Ver

Puede consultar las estadísticas de uso del índice de almacenamiento por sesión mediante la función V$SESSTAT que contiene estadísticas a nivel de sesión.

En concreto, la estadística celda física IO bytes guardados por índice de almacenamiento indicará si se han utilizado índices de almacenamiento.

A continuación se muestra una consulta que puede utilizar para comprobar si los índices de almacenamiento fueron utilizados por una sesión en particular:

SELECT s.sid, 
       s.value AS "Bytes Saved by Storage Index"
FROM v$sesstat s
JOIN v$statname n ON s.statistic# = n.statistic#
WHERE n.name = 'cell physical IO bytes saved by storage index';

Si la consulta devuelve un valor positivo en el campo Bytes ahorrados por índice de almacenamiento indica que se utilizaron índices de almacenamiento durante la ejecución de la consulta para esa sesión.

2. Eventos de espera específicos de Exadata

Otro indicador del uso del índice de almacenamiento es la reducción de los eventos de espera relacionados con la E/S.

Puede supervisar eventos de espera específicos en Exadata, como:

cell smart table scan
escaneo de índice inteligente de celdas

Estos eventos indican que se están realizando escaneos inteligentes y que, por extensión, los índices de almacenamiento pueden haber participado en la reducción de los datos a escanear.

Para comprobar los eventos de espera específicos de Exadata:

SELECT event, total_waits, time_waited
FROM v$session_event
WHERE event LIKE 'cell smart%';

Un elevado número de esperas para cell smart table scan puede indicar que se han utilizado índices de almacenamiento para omitir datos irrelevantes durante la exploración.

3. Comando CellCLI (en las celdas de almacenamiento)

Si tiene acceso a las celdas de almacenamiento propiamente dichas, puede utilizar la función CellCLI (Cell Command-Line Interface) para supervisar y analizar el rendimiento de las células de almacenamiento. Esto incluye comprobar si se están utilizando los índices de almacenamiento.

Para listar las estadísticas actuales de los índices de almacenamiento de una célula de almacenamiento, puede ejecutar lo siguiente CellCLI mando:

CellCLI> list metriccurrent where objectType = 'CELLIODATA' and name = 'DB_IO_BY_STORIDX'

Esto mostrará las métricas relacionadas con el uso del índice de almacenamiento en esa celda de almacenamiento en particular.

Busque valores en DB_IO_POR_STORIDX que indica cuántos datos se han ahorrado mediante el uso de índices de almacenamiento.

4. Informe de supervisión SQL

Cuando se ejecuta una consulta apta para la Exploración inteligente (y potencialmente para el uso de índices de almacenamiento), se puede generar un Informe de supervisión SQL para obtener información detallada sobre la ejecución.

El informe de supervisión de SQL le mostrará:

Si se ha utilizado la Exploración Inteligente.
Cuántos datos se filtraron utilizando los índices de almacenamiento.

Para generar el informe de supervisión de SQL, puede utilizar el siguiente comando SQL:

SELECT dbms_sqltune.report_sql_monitor(sql_id => 'your_sql_id') 
FROM dual;

Este informe permitirá saber si se utilizaron índices de almacenamiento, observando la reducción de datos procesados durante los escaneos inteligentes.

5. Vista DBA_HIST_SYSSTAT (Supervisión histórica)

Para comprobar el uso histórico de los índices de almacenamiento a lo largo del tiempo, puede consultar la base de datos DBA_HIST_SYSSTAT que registra las estadísticas de todo el sistema durante un periodo de tiempo.

SELECT s.snap_id,
       s.instance_number,
       ss.value AS "Storage Index IO Bytes Saved"
FROM dba_hist_sysstat ss
JOIN dba_hist_snapshot s ON ss.snap_id = s.snap_id
WHERE ss.stat_name = 'cell physical IO bytes saved by storage index';

Esta consulta proporcionará una visión general de cuántos bytes de E/S física fueron guardados por los índices de almacenamiento a lo largo del tiempo, tal y como se registra en las instantáneas AWR (Automatic Workload Repository).

Resumen

No puede crear manualmente índices de almacenamiento en Exadata, pero puede supervisar y verificar su uso:

Comprobación de las estadísticas a nivel de sesión (V$SESSTAT).
Análisis de los eventos de espera de Exadata (cell smart table scan).
Uso de comandos CellCLI en las células de almacenamiento.
Generación de informes de supervisión de SQL.
Observando las estadísticas históricas del sistema (DBA_HIST_SYSSTAT).

Estas herramientas le permitirán ver si se crearon índices de almacenamiento y cuándo se utilizaron para mejorar el rendimiento de las consultas.

¿Es necesario crear índices en Exadata?

No necesariamente.

En índices de almacenamiento en Exadata son gestionados automáticamente y creados dinámicamente por el sistema para optimizar el rendimiento, índices tradicionales (como los índices B-tree o bitmap) pueden seguir siendo beneficiosos en algunos casos.

A continuación se explica cuándo puede ser necesario crear índices tradicionales en Exadata y cuándo no:

1. Cuando los índices de almacenamiento son suficientes

Acceso secuencial a datos: Si la mayoría de sus consultas implican el escaneado secuencial de grandes cantidades de datos (por ejemplo, consultas de almacén de datos con escaneados completos de tablas), la tecnología de Exadata Escaneados inteligentes y índices de almacenamiento puede ser extremadamente eficaz para reducir la E/S y mejorar el rendimiento.
Consultas por rangos: Para consultas de rango (como rangos de fechas), los índices de almacenamiento pueden ayudar a omitir bloques irrelevantes y minimizar la E/S de disco sin necesidad de índices tradicionales.
Naturaleza dinámica: Los índices de almacenamiento se crean y mantienen dinámicamente en memoria, lo que significa que pueden ajustarse en función de los patrones de carga de trabajo sin requerir la intervención del DBA.

2. Cuando los índices tradicionales siguen siendo necesarios

Cargas de trabajo OLTP (procesamiento de transacciones en línea): En Entornos OLTPcuando las consultas suelen acceder a filas individuales o a pequeños conjuntos de datos (por ejemplo, buscar un cliente por su ID), las tradicionales Índices de árbol B puede seguir siendo necesario.
Los índices de almacenamiento de Exadata son más eficaces para reducir la E/S durante las exploraciones completas, pero no se utilizan en las búsquedas de una sola fila.
Condiciones de adhesión: Si sus consultas implican uniones en columnas que no son claves primarias, los índices tradicionales (por ejemplo, un índice de árbol B o de mapa de bits) pueden ayudar a mejorar el rendimiento de las uniones reduciendo el número de filas escaneadas.
Actualización de datos: En entornos con frecuentes actualiza o eliminaLos índices tradicionales pueden ayudar a garantizar la eficacia del acceso a las filas y las operaciones de mantenimiento.
Consultas de exploración inteligente no admisibles: No todas las consultas pueden utilizar la Exploración inteligente (por ejemplo, las consultas contra tablas pequeñas o las que implican operadores complejos).
Para esas consultas, los índices tradicionales pueden seguir siendo útiles.

3. Casos especiales en los que puede seguir necesitando índices tradicionales

Restricciones únicas: La creación de índices en columnas con restricciones únicas (por ejemplo, claves únicas, claves primarias) sigue siendo necesaria para garantizar la integridad de los datos.
Relaciones entre claves extranjeras: Los índices sobre claves externas pueden seguir siendo útiles para evitar el escaneo completo de la tabla durante las actualizaciones o eliminaciones en las tablas principales.
Sistemas no Exadata: Si tiene entornos mixtos en los que se puede acceder a los datos en sistemas Exadata y no Exadata, es posible que los índices tradicionales sigan siendo necesarios para optimizar el rendimiento en plataformas no Exadata.

4. Cargas de trabajo mixtas

Para los sistemas que tienen cargas de trabajo mixtas (una combinación de OLTP e informes), los índices tradicionales pueden complementar los índices de almacenamiento de Exadata.

Por ejemplo:

Cargas de trabajo OLTP se benefician de los índices tradicionales para consultar rápidamente las filas.
Consultas analíticas Benefíciese de los índices de almacenamiento de Exadata para realizar exploraciones eficientes a gran escala.

Conclusión:

En índices de almacenamiento pueden reducir la necesidad de índices tradicionales en Exadata, no son un sustituto completo. Aún debe considerar la creación de índices tradicionales para:

Entornos OLTP o cargas de trabajo mixtas.
Consultas que requieren búsquedas precisas de filas.
Aplicación de restricciones únicas y relaciones de clave externa.

En un entorno de almacén de datos en el que los escaneos completos de tablas son habituales, los índices de almacenamiento, combinados con Smart Scan y las optimizaciones de Exadata, pueden reducir en gran medida la necesidad de indexación tradicional.

Sin embargo, para cargas de trabajo OLTP o casos que impliquen consultas selectivas o condiciones de unión, los índices tradicionales pueden seguir siendo esenciales para un rendimiento óptimo.