Elasticsearch:Opérations d'écriture, de lecture et d'interrogation des documents

Confirmer une écriture par ID sans actualisation

Pour confirmer uniquement le document que vous venez d'écrire, utilisez GET ou MGet. Ces deux méthodes activent les lectures en temps réel par défaut (realtime=true), il n'est donc pas nécessaire de transmettre explicitement le paramètre ni de déclencher une actualisation manuelle. Par exemple, après la réussite d'une requête d'écriture, lisez le document avec le même Slice et le même ID de document :

GET /knowledge-chunks/_doc/chunk-1001?_slice=tenant-a

Vérifiez la valeur found renvoyée ainsi que les champs métier. Pour MGet, vérifiez chaque résultat. Les lectures en temps réel ne constituent pas une garantie de cohérence forte pendant chaque fenêtre de défaillance. Si le shard principal n'est pas disponible, ou si une migration ou un redémarrage rend temporairement la source de lecture en temps réel indisponible, GET et MGet peuvent revenir à la vue des données validées. Ils renvoient alors une version antérieure, ou retournent found=false pour un document qui n'a pas encore intégré cette vue. Dans ce cas, évaluez le résultat en fonction du résultat d'écriture et de l'état du cluster, et effectuez de nouvelles vérifications après un nombre limité de tentatives. Ne concluez pas à la perte d'une écriture sur la base d'une seule réponse indiquant que le document est introuvable.

Recherche par condition et attente de l'actualisation automatique en arrière-plan

Les requêtes Search, Count et KNN doivent attendre que les données soient consultables sur les nœuds de requête. La version du moteur Agent dispose d'un intervalle d'actualisation automatique par défaut de 5s ; vous n'avez pas besoin de le configurer lors de la création d'un index standard ou d'une Collection. La valeur par défaut pour Elasticsearch traditionnel avec état est de 1s. Le délai réel avant que les données deviennent consultables dépend également de la publication des données, du chargement des nœuds de requête et de la charge de travail. 5s ne constitue pas une échéance garantie de visibilité.

Utilisez GET /{collection}/_settings pour afficher uniquement les paramètres que vous avez explicitement configurés, et ajoutez include_defaults=true pour renvoyer également les valeurs par défaut. Utilisez PUT /{collection}/_settings pour ajuster le paramètre. Maintenez l'actualisation automatique activée pour les charges de travail de production. Définissez l'intervalle à au moins 5s. Un intervalle plus court augmente la publication des données sur les nœuds d'index, les E/S du stockage objet et la surcharge d'actualisation sur les nœuds de requête. Pour contrôler la charge d'écriture, augmentez l'intervalle selon les besoins et évaluez la latence de visibilité des données qui en résulte.

Utiliser refresh=wait_for uniquement dans des scénarios limités

refresh=wait_for est destiné uniquement aux points de synchronisation métier ponctuels et peu fréquents. Utilisez-le uniquement si toutes les conditions suivantes sont remplies : (1) le lot doit devenir consultable avant la poursuite du traitement, (2) le paramètre est utilisé avec un lot Bulk, (3) les attentes simultanées sont limitées, (4) l'actualisation automatique reste activée et (5) vous avez évalué l'impact du temps d'attente sur la latence et le débit métier. Pour confirmer une écriture par ID, utilisez GET ou MGet. Ne transmettez pas ce paramètre pour les importations continues ou les écritures standard.

Ce paramètre attend une actualisation et coordonne la visibilité sur les réplicas de requête. Trop d'attentes simultanées ou l'épuisement des écouteurs d'actualisation peuvent également déclencher une actualisation forcée, identifiable par forced_refresh: true dans la réponse. Même lorsqu'une actualisation forcée est déclenchée, la requête peut continuer à attendre la visibilité côté requête et n'est pas garantie de retourner immédiatement. Un délai d'expiration du client ne signifie pas que l'écriture n'a pas eu lieu. N'augmentez pas les attentes simultanées pour accélérer une actualisation.

Utiliser l'actualisation manuelle uniquement pour une vérification isolée ou une fenêtre d'O&M

N'ajoutez pas refresh=true au code de votre application et n'appelez pas _refresh. N'effectuez pas d'actualisation automatique après chaque lot d'importation. refresh=true déclenche une actualisation distribuée immédiate, ce qui augmente la publication des données, les E/S du stockage objet et la surcharge d'actualisation sur les nœuds de requête. L'actualisation automatique en arrière-plan constitue l'alternative standard.

POST /{collection}/_refresh affecte tous les Backings et tous les locataires de l'ensemble de la Collection. Vous ne pouvez pas estimer sa surcharge à partir du volume de données de votre propre Slice, et l'impact de la même requête augmente avec le nombre de Backings et le volume de données. Vous ne pouvez pas réduire l'étendue avec _slice. La transmission de _slice à ce point de terminaison renvoie une erreur HTTP 400. Une Collection ne fournit pas de point de terminaison d'actualisation pour un seul Backing destiné aux appels d'application.

Utilisez l'actualisation manuelle uniquement pour une Collection de vérification créée séparément contenant une petite quantité de données de démonstration, ou pendant une fenêtre d'O&M peu fréquente planifiée par un administrateur après évaluation de la taille de l'ensemble de la Collection. L'importation hors ligne ponctuelle décrite dans la section suivante constitue l'un de ces créneaux. Après l'actualisation, vérifiez _shards.failed. Les importations en ligne standard doivent attendre l'actualisation automatique en arrière-plan. Si vous devez préchauffer les données, effectuez cette opération une fois que les données sont consultables.

Désactiver l'actualisation automatique uniquement pour une importation hors ligne ponctuelle

