Долгий реиндекс неотсортированных данных

Elastic In Your Native Tongue Вопросы на русском языке
1

Добрый день.
Имеется около 120 млн объектов, которые нужно проиндексировать.

Отправляю объекты на реиндекс предварительно отсортировав (по полю id типа guid), реиндекс занимает около 8 часов.

Отправляю эти же объеты не сортируя - индексация занимает 3 суток и более, причём первые 10-20 млн объектов индексируются довольно быстро, каждые последующие 5 млн объектов индексируются всё медленнее, после 60млн объекты индексируются адски медленно.

В обоих случаях индекс предварительно создаётся с ноля, id документа генерируется на стороне эластика, сортировка индексу не задаётся. Во втором случае (при медленной индексации) BLOCK I/O эластик-докера в 4-5 раз больше.

В чём может быть причина такого поведения? Связано ли это как-то с мержем сегментов? Почему влияет предварительная сортировка объектов (хотя сам эластик про неё ничего не знает)?

P.S. используется одна нода эластика.

2

Как генерируются id? Если взять два документа с похожими id, есть вероятность, что остальные поля тоже будут похожи? Например, если компонента id, отвечающая за узел одна и та же и узел генерирует почти одни и те же документы, то документы близкие по id будут более похожи друг на друга чем документы значительно отличающиеся друг от друг по id. Возможна у вас такая ситуация? Если нет, то надо смотреть на установки индекса, мэппинг и команду переиндексации

3

id генерируется как маркер + guid.
Что за компонента, отвечающая за узел? Что подразумевается под "узел", который генерирует докуметы?
Документы могут быть между собой похожи, могут быть полностью идентичны (кроме id) вне зависимости от id. На что может влиять похожесть документов? Тем более, если в документы в обоих случаях одни и те же.

Какие установки индекса нужно смотреть? Установки и маппинг в обоих случаях (медленный и быстрый реиндекс) полностью одинаковые. Команда переиндексации тоже.

4

Идея такая, если документы с одинаковым маркером почти одинаковые, то при индексации они попадут в один и тот же сегмент и очень хорошо скомпрессируются. Это в свою очередь значительно уменьшит размер индекса, нагрузку на диск и т.д.

5

Т.е. при индексации ищутся похожие документы и кладутся в один сегмент? Т.е. при добавлении нового документа эластик пробегается по всем существующим документам и как-то сравнивает их чтобы найти похожие?

6

Кстати, в моём случае эластик ничего не знает про id объекта - это просто одно из нескольких полей? _id документа генерирует сам эластик.

7
8

Ничего не написано про то, что эластик как-то группирует "похожие" объекты..

9

It works by grouping documents into blocks of 16KB and then compresses them together using LZ4, a lightweight compression algorithm. The benefit of this approach is that it also helps compressing short documents since several documents would be compressed into a single block.

Если вы один и тот же документ компрессируете в одном блоке несколько раз, то сжатие будет гораздо выше, чем если туда добавлять разные документы.

10

Так про сжатие понятно, вопрос в другом - почему время индексирования существенно разное? Почему индесация каждой последующей партии объектов существенно замедляется? Ищутся ли дубли во всём существующем индексе (а не только в пределах блока 16k) при добавлении нового документа?

Понятно, что если в пачке объектов много дублей, то этот сегмент лучше и, вероятно, быстрее сожмётся, и в итоге индекс на диске займёт меньше места (кстати, в моём случае я не вижу существенной разницы итогового размера индекса, но это не точно). Но, опять же, это всё происходит перед сбросом сегментов на диск, и не должно так сильно влиять на величину i/o диска.

11

Дубли не ищутся вообще. Просто во время индексации создается много сегментов, которые потом сливаются в более большие сегменты, если сегменты изначально маленькие, то время сливание и I/O значительно меньше. Другими словами, это в первую очередь влияет на I/O, все остальное уже из этого следует.

12

В эту картину только не укладывается тот факт, что реиндекс существенно замедляется с ростом индекса.

Спасибо за ответы.

13
14

Спасибо, видел это видео. В целом оно даёт понимание о том, как мержатся сегменты. Но из него не видно, как на процесс может влиять сортировка.

Т.е. то, что при сортировке данных возможно подобные документы оказываются рядом и попадают в один батч, индексируются быстрее и индекс занимает меньше места (за счёт лучшего сжатия) - понятно и логично. Но никак не могу понять, почему с ростом индекса может существенно замедляться скорость индексации неотсортированных данных. Получается на реальных данных надо готовиться к худшему варианту - очень медленной индексации.

15

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.