Looker reduce la carga de tu base de datos y mejora el rendimiento usando los resultados almacenados en caché de consultas SQL anteriores cuando están disponibles y cuando tu política de almacenamiento en caché permite usar esta función. En esta página se describe la política de almacenamiento en caché predeterminada de Looker, así como las opciones disponibles para modificar la duración de los resultados almacenados en caché en su instancia de Looker.
Cómo usa Looker las consultas almacenadas en caché
En el caso de las consultas de SQL, el mecanismo de almacenamiento en caché de Looker funciona de la siguiente manera:
Cuando se ejecuta una consulta de SQL desde una exploración, un look o un panel de control, Looker comprueba la caché para ver si ya hay resultados almacenados en caché para esa consulta. Los resultados almacenados en caché solo se usarán si todos los aspectos de la consulta son los mismos, incluidos los campos, los filtros, los parámetros y los límites de filas.
Si se encuentran resultados almacenados en caché, Looker comprueba la política de almacenamiento en caché definida en el modelo de LookML para determinar si los resultados almacenados en caché han caducado. Si los resultados almacenados en caché no han caducado, Looker los usa para la consulta.
Si no se encuentran resultados almacenados en caché para la consulta o si han caducado, Looker ejecutará la consulta en la base de datos. Los nuevos resultados de la consulta se almacenarán en caché.
La política de conservación de la caché predeterminada es de una hora. En la siguiente sección, Modificar las políticas de retención de caché, se explica cómo acortar o alargar este periodo, así como las opciones para sincronizar la política de retención de caché con el proceso de ETL (extracción, transformación y carga) de la base de datos.
Modificar las políticas de retención de caché
Puede especificar políticas de conservación de la caché a nivel de Explore de LookML y a nivel de modelo de LookML.
El mecanismo de almacenamiento en caché recomendado es usar un parámetro datagroup
a nivel de modelo. Los grupos de datos te permiten sincronizar la política de conservación de la caché de un modelo con la programación de ETL de tu base de datos mediante el parámetro sql_trigger
y definiendo un intervalo de vencimiento de la caché con el parámetro max_cache_age
. Para obtener más información, consulta la sección Almacenar en caché consultas y volver a compilar PDTs con grupos de datos.
Para simplificar el proceso, puede usar el parámetro persist_for
en el nivel de modelo o en el nivel de Exploración. Si usas el parámetro persist_for
de esta forma, puedes definir un intervalo de caducidad de la caché que anule el intervalo predeterminado de una hora. Sin embargo, usar persist_for
es menos eficaz que usar grupos de datos por varios motivos, como se explica en la sección Almacenar en caché consultas con persist_for.
Si una exploración o un modelo tienen un grupo de datos o un persist_for
definidos, la política de almacenamiento en caché se modifica de la siguiente manera:
- Antes de que caduque el intervalo
persist_for
o el intervalomax_cache_age
del grupo de datos: si se vuelve a ejecutar la consulta, Looker extraerá los datos de la caché. - Cuando vence el intervalo
persist_for
o el intervalomax_cache_age
del grupo de datos, Looker elimina los datos de la caché. - Después de que caduque el intervalo
persist_for
o el intervalomax_cache_age
del grupo de datos: si se vuelve a ejecutar la consulta, Looker extrae los datos directamente de la base de datos y restablece el intervalopersist_for
omax_cache_age
.
Un punto clave es que los datos se eliminan de la caché cuando vence el intervalo persist_for
o max_cache_age
.
Si la caché alcanza el límite de almacenamiento, los datos se expulsan según un algoritmo de menos usados recientemente (LRU), sin garantía de que los datos con intervalos persist_for
o max_cache_age
caducados se eliminen todos a la vez.
Minimizar el tiempo que tus datos permanecen en la caché
Looker siempre escribirá los resultados de las consultas en la caché. Aunque los intervalos persist_for
y max_cache_age
se hayan definido en cero, los datos almacenados en caché se pueden seguir almacenando durante un máximo de 10 minutos. Todos los datos de clientes que se almacenan en la caché de disco están cifrados con el estándar de cifrado avanzado (AES).
Para minimizar el tiempo que se almacenan los datos en la caché, sigue estos pasos:
- En cualquier parámetro
persist_for
(de un modelo o una exploración) omax_cache_age
(de un grupo de datos), asigna el valor0 minutes
. Looker elimina la caché cuando vence el intervalopersist_for
o cuando los datos alcanzan el intervalomax_cache_age
especificado en su grupo de datos. No es necesario definir el parámetropersist_for
de las tablas derivadas persistentes (PDTs) en0 minutes
para minimizar la cantidad de datos que se almacenan en la caché. Las PDTs se escriben en la propia base de datos, no en la caché. - Asigna al parámetro
suggest_persist_for
un intervalo pequeño. El valorsuggest_persist_for
especifica durante cuánto tiempo debe mantener Looker las sugerencias de filtros en la caché. Las sugerencias de filtros se basan en una consulta de los valores del campo que se está filtrando. Estos resultados de consulta se almacenan en la caché para que Looker pueda proporcionar sugerencias rápidamente mientras el usuario escribe en el campo de texto del filtro. De forma predeterminada, las sugerencias de filtros se almacenan en caché durante 6 horas. Para minimizar el tiempo que permanecen los datos en la caché, asigne al valorsuggest_persist_for
un valor inferior, como5 minutes
.
Comprobar si una consulta se ha devuelto desde la caché
En una ventana Explorar, puedes determinar si una consulta se ha devuelto desde la caché consultando la información situada junto al botón Ejecutar después de ejecutar una consulta.
Cuando se devuelve una consulta de la caché, se muestra el texto "de la caché". De lo contrario, se muestra el tiempo que se ha tardado en devolver la consulta.
Forzar la generación de nuevos resultados a partir de la base de datos
En una ventana Explorar, puedes forzar que se obtengan nuevos resultados de la base de datos. Después de ejecutar una consulta (incluidas las consultas de resultados combinados), selecciona la opción Borrar caché y actualizar en el menú de la rueda dentada Explorar acciones.
Almacenar en caché las consultas y volver a crear tablas derivadas persistentes (PDTs) con grupos de datos
Usa grupos de datos para coordinar la programación de ETL (extracción, transformación y carga) de tu base de datos con la política de almacenamiento en caché y la programación de recompilación de tablas derivadas persistentes (PDTs) de Looker.
Puedes usar un grupo de datos para especificar el activador de recompilación de los PDTs en función de cuándo se añadan nuevos datos a tu base de datos. Después, puedes aplicar el mismo grupo de datos a tu exploración o modelo para que los resultados almacenados en caché también caduquen cuando se recompilen tus PDTs.
También puede usar un grupo de datos para desacoplar el activador de la recompilación del PDT de la antigüedad máxima de la caché. Esto puede ser útil si tienes una exploración basada en datos que se actualizan con mucha frecuencia y que está unida a una PDT que se recompila con menos frecuencia. En este caso, puede que quieras que la caché de consultas se restablezca con más frecuencia que la que se tarda en volver a compilar el PDT.
Definir un grupo de datos
Define un grupo de datos con el parámetro datagroup
, ya sea en un archivo de modelo o en su propio archivo LookML. Puedes definir varios grupos de datos si quieres que diferentes Exploraciones o PDTs de tu proyecto tengan políticas de almacenamiento en caché y de recompilación de PDTs persistentes distintas.
El parámetro datagroup
puede tener los siguientes subparámetros:
label
: especifica una etiqueta opcional para el grupo de datos.description
: especifica una descripción opcional del grupo de datos que se puede usar para explicar su finalidad y su mecanismo.max_cache_age
: especifica una cadena que define un periodo. Cuando la antigüedad de la caché de una consulta supera el periodo, Looker invalida la caché. La próxima vez que se realice la consulta, Looker la enviará a la base de datos para obtener resultados actualizados.sql_trigger
: especifica una consulta SQL que devuelve una fila con una columna. Si el valor que devuelve la consulta es diferente de los resultados anteriores de la consulta, el grupo de datos pasa a un estado activado.interval_trigger
: especifica una programación para activar el grupo de datos, como"24 hours"
.
Como mínimo, un grupo de datos debe tener el parámetro max_cache_age
, el parámetro sql_trigger
o el parámetro interval_trigger
.
A continuación, se muestra un ejemplo de un grupo de datos que tiene configurado un sql_trigger
para reconstruir el PDT todos los días. Además, la max_cache_age
se ha configurado para borrar la caché de consultas cada dos horas, por si alguna exploración combina PDTs con otros datos que se actualizan con más frecuencia que una vez al día.
datagroup: customers_datagroup {
sql_trigger: SELECT DATE(NOW());;
max_cache_age: "2 hours"
}
Una vez que hayas definido el grupo de datos, podrás asignarlo a Exploraciones y PDTs:
- Para asignar el grupo de datos a una PDT, usa el parámetro
datagroup_trigger
en el parámetroderived_table
. Consulta un ejemplo en la sección Usar un grupo de datos para especificar un activador de recompilación de PDTs de esta página. - Para asignar el grupo de datos a una Exploración, usa el parámetro
persist_with
en el nivel de modelo o en el nivel de Exploración. Consulta un ejemplo en la sección Usar un grupo de datos para especificar el restablecimiento de la caché de consultas de Exploraciones de esta página.
Usar un grupo de datos para especificar un activador de recompilación de PDTs
Para definir un activador de recompilación de PDT mediante grupos de datos, crea un parámetro datagroup
con el subparámetro sql_trigger
o interval_trigger
. A continuación, asigna el grupo de datos a PDTs concretos mediante el subparámetro datagroup_trigger
en la definición derived_table
del PDT. Si usas datagroup_trigger
para tu PDT, no tienes que especificar ninguna otra estrategia de persistencia para la tabla derivada. Si especifica varias estrategias de persistencia para un PDT, recibirá una advertencia en el IDE de Looker y solo se utilizará la datagroup_trigger
.
A continuación, se muestra un ejemplo de definición de PDT que usa el grupo de datos customers_datagroup
. Esta definición también añade varios índices, tanto en customer_id
como en first_order_date
. Para obtener más información sobre cómo definir PDTs, consulta la página de documentación Tablas derivadas en Looker.
view: customer_order_facts {
derived_table: {
sql: ... ;;
datagroup_trigger: customers_datagroup
indexes: ["customer_id", "first_order_date"]
}
}
Consulta la página de documentación Tablas derivadas en Looker para obtener más información sobre cómo funcionan los grupos de datos con las PDTs.
Usar un grupo de datos para especificar el restablecimiento de la caché de consultas de Exploraciones
Cuando se activa un grupo de datos, el regenerador de Looker vuelve a compilar los PDTs que usan ese grupo de datos como estrategia de persistencia. Una vez que se hayan recompilado las PDTs del grupo de datos, Looker borrará la caché de los Exploraciones que usen las PDTs recompiladas del grupo de datos. Puede añadir el parámetro max_cache_age
a la definición de su grupo de datos si quiere personalizar una programación de restablecimiento de la caché de consultas para el grupo de datos. El parámetro max_cache_age
le permite borrar la caché de consultas según una programación específica, además del restablecimiento automático de la caché de consultas que realiza Looker cuando se vuelven a compilar las PDTs del grupo de datos.
Para definir una política de almacenamiento en caché de consultas con grupos de datos, cree un parámetro datagroup
con el subparámetro max_cache_age
.
Para especificar un grupo de datos que se va a usar para restablecer la caché de consultas en Exploraciones, usa el parámetro persist_with
:
- Para asignar el grupo de datos como predeterminado a todas las Exploraciones de un modelo, usa el parámetro
persist_with
a nivel de modelo (en un archivo de modelo). - Para asignar el grupo de datos a Exploraciones concretas, use el parámetro
persist_with
en un parámetroexplore
.
En el siguiente ejemplo se muestra un grupo de datos llamado orders_datagroup
que se define en un archivo de modelo. El grupo de datos tiene un parámetro sql_trigger
, que especifica que la consulta select max(id) from my_tablename
se usará para detectar cuándo se ha producido una ETL. Aunque ese proceso de extracción, transformación y carga no se produzca durante un tiempo, el max_cache_age
del grupo de datos especifica que los datos almacenados en caché solo se usarán durante un máximo de 24 horas.
El parámetro persist_with
del modelo apunta a la política de almacenamiento en caché orders_datagroup
, lo que significa que esta será la política de almacenamiento en caché predeterminada de todos los Exploraciones del modelo. Sin embargo, no queremos usar la política de almacenamiento en caché predeterminada del modelo para los Exploraciones customer_facts
y customer_background
, por lo que podemos añadir el parámetro persist_with
para especificar otra política de almacenamiento en caché para estos dos Exploraciones. Las exploraciones orders
y orders_facts
no tienen el parámetro persist_with
, por lo que usarán la política de almacenamiento en caché predeterminada del modelo: orders_datagroup
.
datagroup: orders_datagroup {
sql_trigger: SELECT max(id) FROM my_tablename ;;
max_cache_age: "24 hours"
}
datagroup: customers_datagroup {
sql_trigger: SELECT max(id) FROM my_other_tablename ;;
}
persist_with: orders_datagroup
explore: orders { ... }
explore: order_facts { ... }
explore: customer_facts {
persist_with: customers_datagroup
...
}
explore: customer_background {
persist_with: customers_datagroup
...
}
Si se especifican persist_with
y persist_for
, recibirá una advertencia de validación y se usará persist_with
.
Usar un grupo de datos para activar envíos programados
Los grupos de datos también se pueden usar para activar el envío de un panel de control o un Look. Con esta opción, Looker enviará sus datos cuando se complete el grupo de datos, de modo que el contenido programado esté actualizado.
Usar el panel Administrar para los grupos de datos
Si tiene el rol de administrador de Looker, puede usar la página Grupos de datos del panel Administrar para ver los grupos de datos que ya tiene. Puedes ver la conexión, el modelo y el estado actual de cada grupo de datos y, si se ha especificado en el LookML, una etiqueta y una descripción de cada grupo de datos. También puedes restablecer la caché de un grupo de datos, activarlo o ir al LookML del grupo de datos.
Almacenar en caché consultas con persist_for
Use el parámetro persist_for
en el nivel de modelo o en el nivel de Exploración para modificar el intervalo de conservación predeterminado de la caché de Looker, que es de 1 hora. Puedes definir intervalos de 0 minutes
y de 8760 hours
(1 año) o más.
Definir parámetros persist_for
puede ser más rápido y sencillo, pero menos sólido, que definir grupos de datos. Se recomienda usar grupos de datos en lugar de persist_for
por los siguientes motivos:
- Los grupos de datos se pueden sincronizar con el proceso de ETL de tu base de datos.
- Puede reutilizar los grupos de datos en varios modelos y Exploraciones. Esto significa que puedes actualizar el
max_cache_age
de un grupo de datos y se actualizará la política de almacenamiento en caché en cada lugar donde se use el grupo de datos. - Puedes borrar toda la caché asociada a un grupo de datos desde la página Grupos de datos.