Elasticsearch:Préchauffage du cache des tranches

Le préchauffage est une optimisation des performances facultative. Si vous ne préchauffez pas les données, les requêtes les chargent à la demande. Le préchauffage ne modifie pas les résultats des requêtes et ne garantit pas la durée de résidence des données dans le cache. Après avoir préchauffé un lot de données, interrogez-le directement plutôt que de le préchauffer à nouveau avant chaque requête.

Avant de commencer

• La Collection et la Slice cibles existent. _warm_slice ne crée pas de Slice inexistante.

• Les données que vous souhaitez préchauffer sont déjà consultables. Le préchauffage ne déclenche pas d'actualisation. Attendez que l'actualisation automatique en arrière-plan rende les données consultables avant de les préchauffer, et n'appelez pas manuellement _refresh pour le préchauffage.

Notes d'utilisation

Les limites et comportements suivants s'appliquent à toutes les demandes de préchauffage :

• Portée de la demande — Chaque demande peut spécifier explicitement une seule Collection et une seule Slice. _all ne peut pas être utilisé dans une demande de préchauffage, bien que les demandes de requête prennent en charge _slice=_all.

• Demandes dupliquées — Les demandes de préchauffage simultanées pour le même réplica de shard de requête et la même Slice sont fusionnées. Inutile de soumettre des demandes dupliquées.

• Portée des données — Le préchauffage traite uniquement les données qui sont déjà consultables au moment où la demande est initiée. Les nouvelles données qui deviennent consultables ultérieurement ne sont pas incluses dans ce résultat de préchauffage.

• Impact sur les ressources — Le préchauffage consomme de la bande passante de lecture du stockage objet et des ressources des nœuds de requête. Dans un environnement de production, utilisez la méthode asynchrone par défaut, préchauffez les Slices avant que votre application ne les interroge et limitez le nombre de Slices préchauffées simultanément.

• File d'attente pleine — Lorsque la file d'attente de préchauffage est pleine, le serveur peut rejeter les nouvelles demandes. Votre client doit utiliser une stratégie de nouvelle tentative avec backoff borné au lieu de réessayer immédiatement toutes les Slices simultanément.

Choisir un mode de préchauffage

Par défaut, _warm_slice soumet une tâche de préchauffage de manière asynchrone. Vous pouvez également attendre le résultat du préchauffage de manière synchrone.

Paramètres de la demande

_warm_slice accepte les paramètres de requête suivants :

Lancer un préchauffage asynchrone

Par défaut, une tâche de préchauffage est soumise de manière asynchrone :

POST /knowledge-chunks/_warm_slice?_slice=tenant-a

La demande renvoie HTTP 200. Le corps de la réponse contient status défini sur ACCEPTED et l'ID de cette tâche de préchauffage :

{
  "status": "ACCEPTED",
  "message": "cache warm hint accepted",
  "task": "<nodeId>:<taskId>"
}

Utilisez l'opération suivante pour interroger une tâche en cours d'exécution :

GET /_tasks/<nodeId>:<taskId>

Par défaut, le résultat de la tâche n'est pas conservé une fois la tâche terminée.

ACCEPTED indique uniquement que la tâche a été soumise. Cela n'indique pas que la Slice cible existe ou que le préchauffage a réussi. Pour confirmer le résultat, définissez store_result=true lors de la soumission de la tâche, puis utilisez l'API Tasks pour vérifier les éléments suivants dans l'ordre :

1. completed=true : La tâche est terminée. Si la valeur est false, attendez un instant, puis interrogez à nouveau la tâche.

2. Le niveau supérieur ne contient pas error : La tâche ne s'est pas terminée par une erreur. Des conditions telles qu'une Slice inexistante ou une branche active qui ne prend pas actuellement en charge le préchauffage peuvent être signalées comme des erreurs uniquement après la soumission de la tâche. Une demande synchrone renvoie HTTP 404 pour une Slice inexistante à la place.

3. response._shards.failed=0 : Aucun shard n'a échoué. Si response._shards.total=0, effectuez des vérifications supplémentaires comme décrit dans Évaluer les résultats synchrones ci-dessous.

Préchauffez uniquement les Slices que votre application interroge réellement. N'énumérez pas toutes les Slices simplement pour le préchauffage.

Attendre la fin du préchauffage

Pour obtenir directement les statistiques de préchauffage, vous pouvez attendre de manière synchrone :

POST /knowledge-chunks/_warm_slice?_slice=tenant-a&wait_for_completion=true&timeout=60s

