Cuando escribes una consulta sobre una vista de Denodo, esa consulta casi nunca se ejecuta tal cual la escribiste. Antes de tocar ninguna fuente de datos, el motor de virtualización la reescribe y la reordena buscando la forma más barata de resolverla. Entender cómo funciona ese optimizador ayuda a explicar por qué a veces una consulta vuela y otras veces, sin cambiar el resultado, se arrastra.
Dos fases de optimización
El optimizador de Denodo trabaja en dos fases, una detrás de otra:
Reescribe la consulta aplicando reglas que mejoran el rendimiento sin necesidad de conocer los datos reales: eliminar JOINs o particiones de UNION innecesarias (poda de ramas) y empujar condiciones y agrupaciones (group by) por debajo de JOINs y UNIONs, para filtrar y agregar lo antes posible.
Toma el plan que salió de la fase estática y evalúa distintas alternativas de ejecución, estimando su coste: qué algoritmo de JOIN usar (MERGE, HASH o NESTED), o si conviene mover resultados parciales a otra fuente de datos o a un sistema de procesamiento masivo en paralelo (MPP).
Join Pruning: eliminar JOINs que no cambian el resultado
Cuando una condición de JOIN se apoya en una clave primaria o un índice único, el optimizador puede llegar a una conclusión potente: sabe con certeza que ese JOIN no va a duplicar ni descartar filas de la otra tabla. Si además el resultado final no necesita columnas de esa tabla, el JOIN se puede eliminar por completo de la ejecución. Es especialmente útil en vistas que combinan varias tablas de una misma fuente, o en modelos con tablas de hechos o dimensiones particionadas verticalmente.
Aggregation Push-Down: agregar en el origen, no en Denodo
En consultas típicas de esquema en estrella que piden datos agregados (sumas, conteos, medias agrupadas por dimensión), el optimizador intenta empujar esa agregación hacia la propia fuente de datos en lugar de traer todas las filas en detalle y agregarlas en Denodo. El resultado es que viaja por la red muchísima menos información, lo que reduce de forma drástica los tiempos de ejecución.
Ninguna de estas optimizaciones funciona a ciegas: el optimizador necesita metadatos correctos para tomar buenas decisiones — claves primarias, índices, restricciones de integridad referencial, estadísticas de las vistas y, si se usan, la configuración de los data movement y de aceleración con MPP.
Ejemplo con un dominio genérico
| Situación | Optimización aplicada | Efecto |
|---|---|---|
| Vista con JOIN a una tabla de la que solo se usa la clave | Join Pruning | El JOIN se elimina de la ejecución; la fuente ni siquiera lo recibe. |
| Informe de ventas totales por región y mes | Aggregation Push-Down | La suma y el agrupado se calculan en el origen; Denodo solo recibe el resultado ya agregado. |
| Consulta con un filtro por fecha antes de un UNION de varias particiones | Poda de ramas (optimización estática) | Las particiones que no pueden contener esa fecha se descartan antes de consultar ninguna fuente. |
Consejos prácticos
- Declara siempre las claves primarias, índices y restricciones de integridad referencial en las vistas — sin esos metadatos, el optimizador no puede aplicar Join Pruning ni muchas otras optimizaciones.
- Mantén actualizadas las estadísticas de las vistas: la optimización basada en costes depende directamente de que esos números reflejen los datos reales.
- Cuando una consulta agregada vaya lenta, revisa primero si la agregación se está resolviendo en el origen o si está viajando el detalle completo hasta Denodo.
- En vistas que combinan muchas tablas, revisa qué columnas se seleccionan realmente al final — columnas de más pueden impedir que el optimizador elimine JOINs que de otro modo serían prescindibles.
- Antes de tocar la configuración del optimizador a mano, usa las herramientas de Denodo para inspeccionar el plan de ejecución de la consulta y confirmar dónde está realmente el cuello de botella.
¿Quieres ver cómo decido qué modo de caché usar antes de que el optimizador entre en juego?
Leer el artículo sobre caché en Denodo