ElasticSearch - haut débit d'indexation
Je compare ElasticSearch à des fins de débit d'indexation très élevé.
Mon objectif actuel est de pouvoir indexer 3 milliards (3 000 000 000) de documents en quelques heures. À cet effet, j'ai actuellement 3 machines de serveur Windows, avec 16 Go RAM et 8 processeurs chacun. Les documents insérés ont un mappage très simple, ne contenant qu'une poignée de champs numériques non analysés (_all est désactivé).
Je peux atteindre environ 120 000 demandes d'index par seconde (surveillance à l'aide d'un grand bureau), en utilisant cette plate-forme relativement modeste, et je suis convaincu que le débit peut être encore augmenté. J'utilise un certain nombre de clients .net NEST pour envoyer les demandes d'index en bloc, avec 1500 opérations d'index en bloc.
Malheureusement, le débit de 120 000 requêtes par seconde ne dure pas très longtemps et le taux diminue progressivement, tombant à environ 15 000 après quelques heures.
La surveillance des machines révèle que les processeurs ne sont pas le goulot d'étranglement. Cependant, le temps d'inactivité du disque physique (et non du SSD) semble diminuer sur toutes les machines, atteignant moins de 15% d'inactivité moyenne.
Réglage refresh_interval à 60s, à 300s, et enfin 15m, ne semble pas beaucoup aider. Espionner un seul translog dans un seul fragment, a montré que le translog est vidé toutes les 30 minutes, avant d'atteindre 200 Mo.
J'ai essayé d'utiliser deux stratégies de partage:
- 1 index, avec 60 fragments (pas de répliques).
- 3 indices, avec 20 éclats chacun (pas de répliques).
Les deux tentatives aboutissent à une expérience assez similaire, ce qui, je suppose, est logique car il s'agit du même nombre de fragments.
En regardant les segments, je peux voir que la plupart des fragments ont ~ 30 segments validés, et un nombre similaire de segments consultables également. La taille des segments varie. À un moment donné, une tentative d'optimisation de l'index avec max_num_segments = 1, semblait avoir aidé un peu après sa fin (cela a pris du temps).
À tout moment, le démarrage de l'ensemble du processus d'ingestion depuis le début, après la suppression des indices utilisés et la création de nouveaux indices - entraîne le même comportement. Débit d'index initialement élevé, mais diminuant progressivement, bien avant d'atteindre l'objectif de 3 milliards de documents. La taille de l'index à cette époque est d'environ 120 Go.
J'utilise la version ElasticSearch 1.4. Xms et Xmx sont configurés pour 8192 Mo, 50% de la mémoire disponible. Le tampon d'indexation est défini sur 30%.
Mes questions sont les suivantes:
- En supposant que le disque est actuellement le goulot d'étranglement de cette plate-forme, ce phénomène d'augmentation progressive de l'utilisation du disque est-il normal? Sinon, que peut-on faire pour annuler ces effets?
- Existe-t-il un réglage fin que je puisse faire pour augmenter le débit d'indexation? Devrais-je? ou devrais-je simplement évoluer.
Pour faire court, je me suis retrouvé avec 5 machines linux virtuelles, 8 cpu, 16 Go, utilisant des marionnettes pour déployer elasticsearch. Mes documents sont devenus un peu plus volumineux, mais le débit de traitement a également augmenté (légèrement). J'ai pu atteindre 150 000 requêtes d'index par seconde en moyenne, indexant 1 milliard de documents en 2 heures. Le débit n'est pas constant, et j'ai observé un comportement de débit décroissant similaire à celui d'avant, mais dans une moindre mesure. Étant donné que j'utiliserai des indices quotidiens pour la même quantité de données, je m'attendrais à ce que ces mesures de performances soient à peu près similaires chaque jour.
Le passage des machines Windows à Linux était principalement dû à la commodité et au respect des conventions informatiques. Bien que je ne sois pas sûr, je soupçonne que les mêmes résultats pourraient également être obtenus sur Windows.
Dans plusieurs de mes essais, j'ai tenté d'indexer sans spécifier les identifiants des documents comme l'a suggéré Christian Dahlqvist. Les résultats ont été étonnants. J'ai observé une augmentation de débit significative , atteignant 300k et plus dans certains cas. La conclusion de ceci est évidente: ne spécifiez pas d'ID de document, sauf si vous devez absolument le faire.
De plus, j'utilise moins de fragments par machine, ce qui a également contribué à l'augmentation du débit.