Mise en cache des requêtes

Looker réduit la charge pesant sur votre base de données et améliore les performances en utilisant les résultats mis en cache des requêtes SQL précédentes, lorsqu'ils sont disponibles et lorsque cette fonction est autorisée par votre règle de mise en cache. Cette page décrit la règle de mise en cache par défaut de Looker et les options disponibles pour modifier la durée de mise en cache des résultats sur votre instance Looker.

Comment Looker utilise les requêtes mises en cache

Pour les requêtes SQL, le mécanisme de mise en cache de Looker fonctionne comme suit:

  1. Lorsqu'une requête SQL est exécutée à partir d'une exploration, d'une présentation ou d'un tableau de bord, Looker vérifie le cache pour voir si des résultats sont déjà mis en cache pour cette requête. Les résultats mis en cache ne sont utilisés que si tous les aspects de la requête sont identiques, y compris les champs, les filtres, les paramètres et le nombre maximal de lignes.

  2. Si des résultats mis en cache sont trouvés, Looker vérifie la règle de mise en cache définie dans le modèle LookML pour déterminer si ces résultats ont expiré. Si les résultats mis en cache n'ont pas expiré, Looker les utilise pour la requête.

  3. Si aucun résultat mis en cache n'est trouvé pour la requête, ou si les résultats mis en cache ont expiré, Looker exécute la requête sur la base de données. Les résultats de la nouvelle requête sont ensuite mis en cache.

La règle de conservation par défaut du cache est définie sur une heure. La section suivante, Modifier les règles de conservation du cache, explique comment raccourcir ou allonger ce délai, et décrit les options permettant de synchroniser la règle de conservation du cache avec le processus ETL (extraction, transformation et chargement) de votre base de données.

Modifier les règles de conservation du cache

Vous pouvez spécifier des règles de conservation du cache au niveau de l'exploration LookML et du modèle LookML.

Le mécanisme de mise en cache recommandé consiste à utiliser un paramètre datagroup au niveau du modèle. Les groupes de données vous permettent de synchroniser la règle de conservation du cache d'un modèle avec la planification ETL de votre base de données en utilisant le paramètre sql_trigger et en définissant un intervalle d'expiration du cache avec le paramètre max_cache_age. Pour en savoir plus, consultez la section Mettre en cache des requêtes et régénérer des tables PDT à l'aide de groupes de données.

Pour une approche plus simple, vous pouvez utiliser le paramètre persist_for au niveau du modèle ou au niveau de l'exploration. Utiliser le paramètre persist_for de cette manière vous permet de définir un intervalle d'expiration du cache qui remplace l'intervalle par défaut d'une heure. Cependant, l'utilisation de persist_for est moins robuste que l'utilisation de groupes de données pour plusieurs raisons, comme indiqué dans la section Mettre en cache des requêtes avec persist_for.

Si un groupe de données ou une persist_for est défini pour une exploration ou un modèle, la règle de mise en cache est modifiée comme suit:

  • Avant l'intervalle persist_for ou l'intervalle max_cache_age du groupe de données: si la requête est réexécutée, Looker extrait les données du cache.
  • Au moment où l'intervalle de persist_for ou l'intervalle max_cache_age du groupe de données expire: Looker supprime les données du cache.
  • Après l'expiration de l'intervalle persist_for ou de l'intervalle max_cache_age du groupe de données: si la requête est réexécutée, Looker extrait directement les données de la base de données et réinitialise l'intervalle persist_for ou max_cache_age.

Il est essentiel de noter que les données sont supprimées du cache à l'expiration de l'intervalle persist_for ou max_cache_age.

Si le cache atteint la limite de stockage, les données sont éjectées en fonction d'un algorithme LRU (les moins utilisés récemment), sans garantie que les données dont les intervalles persist_for ou max_cache_age ont expiré seront toutes supprimées en une seule fois.

Réduction du temps de mise en cache des données

Looker écrira toujours les résultats de requête dans la mise en cache. Même si les intervalles persist_for et max_cache_age sont définis sur zéro, les données mises en cache peuvent toujours être stockées pendant 10 minutes au maximum. Toutes les données client stockées dans le cache disque sont chiffrées à l'aide de la norme AES (Advanced Encryption Standard).

Pour réduire la durée de stockage des données dans le cache:

  • Définissez la valeur sur 0 minutes pour tout paramètre persist_for (pour un modèle ou une exploration) ou pour un paramètre max_cache_age (pour un groupe de données). Looker supprime le cache à l'expiration de l'intervalle persist_for ou lorsque les données atteignent l'intervalle max_cache_age spécifié dans son groupe de données. (Il n'est pas nécessaire de définir le paramètre persist_for des PDT sur 0 minutes afin de réduire la quantité de données stockées dans le cache. Les PDT sont écrites dans la base de données elle-même, et non dans le cache.)
  • Définissez le paramètre suggest_persist_for sur un petit intervalle. La valeur suggest_persist_for indique la durée pendant laquelle Looker doit conserver les suggestions de filtrage dans le cache. Les suggestions de filtrage sont basées sur une requête portant sur les valeurs du champ filtré. Ces résultats de requête sont conservés dans le cache afin que Looker puisse rapidement fournir des suggestions à mesure que l'utilisateur saisit du texte dans le champ de texte du filtre. Par défaut, les suggestions de filtrage sont mises en cache pendant six heures. Pour réduire la durée de conservation des données dans le cache, définissez une valeur inférieure pour suggest_persist_for, par exemple 5 minutes.

