Índices Personalizados en SAP HANA

En el mundo SAP, el rendimiento lo es todo. Y cuando hablamos de SAP HANA, muchos confían plenamente en su motor inteligente para optimizar consultas sin necesidad de intervenir. Pero, ¿qué pasa cuando el rendimiento no es el esperado?

SAP HANA está diseñado para ofrecer alto rendimiento sin necesidad de índices secundarios, gracias a su arquitectura in-memory, el almacenamiento orientado a columnas, la compresión avanzada y el paralelismo masivo. Sin embargo, existen escenarios bien definidos donde la creación de índices personalizados puede mejorar significativamente el tiempo de respuesta de las consultas.

Por defecto, HANA utiliza el almacenamiento columnar, lo que permite leer solo las columnas necesarias para cada consulta. Por ejemplo, en una tabla con 150 columnas, una consulta que solo accede a 3 de ellas evita leer el resto, lo que representa una reducción de I/O y uso de memoria de hasta un 98%. Además, las columnas homogéneas se comprimen mejor; en algunos entornos OLAP reales, se logran ratios de compresión de hasta 7:1.

El motor de ejecución paraleliza automáticamente las operaciones. Una query compleja con múltiples JOINs y agregaciones puede ser distribuida entre 32 núcleos o más, reduciendo el tiempo de ejecución de minutos a segundos. El optimizador de HANA, además, analiza estadísticas de cardinalidad, distribución de valores, y costo estimado por operador para determinar el mejor plan posible. En este contexto, la creación manual de índices es innecesaria en la mayoría de los casos.

No obstante, hay situaciones donde los índices personalizados sí ofrecen una ventaja tangible. Consideremos algunos ejemplos:

Supongamos una consulta como:

SELECT p.nombre, v.total 
FROM ventas v 
JOIN productos p ON v.id_producto = p.id 
WHERE p.categoria = 'Servicios';

Si la tabla productos tiene 1 millón de registros pero solo 6 categorías posibles, un índice en p.categoria puede acelerar significativamente la filtración post-join. En pruebas de laboratorio con tablas de 10M de registros, la creación de un índice en una columna de 10 valores únicos redujo el tiempo de ejecución de 950 ms a 210 ms.

Si múltiples consultas usan:

… JOIN logs l ON l.usuario_email = u.email

Y usuario_email no está indexado, el optimizador puede fallar en estimar correctamente el costo. Un índice en l.usuario_email puede reducir el tiempo de búsqueda de un hash join de O(n) a O(log n). En una tabla de 5 millones de filas, se ha observado una mejora del 65% en la latencia.

En sistemas híbridos OLTP/OLAP donde una aplicación busca datos como:

SELECT * FROM pedidos WHERE codigo_interno = 'ABX-9211';

Si codigo_interno no forma parte de la clave primaria, HANA deberá escanear toda la columna (full column scan). Crear un índice hash puede hacer que la búsqueda pase de 400 ms a <10 ms en tablas medianas (500.000 filas).

Cuando una consulta contiene:

WHERE YEAR(fecha_factura) = 2024

El índice tradicional en fecha_factura no se aprovecha porque el optimizador no puede usarlo directamente sobre una función. Una solución eficiente es crear un índice calculado sobre YEAR(fecha_factura), lo que permite a HANA utilizarlo para filtrar antes de procesar el resto. En una tabla de 2M de facturas, esto puede reducir la latencia de 1.8 s a 230 ms.

Riesgos asociados a la creación de índices

Crear índices sin un análisis puede impactar negativamente en el correcto y fluido funcionamiento del sistema HANA, ya que cada índice ocupa espacio adicional. Un índice en una tabla de 10M filas puede requerir entre 100 MB y 1 GB, según la cardinalidad y tipo de datos, las operaciones INSERT, UPDATE y DELETE se vuelven más lentas, ya que deben actualizar cada índice. En pruebas internas, el INSERT de 100.000 registros aumentó de 4 a 9 segundos al agregar 3 índices. Esto sin contar que mantener demasiados índices es engorroso y requiere un esfuerzo constante.

Mis recomendaciones

SAP HANA ofrece un rendimiento excelente por diseño. Pero como todo sistema, tiene puntos de optimización cuando se enfrenta a patrones específicos de acceso. Los índices personalizados deben usarse como herramientas quirúrgicas, no como soluciones universales. El conocimiento del modelo de datos, los patrones de consulta y las cargas del sistema es lo que permite tomar decisiones correctas. Crear un índice debe ser el resultado de un diagnóstico, no un reflejo automático. Cuando se aplican con criterio, los resultados son medibles, sostenibles y valiosos.

Yo recomiendo siempre trabajar sobre los datos reales. Es decir, identificar las consultas lentas utilizando Performance Analysis Mode en HANA Studio o PlanViz, buscar los full scans que puedan existir en las consultas o los joins mal optimizados.

Una vez identificadas las consultas mas lentas, lo ideal es comenzar a reescribir las consultas. A veces pequeños cambios pueden hacer grandes diferencias. Luego, si no hay lugar a la reescritura, ya sea porque la consulta es std, o porque está optimizada, crear los índices necesarios en el sistema.