En mode synchrone, HTTP 404 est renvoyé pour une Slice inexistante. Une fois la demande réussie, vérifiez que _shards.failed=0 au niveau supérieur. Si _shards.total=0, vous ne pouvez pas utiliser ce résultat pour déterminer si les nœuds de requête sont prêts. Si vous vous attendez à ce que des données consultables existent, confirmez d'abord que les shards de requête sont disponibles, vérifiez la visibilité des données avec une requête réelle, puis réessayez le préchauffage si nécessaire. Ne concluez pas à partir de ce seul résultat que le préchauffage a échoué pour une Slice qui ne contient aucune donnée.

La réponse synchrone contient les champs de statistiques suivants :

Une valeur ranges_skipped supérieure à 0 n'indique pas nécessairement que le préchauffage a échoué. Lorsque des fichiers sont fusionnés ou supprimés pendant le préchauffage, les plages correspondantes sont ignorées.

Affinité entre requête et préchauffage

Le cache local de chaque nœud de requête est indépendant. Si différents réplicas consultables du même shard résident sur des nœuds différents, ils ne peuvent pas partager directement les données mises en cache. Par conséquent, l'affinité entre requête et préchauffage est activée par défaut. Lorsque le routage des shards reste stable, le préchauffage et les requêtes ultérieures accèdent de préférence au même réplica consultable. Cela permet de réutiliser le cache local du nœud de requête où réside ce réplica, ce qui réduit les lectures de données répétées depuis le stockage objet et empêche plusieurs réplicas de mettre en cache les mêmes données.

Par exemple, préchauffez une base de connaissances interrogée peu fréquemment avant que vos utilisateurs ne l'interrogent, puis exécutez la requête une fois le préchauffage terminé. Dans un environnement de production, préchauffez les données de manière asynchrone à l'avance afin que les requêtes des utilisateurs n'aient pas à attendre le préchauffage. L'exemple synchrone suivant montre la séquence d'appels :

POST /knowledge-chunks/_warm_slice?_slice=tenant-a&wait_for_completion=true&timeout=60s

Après avoir vérifié le résultat du préchauffage, exécutez la requête :

GET /knowledge-chunks/_search?_slice=tenant-a

L'affinité affecte uniquement le réplica auquel on accède de préférence et ne modifie pas les résultats des requêtes. L'affinité s'applique à :

• GET, MGet et Explain

• Sous-requêtes de Collection dans Search, Count, Search Template, Search Shards, Async Search et Multi Search

• Requêtes pour une seule Slice, plusieurs Slices et _slice=_all

• Update By Query et Delete By Query

• _warm_slice

L'affinité ne s'applique pas aux lectures côté source pour Reindex ni à Validate Query. Copy Slice utilise Reindex pour lire les données source, donc Copy Slice ne peut pas non plus garantir que le cache du réplica qui vient d'être préchauffé est réutilisé.

Lorsque l'affinité est activée (par défaut), vous n'avez pas besoin de définir preference. Toute valeur preference transmise dans une demande est remplacée par les règles d'affinité. Si votre activité nécessite d'utiliser preference pour contrôler la sélection des nœuds, l'administrateur du cluster doit désactiver l'affinité. Par exemple, _local accède de préférence aux nœuds locaux, et _only_nodes accède uniquement aux nœuds spécifiés.

Ce paramètre prend effet pour toutes les Collections et ne peut pas être modifié pour une seule Collection. Une fois l'affinité désactivée, les demandes de préchauffage qui ne comportent pas preference couvrent tous les réplicas consultables du shard cible, ce qui peut augmenter les lectures depuis le stockage objet et l'utilisation du cache local. Confirmez cet impact avant de modifier le paramètre. Pour désactiver l'affinité, soumettez la demande suivante :

PUT /_cluster/settings
{
  "persistent": {
    "apack.slice_collection.query_warm_affinity.enabled": false
  }
}

Ce paramètre prend effet dynamiquement et vous n'avez pas besoin de reconstruire la Collection. Une fois l'affinité désactivée, la valeur preference dans les demandes prend à nouveau effet. Si une requête ne transmet pas ce paramètre, la méthode de sélection de réplica d'origine est utilisée.

Que l'affinité soit activée ou non, le réplica effectivement accessible peut changer lorsqu'un réplica est migré ou devient indisponible, ou lorsqu'une demande est réessayée. L'affinité ne garantit pas qu'une demande reste définitivement liée à un nœud.