Vérifier si une requête a été renvoyée à partir du cache

Dans une fenêtre Explore (Explorer), vous pouvez déterminer si une requête a été renvoyée du cache en regardant en haut à droite après avoir exécuté une requête.

Lorsqu'une requête est renvoyée par le cache, la mention "depuis le cache" s'affiche. Sinon, le temps nécessaire pour renvoyer la requête s'affiche.

Forcer la génération de nouveaux résultats à partir de la base de données

Dans une fenêtre Explorer, vous pouvez forcer la récupération de nouveaux résultats dans la base de données. Après avoir exécuté une requête (y compris des requêtes de résultats fusionnés), sélectionnez l'option Effacer le cache et actualiser dans le menu en forme de roue dentée Actions d'exploration situé en haut à droite de l'écran.

Mise en cache des requêtes et recompilation des PDT avec des groupes de données

Utilisez des groupes de données pour coordonner la planification ETL (extraction, transformation et chargement) de votre base de données avec la règle de mise en cache de Looker et le calendrier de régénération des PDT.

Vous pouvez utiliser un groupe de données pour spécifier le déclencheur de recompilation des PDT en fonction du moment où de nouvelles données sont ajoutées à votre base de données. Vous pouvez ensuite appliquer le même groupe de données à votre exploration ou votre modèle afin que les résultats mis en cache expirent également lorsque vos tables PDT se recompilent.

Vous pouvez également utiliser un groupe de données pour dissocier le déclencheur de recompilation de la PDT de l'ancienneté maximale du cache. Cela peut être utile si vous disposez d'une exploration basée à la fois sur des données très fréquemment mises à jour et jointe à une PDT qui est recréée moins fréquemment. Dans ce cas, vous souhaiterez peut-être que le cache de vos requêtes se réinitialise plus souvent que votre PDT est régénérée.

Définir un groupe de données

Définissez un groupe de données avec le paramètre datagroup dans un fichier de modèle ou dans son propre fichier LookML. Vous pouvez définir plusieurs groupes de données si vous souhaitez appliquer différentes règles de mise en cache et de régénération des PDT en fonction des explorations et/ou des tables dérivées persistantes de votre projet.

Le paramètre datagroup peut comporter les sous-paramètres suivants:

  • label : spécifie un libellé facultatif pour le groupe de données.
  • description : spécifie une description facultative du groupe de données qui peut être utilisée pour expliquer son objectif et son mécanisme.
  • max_cache_age : spécifie une chaîne qui définit une période. Lorsque l'âge du cache d'une requête dépasse la période, Looker invalide le cache. Lors de la prochaine émission de la requête, Looker l'envoie à la base de données pour obtenir de nouveaux résultats.
  • sql_trigger : spécifie une requête SQL qui renvoie une ligne avec une colonne. Si la valeur renvoyée par la requête est différente des résultats précédents, le groupe de données se déclenche.
  • interval_trigger : spécifie un calendrier de déclenchement du groupe de données, par exemple "24 hours".

Pour en savoir plus sur ces paramètres, consultez la page de documentation concernant les groupes de données.

Un groupe de données doit comporter au minimum les paramètres max_cache_age, sql_trigger ou interval_trigger.

Voici un exemple de groupe de données avec une sql_trigger configurée pour recréer la PDT tous les jours. De plus, le max_cache_age est configuré pour vider le cache des requêtes toutes les deux heures, au cas où des explorations associent des PDT à d'autres données actualisées plus d'une fois par jour.

datagroup: customers_datagroup {
  sql_trigger: SELECT DATE(NOW());;
  max_cache_age: "2 hours"
}

Une fois le groupe de données défini, vous pouvez l'attribuer aux explorations et aux PDT:

Utiliser un groupe de données pour spécifier un déclencheur de régénération pour les PDT

Pour définir un déclencheur de recompilation de PDT à l'aide de groupes de données, créez un paramètre datagroup avec le sous-paramètre sql_trigger ou interval_trigger. Attribuez ensuite le groupe de données à chaque PDT à l'aide du sous-paramètre datagroup_trigger dans la définition derived_table de la PDT. Si vous utilisez datagroup_trigger pour votre table PDT, vous n'avez pas besoin de spécifier une autre stratégie de persistance pour la table dérivée. Si vous spécifiez plusieurs stratégies de persistance pour une PDT, un avertissement s'affiche dans l'IDE Looker, et seul le datagroup_trigger sera utilisé.

Voici un exemple de définition de PDT qui utilise le groupe de données customers_datagroup. Cette définition ajoute également plusieurs index, à la fois sur customer_id et first_order_date. Pour en savoir plus sur la définition de PDT, consultez la page de documentation Tables dérivées dans Looker.

