Oracle Analytics Cloud mantiene una caché local de juegos de resultados de consulta en la caché de consulta.
Temas:
La caché de consulta permite a Oracle Analytics Cloud satisfacer muchas solicitudes de consulta subsiguientes sin acceder a orígenes de datos de backend, lo cual incrementa el rendimiento de la consulta. Sin embargo, las entradas de la caché de consulta podrían quedarse desactualizadas ya que las actualizaciones se producen en los orígenes de datos de backend.
La manera más rápida de procesar una consulta es omitir el bloque del procesamiento y utilizar una respuesta calculada previamente.
Con la caché de consulta, Oracle Analytics Cloud almacena los resultados de las consultas calculados previamente en una caché local. Si otra consulta puede utilizar esos resultados, se elimina todo el procesamiento de base de datos para dicha consulta. Esto puede causar una mejora considerable en el tiempo medio de respuesta de consulta.
Además de mejorar el rendimiento, poder responder a una consulta desde una caché local permite ahorrar recursos de red y tiempo de procesamiento en el servidor de base de datos. Se ahorran recursos de red porque los resultados intermedios no se devuelven a Oracle Analytics Cloud. Al no ejecutar la consulta en la base de datos se libera el servidor de base de datos para que realice otros trabajos. Si la base de datos utiliza un sistema de contracargo, la ejecución de menos consultas también puede reducir costos en el presupuesto.
Otra ventaja de utilizar la caché para responder a una consulta es el ahorro en el tiempo de procesamiento en Oracle Analytics Cloud, especialmente si los resultados de la consulta se recuperan de varias bases de datos. Dependiendo de la consulta, puede haber un procesamiento de unión y ordenación considerable en el servidor. Si ya se ha calculado la consulta, se evita este procesamiento, de este modo se liberan recursos del servidor para otras tareas.
En resumen, la caché de consulta puede mejorar el rendimiento de consulta y reducir el tráfico de red, el procesamiento de base de datos y la sobrecarga de procesamiento sustancialmente.
El almacenamiento en caché tienes muchas ventajas evidentes, pero también determinados costos.
La posibilidad de que los resultados almacenados en caché estén desactualizados
Costos administrativos de gestión de la caché
Con las gestión de la caché, normalmente los beneficios superan con creces los costos.
Algunas tareas administrativas están asociadas al almacenamiento en caché. Debe definir correctamente el tiempo de persistencia de caché de cada tabla física, sabiendo con qué frecuencia se actualizan los datos de esa tabla.
Cuando la frecuencia de la actualización varía, debe realizar un seguimiento de cuándo se producen los cambios y depurar la caché manualmente cuando sea necesario.
Si no se depuran las entradas de caché cuando cambian los datos en las bases de datos subyacentes, es posible que las consultas devuelvan resultados que no están actualizados.
Debe evaluar si esto es aceptable. Puede ser aceptable permitir que la caché contenga algunos datos desactualizados. Debe decidir qué nivel de datos desactualizados es aceptable y, a continuación, configurar (y seguir) un juego de reglas que reflejen ese nivel.
Por ejemplo, suponga que una aplicación analiza datos corporativos de un gran conglomerado y que usted está realizando resúmenes anuales de las diferentes divisiones de la compañía. Los nuevos datos no afectan significativamente a las consultas porque solo afectan a los resúmenes del siguiente año. En este caso, las compensaciones para decidir si se debe purgar la caché pueden decantarse a favor de dejar las entradas en la caché.
Sin embargo, suponga que las bases de datos se actualizan tres veces al día y que está realizando consultas sobre las actividades del día actual. En este caso, debe depurar la caché con mucha mayor frecuencia o quizás considerar la posibilidad de no utilizar la caché en absoluto.
Otro escenario puede ser que vuelva a crear el juego de datos desde el principio a intervalos periódicos (por ejemplo, una vez a la semana). En este ejemplo, puede purgar la caché completa como parte del proceso de recreación del juego de datos, garantizando que nunca tiene datos desactualizados en la caché.
Independientemente de la situación, debe evaluar qué es aceptable para la información no actual que se devuelve a los usuarios.
Si está activada la conexión compartida para un pool de conexiones concreto, se puede compartir la caché entre los usuarios y esta no se tiene que iniciar para cada usuario.
Si no está activada la conexión compartida y se utiliza una conexión a base de datos especifica del usuario, cada usuario genera su propia entrada de caché.
En Oracle Analytics Cloud, la caché de consulta está activada por defecto. Puede activar o desactivar la caché de consulta en la página Configuración del sistema.
Para gestionar los cambios en las bases de datos subyacentes y supervisar las entradas de caché, debe desarrollar una estrategia de gestión de caché.
Necesita un proceso para invalidar las entradas de caché cuando cambian los datos en las tablas subyacentes que componen la entrada de caché, así como un proceso para supervisar, identificar y eliminar todas las entradas de caché no deseadas.
Esta sección incluye los siguientes temas:
La elección de una estrategia de gestión de caché depende de la volatilidad de los datos en las bases de datos subyacentes y de la previsibilidad de los cambios que causan esta volatilidad.
También depende del número y los tipos de consultas que componen la caché y del uso que se hace de dichas consultas. En esta sección se proporciona una visión general de los diferentes enfoques de la gestión de caché.
Puede desactivar el almacenamiento en caché para todo el sistema a fin de impedir que todas las entradas de caché nuevas y todas las consultas nuevas utilicen la caché existente. La desactivación del almacenamiento en caché le permite activarla posteriormente sin perder ninguna de las entradas almacenadas en la caché.
La desactivación temporal del almacenamiento en cache es una estrategia útil en situaciones en las que pueda sospechar que tiene entradas de caché desactualizadas, pero desee verificar si están realmente desactualizadas antes de depurar dichas entradas o la caché completa. Una vez que haya comprobado que los datos almacenados en la caché siguen siendo relevantes, o que haya depurado las entradas problemáticas de forma segura, puede activar la caché de forma segura. Si es necesario, depure la caché completa o la caché asociada a un modelo de negocio concreto antes de volver a activar la caché.
Puede definir un atributo almacenable en caché para cada tabla física, lo cual le permite especificar si las consultas de esa tabla se agregan a la caché para responder a consultas futuras.
Si activa el almacenamiento en caché para una tabla, se agregarán a la caché todas las consultas referentes a la tabla. Todas las tablas se pueden almacenar en caché por defecto, pero es posible que algunas tablas no sean buenas candidatas para incluirlas en la caché a menos que configure el valor de persistencia de caché adecuado. Por ejemplo, suponga que tiene una tabla que almacene datos de cotizaciones bursátiles que se actualizan cada minuto Puede especificar que desea purgar las entradas de esa tabla cada 59 segundos.
También puede utilizar los valores de persistencia de caché para especificar cuánto tiempo se almacenan las entradas de esta tabla en la caché de consulta. Resulta útil para orígenes de datos que se actualizan con frecuencia.
En la capa física de la herramienta de administración de modelos, haga doble clic en la tabla física.
Si utiliza el modelador semántico, consulte ¿Cuáles son las propiedades generales de la tabla física?.
En el cuadro de diálogo de propiedades Tabla física, en el separador General, realice una de las siguientes selecciones:
Para activar el almacenamiento en caché, seleccione Permite caché.
Para impedir que una tabla se almacene en caché, anule la selección de Permite caché.
Para definir un tiempo de caducidad de caché, especifique un Tiempo de persistencia de caché y una unidad de medida (días, horas, minutos o segundos). Si no desea que caduquen automáticamente las entradas de caché, seleccione La caché nunca caduca.
Haga clic en Aceptar.
Cuando modifica los modelos semánticos mediante el modelador semántico o la herramienta de administración de modelos, estos cambios pueden tener implicaciones para las entradas que se almacenan en la caché. Por ejemplo, si cambia la definición de un objeto físico o de una variable de modelo semántico dinámica, es posible que las entradas de caché que hacen referencia a dicho objeto o variable ya no sean válidas. Estos cambios pueden provocar la necesidad de depurar la caché. Hay dos escenarios que se deben tener en cuenta: cuando modifica el modelo semántico existente y cuando crea (o carga) un nuevo modelo semántico.
Cambios en el modelo semántico
Cuando modifica un modelo semántico o carga un archivo .rpd diferente, todos los cambios que realice que afecten a las entradas de caché provocan automáticamente la depuración de todas las entradas de caché que hacen referencia a los objetos modificados. La depuración se produce cuando carga los cambios. Por ejemplo, si suprime una tabla física de un modelo semántico, se depuran todas las entradas de caché que hacen referencia a esa tabla al desbloquear. Cualquier cambio que se realice en un modelo semántico en la capa lógica depurará todas las entradas de caché para dicho modelo semántico.
Cambios en las variables de modelo semántico globales
Los valores de las variables de modelo semántico globales se refrescan con los datos que se devuelven de las consultas. Al definir una variable de modelo semántico global, debe crear un bloque de inicialización o utilizar uno existente que contenga una consulta SQL. También configura un programa para ejecutar la consulta y refrescar periódicamente el valor de la variable.
Si cambia el valor de una variable de modelo semántico global, quedarán desactualizadas todas las entradas de caché que utilizan esta variable en una columna y se generará una nueva entrada de caché cuando los datos de esa entrada vuelvan a ser necesarios. La antigua entrada de caché no se elimina inmediatamente, sino que permanece hasta que se limpia mediante el mecanismo normal de almacenamiento en caché.
Una de las principales ventajas de la caché de consulta es la mejora del rendimiento aparente de consulta.
La caché de consulta puede ser valiosa para iniciar la caché durante las horas libres mediante la ejecución de consultas y el almacenamiento en caché de sus resultados. Una buena estrategia de inicio requiere que conozca cuándo se producen los aciertos de caché.
Si desea iniciar la caché para todos los usuarios, puede iniciarla con la siguiente consulta:
SELECT User, SRs
Una vez iniciada la caché con SELECT User, SRs, las siguientes consultas son aciertos de caché:
SELECT User, SRs WHERE user = valueof(nq_SESSION.USER) (and the user was USER1) SELECT User, SRs WHERE user = valueof(nq_SESSION.USER) (and the user was USER2) SELECT User, SRs WHERE user = valueof(nq_SESSION.USER) (and the user was USER3)
Esta sección incluye los siguientes temas:
Cuando el almacenamiento en caché está activado, se evalúa cada consulta para determinar si está cualificada para un acierto de caché.
Un acierto de caché significa que Oracle Analytics Cloud ha podido utilizar la caché para responder a una consulta sin ir a la base de datos. Oracle Analytics Cloud puede utilizar la caché de consulta para responder a consultas en el mismo nivel de agregación o uno superior.
Hay varios factores que determinan si se produce un acierto de caché. En la siguiente tabla se describen estos factores.
| Factor o regla | Descripción |
|---|---|
|
Un subjuego de columnas de la lista |
Para que esté cualificada para un acierto de caché, todas las columnas de la lista Esta regla describe el requisito mínimo para un acierto de caché, pero el cumplimiento de esta regla no garantiza un acierto de caché. También se aplican las reglas restantes de esta tabla. |
|
Las columnas de la lista |
Oracle Analytics Cloud puede calcular expresiones en los resultados en caché para responder a la nueva consulta, pero todas las columnas deben estar en el resultado en caché. Por ejemplo, la consulta: SELECT product, month, averageprice FROM sales WHERE year = 2000 coincide con la caché en la consulta: SELECT product, month, dollars, unitsales FROM sales WHERE year = 2000 porque |
|
La cláusula |
Para que la consulta esté cualificada como un acierto de caché, las restricciones de la cláusula Una cláusula
Además, todas las columnas que se utilizan en la cláusula SELECT employeename
FROM employee, geography
WHERE region in ('EAST', 'WEST')
No da como resultado un acierto de caché para la consulta inicial en la lista anterior porque REGION no está en la lista de proyecciones. |
|
Las consultas solo de dimensión deben ser una coincidencia exacta |
Si una consulta es solo de dimensión, lo que significa que no está incluido ningún hecho o medida en la consulta, solo una coincidencia exacta de las columnas de proyección de la consulta en caché coincide con la caché. Este comportamiento evita falsos positivos cuando hay varios orígenes lógicos para una tabla de dimensiones. |
|
Las consultas con funciones especiales deben ser una coincidencia exacta |
Otras consultas que contienen funciones especiales, como las funciones de serie temporal ( |
|
El juego de tablas lógicas debe coincidir |
Para estar cualificadas como un acierto de caché, todas las consultas entrantes deben tener el mismo juego de tablas lógicas que la entrada de caché. Esta regla evita aciertos de caché falsos. Por ejemplo, |
|
Los valores de las variables de sesión deben coincidir, incluidas las variables de la sesión de seguridad |
Si la sentencia SQL lógica o física hace referencia a cualquier variable de sesión, los valores de la variable de sesión deben coincidir. De lo contrario, no hay una coincidencia con la caché. Además, el valor de las variables de sesión que son sensibles a la seguridad debe coincidir con los valores de las variables de sesión de seguridad definidos en el modelo semántico, incluso aunque la propia sentencia SQL lógica no haga referencia a las variables de sesión. Consulte Garantizar resultados de caché correctos al utilizar la seguridad de base de datos de nivel de fila. |
|
Condiciones de unión equivalentes |
La tabla lógica unida resultante de una nueva solicitud de consulta tiene que ser la misma que (o un subjuego de) los resultados en caché para estar cualificada para un acierto de caché. |
|
El atributo |
Si una consulta en caché elimina registros duplicados con el procesamiento |
|
Las consultas deben contener niveles de agregación compatibles |
Las consultas que solicitan un nivel de información agregado pueden utilizar resultados en caché en un nivel de agregación inferior. Por ejemplo, la siguiente consulta solicita la cantidad vendida en el nivel de proveedor y región y ciudad: SELECT supplier, region, city, qtysold FROM suppliercity La siguiente consulta solicita la cantidad vendida en el nivel de ciudad: SELECT city, qtysold FROM suppliercity La segunda consulta tiene como resultado un acierto de caché en la primera consulta. |
|
Agregación adicional limitada |
Por ejemplo, si una consulta con la columna |
|
La cláusula |
Las consultas que ordenan por columnas que no están contenidas en la lista de selección tienen como resultado faltas de caché. |
|
Diagnóstico del comportamiento del acierto de caché |
Para una mejor evaluación del comportamiento del acierto de caché, defina la variable de sesión ENABLE_CACHE_DIAGNOSTICS en 4, como se muestra en el siguiente ejemplo: ENABLE_CACHE_DIAGNOSTICS=4 |
Al utilizar una estrategia de seguridad de base de datos de nivel de fila, como la base de datos privada virtual (VPD), los resultados de datos devueltos dependen de las credenciales de autorización del usuario.
Debido a esto, Oracle Analytics Cloud debe conocer si un origen de datos está utilizando la seguridad de base de datos de nivel de fila y qué variables son relevantes para la seguridad.
Para garantizar que los aciertos de caché solo se producen en las entradas de caché que incluyen y coinciden con todas las variables sensibles a la seguridad, debe configurar correctamente el objeto de base de datos y los objetos de variable de sesión en la herramienta de administración de modelos como se describe a continuación:
Objeto de base de datos. En la capa física, en el separador General del cuadro de diálogo Base de datos, seleccione Base de datos privada virtual para especificar que el origen de datos está utilizando la seguridad de base de datos de nivel de fila.
Si está utilizando la seguridad de base de datos de nivel de fila con el almacenamiento en caché compartido, debe seleccionar esta opción para evitar que se compartan entradas de caché cuyas variables sensibles a la seguridad no coincidan.
Objeto de variable de sesión. Para las variables relacionadas con la seguridad, en el cuadro de diálogo Variable de sesión, seleccione Sensible a seguridad para identificarlas como sensibles a la seguridad al utilizar una estrategia de seguridad de base de datos de nivel de fila. Esta opción garantiza que las entradas de caché se marquen con las variables sensibles a la seguridad, lo que permite la coincidencia de variables sensibles a la seguridad en todas las consultas entrantes.
Para maximizar los aciertos de caché potenciales, una estrategia consiste en ejecutar una serie de consultas para rellenar la caché.
A continuación se ofrecen algunas recomendaciones sobre los tipos de consultas que se deben usar al crear una serie de consultas con las que iniciar la caché.
Consultas predefinidas comunes. Las consultas que se ejecutan normalmente, concretamente las que son más costosas de procesar, son excelentes consultas de inicio de la caché. Las consultas cuyos resultados están embebidos en paneles de control son buenos ejemplos de consultas comunes.
Listas SELECT sin expresiones. La eliminación de expresiones en las columnas de listas SELECT aumentan la posibilidad de que se produzcan aciertos de caché. Una columna almacenada en caché con una expresión solo puede responder a una nueva consulta con la misma expresión; una columna almacenada en caché sin expresiones puede responder a una solicitud para esa columna con cualquier expresión. Por ejemplo, una solicitud almacenada en caché, como:
SELECT QUANTITY, REVENUE...
puede responder a una nueva consulta, como:
SELECT QUANTITY/REVENUE...
pero no al contrario.
Ninguna cláusula WHERE. Si no hay ninguna cláusula WHERE en un resultado almacenado en caché, este se puede utilizar para responder a consultas que cumplan las reglas de aciertos de caché para la lista seleccionada con cualquier cláusula WHERE que incluya columnas en la lista de proyecciones.
En general, las mejores consultas con las que iniciar la caché son aquellas que consumen muchos recursos de procesamiento de base de datos y que es probable que se vuelvan a emitir. Tenga cuidado de no iniciar la caché con consultas simples que devuelven muchas filas. Estas consultas (por ejemplo, SELECT * FROM PRODUCTS, donde PRODUCTS se asigna directamente a una única tabla de base de datos) requieren un procesamiento de base de datos muy reducido. Su costo es una sobrecarga de red y de disco, y estos factores no se reducen con el almacenamiento en caché.
Cuando Oracle Analytics Cloud refresca las variables del modelo semántico, examina los modelos de negocio para determinar si hacen referencia a esas variables de modelo semántico. En caso afirmativo, Oracle Analytics Cloud depura toda la caché para estos modelos de negocio. Consulte Cómo afectan los cambios en el modelo semántico a la caché de consulta.
Puede configurar agentes para iniciar la caché de consulta de Oracle Analytics Cloud.
El inicio de la caché puede mejorar los tiempos de respuesta para los usuarios cuando ejecutan o visualizan análisis embebidos en sus paneles de control. Puede realizarlo mediante la programación de agentes para que ejecuten solicitudes que refresquen estos datos.
La única diferencia entre los agentes de inicio de caché y otros agentes es que borran la caché anterior automáticamente y no aparecen en el panel de control como alertas.
Nota:
Los agentes de inicio de caché solo depuran las consultas de coincidencia exacta, por lo que los datos desactualizados podrían seguir existiendo. Asegúrese de que la estrategia de almacenamiento en caché siempre incluya la depuración de la caché, ya que las consultas de agente no abordan las consultas ad hoc ni los cambios de nivel.La depuración de la caché suprime las entradas de la caché de consulta y mantiene el contenido refrescado. Puede depurar automáticamente las entradas de caché de tablas específicas definiendo el campo Tiempo de persistencia de caché para cada tabla en la herramienta de administración de modelos.
Nota:
Si utiliza el modelador semántico, consulte ¿Cuáles son las propiedades generales de la tabla física?
Resulta útil para orígenes de datos que se actualizan con frecuencia. Por ejemplo, si tiene una tabla que almacena datos de cotizaciones bursátiles que se actualizan cada minuto, puede utilizar el valor Tiempo de persistencia de caché para depurar las entradas de esa tabla cada 59 segundos. Consulte Caché y tiempo de persistencia de caché para tablas físicas especificadas.