Ne définissez pas index.refresh_interval=-1 pour une Collection de production. Ce paramètre désactive l'actualisation automatique, de sorte que les recherches ne voient pas les données nouvellement écrites en temps utile. Lorsque vous le combinez avec refresh=wait_for, une requête peut attendre longtemps, voire expirer.

La seule exception concerne une fenêtre d'importation hors ligne ponctuelle clairement définie pour l'ensemble de la Collection cible, durant laquelle aucun des locataires associés n'exécute de requêtes. Au cours de cette fenêtre, effectuez les étapes suivantes dans l'ordre : (1) Omettez refresh pendant l'importation. (2) Une fois l'importation terminée, rétablissez 5s ou l'intervalle précédent d'au moins 5s en appelant PUT /{collection}/_settings. (3) Toujours dans la même fenêtre, demandez à la tâche d'importation d'exécuter _refresh une fois, puis vérifiez _shards.failed dans la réponse. (4) Vérifiez que les requêtes renvoient les données importées. (5) Si la charge de travail est sensible à la latence des requêtes à froid, préchauffez les données avant de rétablir le trafic de production. N'utilisez pas ce processus pour une Collection qui dessert encore d'autres locataires.

Une actualisation concerne uniquement la visibilité des requêtes. Elle ne signifie pas que tous les réplicas de requête sont disponibles et ne peut pas remplacer les sondes de requête ou les vérifications de haute disponibilité (HA).

Comportement par défaut lorsque _slice n'est pas spécifié

En mode namespace (exact), Search, Count, Search Template, Async Search, Validate Query et Search Shards requièrent _slice par défaut. La requête échoue en l'absence de ce paramètre. Pour le petit nombre de tâches dédiées répondant aux conditions de requête complète décrites précédemment, transmettez explicitement _slice=_all dans ces requêtes au lieu de modifier le comportement par défaut global. Le mode de rappel de cluster vectoriel peut sélectionner automatiquement les Slices candidats en fonction du vecteur de requête. Pour plus d'informations, consultez Mode de rappel de cluster vectoriel.

Maintenez la solution de secours de requête complète désactivée par défaut. Le paramètre de cluster apack.slice_collection.search.default_to_all_slices contrôle cette solution de secours, et le paramètre affecte toutes les Collections. En mode namespace, lorsque _slice n'est pas spécifié, la requête revient à tous les Slices. Le mode de cluster vectoriel revient à une requête complète uniquement lorsqu'aucune étendue n'est spécifiée et que le chemin de configuration ne contient pas de vecteur de requête ; lorsqu'un vecteur de requête valide est fourni, les Slices candidats sont toujours sélectionnés normalement. Une solution de secours de requête complète augmente la surcharge des requêtes de shard, des agrégations et des lectures du stockage objet.

Une tâche dédiée nécessitant réellement une requête complète doit spécifier explicitement l'étendue dans chaque requête. Ne vous fiez pas à ce commutateur global pour garantir une requête complète. Activez ce commutateur à l'échelle du cluster uniquement lorsque l'application dépend explicitement de la solution de secours de requête complète, qu'un administrateur a évalué la charge sur toutes les Collections concernées et que des contrôles de concurrence et de délai d'expiration sont en place :

PUT /_cluster/settings
{
  "persistent": {
    "apack.slice_collection.search.default_to_all_slices": true
  }
}

Une fois le commutateur activé, GET /knowledge-chunks/_search en mode namespace équivaut à transmettre explicitement _slice=_all. En mode de cluster vectoriel, les chemins invalides, query_vector_builder et les dimensions de vecteur incorrectes sont toujours rejetés. Pour plus d'informations, consultez Sélection automatique des Slices candidats.

Ce paramètre s'applique uniquement aux points de terminaison de requête répertoriés ci-dessus qui n'écrivent pas de données. Il ne s'applique pas à GET, MGet, Explain, Reindex, Update by query ni Delete by query.

Paramètre de compatibilité de routage

Pour une Collection ou un alias de Collection, les API d'écriture, de lecture et de requête de documents acceptent le paramètre standard Elasticsearch routing à la place de _slice. Les deux paramètres représentent le même Slice logique et sont sémantiquement équivalents, de sorte que cette syntaxe de compatibilité permet à vos clients Elasticsearch existants de continuer à fonctionner. Pour les nouvelles applications, utilisez _slice, qui est sémantiquement plus clair. Notez les contraintes suivantes :

• Ne fournissez pas à la fois _slice et routing dans la même URL ou dans le même élément Bulk ou MGet.

• Cette syntaxe de compatibilité ne s'applique pas à source.routing dans le corps d'une requête Reindex, aux points de terminaison de gestion de Collection et de Slice, au préchauffage du cache, à Copy Slice, CAT ni à une actualisation explicite.

• Cette syntaxe de compatibilité ne modifie pas la sémantique de routage des index Elasticsearch standard.

Index standard dans les requêtes mixtes

Lorsqu'une requête de type Search contient à la fois des index standard et des Collections, le paramètre de cluster apack.slice_collection.rewrite.mixed_collection_targets détermine le comportement :

Dans ce cas, routing est toujours traité selon les règles de routage des index standard et ne représente pas un Slice dans une Collection. Même si tous les noms d'une requête mixte existent et que la requête aboutit, ne supposez pas que les résultats contiennent des données de Collection.

Une requête contenant à la fois une Collection et une cible distante est également traitée comme une requête mixte. Si l'instance contient une Collection, les règles précédentes s'appliquent également à GET /_search sans index. Par défaut, le paramètre ignore uniquement la réécriture du point d'entrée logique de la Collection. Une requête wildcard complète ou trop large peut toujours correspondre directement aux Backings visibles, et une telle requête ne peut pas remplacer une requête étendue par Collection et Slice.

Pour lire les deux types de données, envoyez des requêtes séparées et demandez à l'application de fusionner les résultats.