Uno de los mayores puntos fuertes de Denodo es que puede consultar los datos en el origen sin moverlos. Pero eso tiene un coste: si cada consulta va directa a la fuente, la latencia y la carga sobre esos sistemas puede dispararse. Para eso existe la caché de Denodo — y elegir el modo equivocado puede convertir una vista rápida en un cuello de botella, o en un informe con datos desactualizados sin que nadie se dé cuenta.
Los tres modos de caché
Denodo ofrece tres modos de caché para una vista, y cada uno resuelve un problema distinto:
Todas las consultas sobre la vista se responden siempre desde la caché, sin tocar nunca la fuente. Es el modo más rápido y predecible, pero los datos nuevos que lleguen al origen no aparecerán hasta que se vuelva a cargar toda la caché.
Solo se cachean los resultados que realmente se han consultado. Si una consulta no está en caché, Denodo va a la fuente, trae el resultado y lo guarda para la próxima vez. Útil cuando solo una parte de los datos se consulta con frecuencia.
Una mejora sobre la caché completa: combina los datos ya cacheados con los cambios más recientes traídos de la fuente, sin tener que recargar todo el histórico cada vez.
La caché incremental no es gratis: solo está disponible sobre base views, exige que la vista tenga una clave primaria, y necesita que la fuente pueda delegar la condición «dame las filas añadidas o modificadas desde una fecha concreta». Además, solo sirve si la fuente no borra físicamente filas — Denodo no puede detectar bajas, solo altas y modificaciones.
Cómo funciona la carga incremental por dentro
En lugar de recargar todo el conjunto de datos, Denodo usa un campo de fecha de modificación en el origen (por ejemplo, un campo tipo fecha_actualizacion) junto con una variable de interpolación especial, @LASTCACHEREFRESH, que representa el momento de la última carga. En cada actualización, solo se piden a la fuente las filas cambiadas desde ese instante, y se combinan con lo que ya había en caché usando la clave primaria: si una fila de la fuente coincide con una ya cacheada, gana siempre la versión más reciente.
Ejemplo con un dominio genérico
| Escenario | Modo recomendado | Por qué |
|---|---|---|
| Catálogo de productos, cambia poco | Full | Los datos son estables; una recarga periódica completa es suficiente y muy rápida de servir. |
| Consultas puntuales sobre un histórico enorme | Partial | No tiene sentido cachear todo el histórico si solo se consulta un subconjunto pequeño cada vez. |
| Tabla de transacciones que crece cada día | Incremental | Permite mantener la caché al día sin recargar años de datos históricos en cada actualización. |
Consejos prácticos
- Sitúa el motor de caché en el mismo segmento de red que el servidor de Denodo — la velocidad de transferencia entre ambos afecta directamente al rendimiento.
- Cuando sea posible, usa una de tus fuentes de datos principales como motor de caché: ayuda a maximizar el push-down de las consultas.
- No actives caché incremental sobre una fuente donde se puedan borrar filas físicamente — Denodo no se enterará de esas bajas y la caché quedará desincronizada.
- Define bien la frecuencia de refresco según la naturalidad del dato: no es lo mismo un catálogo de productos que una tabla de eventos en tiempo casi real.
- Antes de elegir un modo, mide primero: revisa qué porcentaje de las consultas repiten los mismos filtros antes de decidir entre full y partial.
¿Quieres ver cómo organizo mis vistas en Denodo antes incluso de pensar en la caché?
Leer el artículo sobre nomenclatura de capas