Partager via

Stratégie de cache (cache à chaud et à froid)

  • Article

Azure Data Explorer utilise un système de cache de données multiniveau pour garantir des performances de requête rapides. Les données sont stockées dans un stockage fiable, tel que Stockage Blob Azure, mais certaines parties sont mises en cache sur les nœuds de traitement, SSD ou même dans la RAM pour un accès plus rapide.

Real-Time Intelligence utilise un système de cache de données multiniveau pour garantir des performances de requête rapides. Les données sont stockées dans un stockage fiable, tel que OneLake, mais certaines parties sont mises en cache sur les nœuds de traitement, SSD ou même dans la RAM pour un accès plus rapide.

La stratégie de mise en cache vous permet de choisir les données à mettre en cache. Vous pouvez différencier le cache de données chaud et le cache de données froid en définissant une stratégie de mise en cache sur les données chaudes. Les données à chaud sont conservées dans le stockage SSD local pour accélérer les performances des requêtes, tandis que les données à froid sont stockées dans un stockage fiable, ce qui est moins cher mais plus lent à accéder.

Le cache utilise 95 % du disque SSD local pour les données chaudes. S’il n’y a pas suffisamment d’espace, les données les plus récentes sont conservées de préférence dans le cache. Les 5 % restants sont utilisés pour les données qui ne sont pas classées comme chaudes. Cette conception garantit que les requêtes qui chargent un grand nombre de données froides ne suppriment pas les données chaudes du cache.

Les meilleures performances de requête sont obtenues lorsque toutes les données ingérées sont mises en cache. Toutefois, certaines données peuvent ne pas justifier les frais d’être conservés dans le cache chaud. Par exemple, les anciens enregistrements de journal rarement consultés peuvent être considérés comme moins essentiels. Dans ce cas, les équipes choisissent souvent de réduire les performances d’interrogation sur le paiement pour maintenir les données chaudes.

Utilisez des commandes de gestion pour modifier la stratégie de mise en cache au niveau de la base de données, de la table ou de la vue matérialisée.

Utilisez des commandes de gestion pour modifier la stratégie de mise en cache au niveau du cluster, de la base de données, de la table ou de la vue matérialisée.

Conseil

Votre cluster est conçu pour les requêtes ad hoc avec des jeux de résultats intermédiaires qui correspondent à la RAM totale du cluster. Pour les travaux volumineux, tels que map-reduce, il peut être utile de stocker des résultats intermédiaires dans un stockage persistant. Pour ce faire, créez un travail d’exportation continue. Cette fonctionnalité vous permet d’effectuer des requêtes par lots longues à l’aide de services tels que HDInsight ou Azure Databricks.

Comment la stratégie de mise en cache est appliquée

Lorsque les données sont ingérées, le système effectue le suivi de la date et de l’heure de l’ingestion et de l’étendue créée. La valeur de date et d’heure d’ingestion de l’étendue (ou valeur maximale, si une extension a été générée à partir de plusieurs étendues préexistantes) est utilisée pour évaluer la stratégie de mise en cache.

Remarque

Vous pouvez spécifier une valeur pour la date et l’heure d’ingestion à l’aide de la propriété creationTimed’ingestion. Dans ce cas, assurez-vous que la Lookback propriété de la stratégie de fusion Étendues effective de la table est alignée sur les valeurs que vous définissez pour creationTime.

Par défaut, la stratégie effective est null, ce qui signifie que toutes les données sont considérées comme chaudes. Une null stratégie au niveau de la table signifie que la stratégie sera héritée de la base de données. Une stratégie de niveau table nenull remplace pas une stratégie au niveau de la base de données.

Étendue des requêtes dans le cache à chaud

Lorsque vous exécutez des requêtes, vous pouvez limiter l’étendue aux données de requête uniquement dans le cache chaud.

Remarque

L’étendue des données s’applique uniquement aux entités qui prennent en charge les stratégies de mise en cache, telles que les tables et les vues matérialisées. Elle est ignorée pour d’autres entités, telles que des tables externes et des données dans le magasin de lignes.

Il existe plusieurs possibilités de requête :

  • Ajoutez une propriété de requête cliente appelée query_datascope à la requête. Valeurs possibles : default, all et hotcache.
  • Utilisez une set instruction dans le texte de la requête : set query_datascope='...'. Les valeurs possibles sont identiques à celles de la propriété de requête du client.
  • Ajoutez un datascope=... texte immédiatement après une référence de table dans le corps de la requête. Les valeurs possibles sont all et hotcache.

La default valeur indique l’utilisation des paramètres par défaut du cluster, qui déterminent que la requête doit couvrir toutes les données.

S’il existe une différence entre les différentes méthodes, il set est prioritaire sur la propriété de demande du client. La spécification d’une valeur pour une référence de table est prioritaire sur les deux.

Par exemple, dans la requête suivante, toutes les références de table utilisent uniquement des données de cache à chaud, à l’exception de la deuxième référence à « T », qui est étendue à toutes les données :

set query_datascope="hotcache";
T | union U | join (T datascope=all | where Timestamp < ago(365d)) on X

Stratégie de mise en cache et stratégie de rétention

La stratégie de mise en cache est indépendante de la stratégie de rétention :

  • La stratégie de mise en cache définit comment hiérarchiser les ressources. Les requêtes pour les données importantes sont plus rapides.
  • La stratégie de rétention définit l’étendue des données interrogeables dans une table/une base de données (en particulier). SoftDeletePeriod

Configurez cette stratégie pour obtenir un équilibre optimal entre les coûts et les performances, en fonction du modèle de requête attendu.

Exemple :

  • SoftDeletePeriod = 56d
  • hot cache policy = 28d

Dans l’exemple, les 28 derniers jours de données se trouveront sur le disque SSD du cluster et les 28 jours supplémentaires de données seront stockés dans le stockage Blob Azure. Vous pouvez exécuter des requêtes sur les 56 jours complets de données.

Contenu connexe