Агрессивный merge сегментов ES

[GreenX]

День добрый!
В продолжение темы про "НЕ идеальный" подсчет _score:

Я попробовал настроить более агрессивный merge в ES, но не особо получилось.

Из всех крутилов в:
https://github.com/elastic/elasticsearch/blob/7.10/server/src/main/java/org/elasticsearch/index/MergePolicyConfig.java

• Самой эффективной оказаласьindex.merge.policy.segments_per_tier. Как только в шарде больше сегментов - работает merge. Относительно её правится max_merge_at_once. Но, как то медленно ввод/вывод идет, как будьто еще IO scheduler для этих операций есть, который я не нашел.
• index.merge.policy.expunge_deletes_allowed похоже рабратает только при вызове
  ``_forcemerge?only_expunge_deletes=true
• index.merge.policy.deletes_pct_allowed меньше 20% не задать, а 20% от нескольких ТБ много.
• index.merge.policy.reclaim_deletes_weight вообще выпилили
• Ради интереса ставил"index.merge.policy.floor_segment": "1b", чтобы склеивались и самые маленькие шарды - не сработало

И самый главный фатальный недостаток - MergePolicy походе вызывается только из IndexWriter.

Т.е. если индекс постепенно остывает и становится только для чтения(поиска) нет шансов, что удаленные документы когда то удалятся на самом деле их число сравняется (или будет близким) и _score будет считаться правильно. (индекс обновляется периодичеки, сильно, но редко).

Пока у меня только один вариант: периодически cron-ом вызывать _forcemerge, если ElasticSearch сам этого не делает.

Поправте меня, если я ошибаюсь и есть нормальное решение.

P.S. идеальный _score получается если количество помеченных на удаление документов совпадает во всех шардах и репликах. А посколько это процесс ассинхронный, то это число ноль!

[Igor_Motov]

@GreenX

Т.е. если индекс постепенно остывает и становится только для чтения(поиска) нет шансов, что удаленные документы когда то удалятся на самом деле их число сравняется (или будет близким) и _score будет считаться правильно. (индекс обновляется периодичеки, сильно, но редко).

Это процесс можно автоматизировать.

[GreenX]

Спасибо, понял. У нас исторически сложилось, что на OSS версии сидим, поэтому не вкурсе всех возможностей X-pack Не пригципиально, но нам пока хватало.
Решалось так:

# cat /etc/cron.d/elastic_cleanup 
0 0 * * sun elasticsearch sleep ${RANDOM:0:2}m ; curl -s http://localhost:9200/_cat/tasks|fgrep forcemerge || curl -s http://localhost:9200/_all/_forcemerge?max_num_segments=1 -XPOST

Вернее так, в своё время меня насторожило, что X-pack открыли, но как то странно, под другой лицензхией, в роли плагина, тогда мы и перешли на OSS.

[GreenX]

Еще раз подумал. Всё-таки странно, но эта пришлёпка где то отдельно в X-pack, а не в базе. Старнно, что сам Эластик, если стоит и ничего не делает потихоньку не прибирается в индексах.