Description du problème
Aujourd'hui, lorsque j'ai utilisé ElacticSearch pour effectuer des requêtes de pagination, j'ai rencontré un problème étrange. Il était normal d'obtenir les 9999 premiers éléments de données lors de la pagination, mais chaque fois que je récupérais le 10 000ème élément de données, je ne pouvais pas obtenir les résultats. J'ai vérifié la logique de pagination dans mon code et n'ai trouvé aucun problème, j'ai donc effectué un débogage en une seule étape. Lorsque j'ai effectué une seule étape pour obtenir la 10 000ème donnée, j'ai détecté l'exception suivante :
Échec de l'exécution de la phase [query_fetch], toutes les partitions ont échoué ; shardFailures {[1w_m0BF0Sbir4I0hRWAmDA][fuxi_user_feature-2018.01.09][0] : RemoteTransportException[[10.1.113.169][10.1.113.169:9300][indices:data/read/search[phase/query+fetch]]] ; imbriqué : QueryPhaseExecutionException[La fenêtre de résultat est trop grande, à partir de + la taille doit être inférieure ou égale à : [10000] mais était de [10100]. Consultez l’API de défilement pour découvrir un moyen plus efficace de demander des ensembles de données volumineux. Cette limite peut être définie en modifiant le paramètre de niveau d'index [index.max_result_window].]; }
solution
Enfin, grâce à la vérification, j'ai appris que ce problème est dû aux limitations du mécanisme de rotation profonde des pages par défaut d'ElasticSearch. Un inconvénient du mécanisme de pagination par défaut d'ES est que, par exemple, s'il y a 5 010 éléments de données, lorsque vous souhaitez uniquement récupérer les 5 000e à 5010e éléments de données, ES chargera également les 5 000 premiers éléments de données dans la mémoire. , ainsi ES évite que les demandes de pagination excessives de l'utilisateur provoquent un débordement de mémoire sur la machine où se trouve le service ES. Par défaut, le nombre d'entrées de pagination approfondie est limité. Le nombre maximum d'entrées par défaut est de 10 000. C'est Result window is too largepourquoi une exception .
Pour résoudre ce problème, vous pouvez utiliser la méthode suivante pour modifier la index.max_result_window valeur maximale de la fenêtre de pagination en profondeur par défaut d'ES.
curl -XPUT http://127.0.0.1:9200/my_index/_settings -d '{ "index" : { "max_result_window" : 500000}}'Parmi eux, my_index est le nom de l'index à modifier et 500 000 est le nombre de nouvelles fenêtres à ajuster. Après avoir ajusté cette fenêtre, le problème de l'impossibilité d'obtenir des données après 10 000 éléments peut être résolu.
Précautions
Grâce à la méthode ci-dessus, notre problème est résolu, mais cela introduit également un autre problème qui nécessite notre attention. Une fois la valeur de la fenêtre augmentée, bien que le nombre d'éléments de données demandés à la pagination soit plus élevé, cela sacrifie plus de serveurs. En échange de mémoire et Ressources CPU. Il est nécessaire de déterminer si la demande de pagination excessive dans le scénario métier provoquera le problème OutOfMemory du service de cluster. La pagination en profondeur est également abordée dans la documentation officielle d'ES
https://www.elastic.co/guide/en/elasticsearch/guide/current/pagination.html
https://www.elastic.co/guide/en/elasticsearch/guide/current/pagination.html
Les idées principales sont les suivantes :
En fonction de la taille de vos documents, du nombre de fragments et du matériel que vous utilisez, la pagination de 10 000 à 50 000 résultats (1 000 à 5 000 pages) devrait être parfaitement réalisable. Mais avec des valeurs suffisamment grandes, le processus de tri peut devenir très lourd, utilisant de grandes quantités de CPU, de mémoire et de bande passante. Pour cette raison, nous déconseillons fortement la pagination profonde.
Ce que signifie cette déclaration : selon la taille du document, le nombre de fragments et le matériel utilisé, la pagination de 10 000 à 50 000 résultats (1 000 à 5 000 pages) devrait être tout à fait réalisable. Cependant, du point de vue de la valeur, utilisant beaucoup de CPU, de mémoire et de bande passante, le processus de classification devient assez important. Pour cette raison, nous déconseillons fortement la pagination profonde.
Mon propre point de vue est qu'en tant que moteur de recherche, ES est plus adapté à la recherche qu'à la traversée de résultats à grande échelle. Dans la plupart des scénarios, il n’est pas nécessaire d’obtenir plus de 10 000 éléments de résultat ; par exemple, seuls les 1 000 premiers résultats sont renvoyés. Si vous avez vraiment besoin de parcourir et d'afficher une grande quantité de données, demandez-vous si un autre stockage plus approprié peut être utilisé. Ou, selon le scénario commercial, voyez si vous pouvez utiliser l'API continue d'ElasticSearch (similaire aux itérateurs, mais avec le concept de fenêtres horaires).