Stratégie de mise en cache (cache chaud et froid)

  • Article

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

Real-Time Analytics utilise un système de cache de données à plusieurs niveaux 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 des 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 faire la différence entre le cache de données chaudes et le cache de données froides en définissant une stratégie de mise en cache sur les données chaudes. Les données chaudes sont conservées dans le stockage SSD local pour des performances de requête plus rapides, tandis que les données froides sont stockées dans un stockage fiable, qui est moins cher, mais plus lent à l’accès.

Le cache utilise 95 % du disque SSD local pour les données à chaud. 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 étant 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 le coût d’être conservées dans le cache à chaud. Par instance, les anciens enregistrements de journal rarement consultés peuvent être considérés comme moins importants. Dans ce cas, les équipes optent souvent pour des performances d’interrogation inférieures plutôt que de payer pour garder les données au chaud.

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 s’intègrent dans la RAM totale du cluster. Pour les travaux volumineux, comme map-reduce, il peut être utile de stocker les 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 de longue durée à 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, ainsi que de l’étendue qui a été créée. La valeur de date et d’heure d’ingestion de l’étendue (ou la valeur maximale, si une étendue a été créée à partir de plusieurs étendues préexistantes) est utilisée pour évaluer la stratégie de mise en cache.

Notes

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é dans 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 au niveau de la table remplacenull 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 à interroger uniquement les données dans le cache à chaud.

Notes

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 les tables externes et les 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 les mêmes que pour la propriété de requête cliente.
  • 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, elle set est prioritaire sur la propriété de requête 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 limitée à 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/base de données (en particulier, SoftDeletePeriod).

Configurez cette stratégie pour obtenir l’équilibre optimal entre le coût 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 trouvent sur le disque SSD du cluster et les 28 jours supplémentaires de données sont stockés dans le stockage blob Azure. Vous pouvez exécuter des requêtes sur les 56 jours complets de données.

Contenu connexe