Sur une architecture Hot/Warm/Frozen au moment du Warm il est plus que pertinent d’utiliser le force merge avec 1 segment Le force merge permet une recherche plus performante si il n’y a plus d’écriture sur l’index
PUn index Elasticsearch est un groupe logique de shards. Chaque shard est un “index Lucene” (Lucene est la technologie de stockage et de recherche sous-jacente d’Elasticsearch). Dans Lucene, un index unique est souvent divisé en plusieurs index appelés “segments”. Avoir plusieurs segments est avantageux pour l’efficacité d’écriture, car nous écrivons toujours de nouveaux segments au lieu de modifier les index existants : les segments sont immuables.
Par conséquent, les performances de recherche souffrent à mesure que le nombre de segments augmente. En effet, les segments sont recherchés en séquence par un seul thread lors d’une recherche de shard. Pour optimiser la recherche, les segments sont “fusionnés” (merge) en moins de segments. Un processus appelé “background merging” se produit constamment, mais uniquement lorsque de nouvelles données sont écrites. Le merge en arrière-plan ne fusionnera jamais, par conception, jusqu’à 1 segment car il est inefficace de le faire alors que nous nous attendons à ce que des données supplémentaires soient écrites sur le shard.
Si après un événement, tel qu’un rollover d’index, ou une relocalisation de hot vers warm, ou une période de temps, nous savons avec certitude qu’un index ne recevra plus de mises à jour supplémentaires, il est extrêmement avantageux de le force merge à 1 segment . 1 segment peut être recherché 4 fois plus vite que 4 segments. Mais attention (avertissement), si ne serais-ce qu’une écriture supplémentaire se produit après le merge, nous aurons soudainement 2 segments, une recherche moins efficace de 50 % et beaucoup de travail supplémentaire pour le merge de nouveau en 1 segment. Pour cette raison, il est préférable également de définir “index.blocks.write : true” avant de forcer la fusion, pour garantir la stabilité. Lorsque vous utilisez ILM, le blocage d’écriture est défini automatiquement lorsque l’action de force merge est activée.
Si vous utilisez une architecture à plusieurs niveaux (Hot/Warm/Frozen), il ne devrait normalement pas y avoir de force merge sur la zone Hot, mais il est certain qu’au moment où un index est en Frozen, il devrait toujours être fusionné à 100 %.
Force merge et les global ordinals
Un avantage supplémentaire du force merge en 1 segment est le fait qu’il n’est pas nécessaire de générer des global ordinals. Les global ordinals sont des structures de données en mémoire qui sont générées au moment de la recherche (ou éventuellement au moment de l’indexation) pour remplir certains types d’agrégations (comme une agrégation de termes sur un champ keyword à cardinalité élevée). Les global ordinals sont coûteux à générer (ils apparaissent dans les statistiques de données de champ) et ils peuvent atteindre plusieurs Go d’utilisation de la JVM. Le force merge peut éviter la génération de global ordinals car les données seront triées dans un seul segment.