view: customer_order_facts {
  derived_table: {
    sql: ... ;;
    datagroup_trigger: customers_datagroup
    indexes: ["customer_id", "first_order_date"]
  }
}

Si vous disposez de PDT en cascade ou de tables PDT dépendant d'autres tables PDT, veillez à ne pas spécifier de règles de mise en cache des groupes de données incompatibles.

Pour les connexions disposant d'attributs utilisateur permettant de spécifier les paramètres de connexion, vous devez créer une connexion distincte à l'aide des champs de remplacement du PDT si vous souhaitez effectuer l'une des opérations suivantes:

  • Utiliser des PDT dans votre modèle
  • Utiliser un groupe de données pour définir un déclencheur de régénération des PDT

Sans les remplacements de PDT, vous pouvez toujours utiliser un groupe de données avec max_cache_age pour définir la règle de mise en cache des explorations.

Consultez la page de documentation Tables dérivées dans Looker pour en savoir plus sur le fonctionnement des groupes de données avec les tables PDT.

Utiliser un groupe de données pour spécifier la réinitialisation du cache des requêtes pour les explorations

Lorsqu'un groupe de données est déclenché, le régénérateur Looker régénère les tables PDT qui utilisent ce groupe de données comme stratégie de persistance. Une fois que les PDT du groupe de données sont régénérées, Looker vide le cache des explorations qui utilisent les PDT régénérées du groupe de données. Vous pouvez ajouter le paramètre max_cache_age à la définition de votre groupe de données si vous souhaitez personnaliser un calendrier de réinitialisation du cache de requêtes pour le groupe. Le paramètre max_cache_age vous permet de vider le cache de requêtes selon un calendrier spécifié, en plus de la réinitialisation automatique du cache de requêtes que Looker effectue lorsque les PDT du groupe de données sont régénérées.

Pour définir une règle de mise en cache des requêtes avec des groupes de données, créez un paramètre datagroup avec le sous-paramètre max_cache_age.

Pour spécifier un groupe de données à utiliser pour les réinitialisations du cache des requêtes lors des explorations, utilisez le paramètre persist_with:

Les exemples suivants illustrent un groupe de données nommé orders_datagroup qui est défini dans un fichier de modèle. Le groupe de données comporte un paramètre sql_trigger, qui spécifie que la requête select max(id) from my_tablename sera utilisée pour détecter un ETL. Même si cet ETL n'a pas lieu pendant un certain temps, le max_cache_age du groupe de données spécifie que les données mises en cache ne seront utilisées que pendant 24 heures au maximum.

Le paramètre persist_with du modèle pointe vers la règle de mise en cache orders_datagroup, ce qui signifie qu'il s'agit de la règle de mise en cache par défaut pour toutes les explorations du modèle. Cependant, nous ne voulons pas utiliser la règle de mise en cache par défaut du modèle pour les explorations customer_facts et customer_background. Nous pouvons donc ajouter le paramètre persist_with afin de spécifier une règle de mise en cache différente pour ces deux explorations. Les explorations orders et orders_facts n'ont pas de paramètre persist_with. Elles utiliseront donc la règle de mise en cache par défaut du modèle: 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 persist_with et persist_for sont tous les deux spécifiés, vous recevrez un avertissement de validation et l'persist_with sera utilisé.

Déclencher des envois planifiés à l'aide d'un groupe de données

Les groupes de données peuvent également servir à déclencher l'envoi d'un tableau de bord ou d'une présentation. Avec cette option, Looker envoie vos données lorsque le groupe de données est terminé, afin que le contenu planifié soit à jour.

Utiliser le panneau d'administration pour les groupes de données

Si vous disposez du rôle d'administrateur Looker, vous pouvez utiliser la page Groupes de données du panneau Administration pour afficher les groupes de données existants. Vous pouvez voir la connexion, le modèle et l'état actuel de chaque groupe de données et, si spécifié dans le code LookML, un libellé et une description pour chaque groupe de données. Vous pouvez également réinitialiser le cache d'un groupe de données, le déclencher ou accéder au code LookML du groupe de données.

Mettre en cache les requêtes avec persist_for

Utilisez le paramètre persist_for au niveau du modèle ou au niveau de l'exploration pour modifier l'intervalle de conservation du cache par défaut de Looker (1 heure). Vous pouvez définir des intervalles jusqu'à 0 minutes et des intervalles jusqu'à 8760 hours (un an) ou plus.

Définir des paramètres persist_for peut être plus rapide et plus simple, mais moins robuste, que de définir des groupes de données. Il est recommandé d'utiliser des groupes de données plutôt que persist_for pour les raisons suivantes:

  • Les groupes de données peuvent être synchronisés avec le processus ETL de votre base de données.
  • Vous pouvez réutiliser des groupes de données dans plusieurs modèles et explorations. Cela signifie que vous pouvez mettre à jour l'élément max_cache_age d'un groupe de données, ce qui met à jour la règle de mise en cache partout où le groupe de données est utilisé.
  • Vous pouvez vider le cache associé à un groupe de données à partir de la page Groupes de données.