Следует ли оптимизировать индекс после дополнительных индексов в Lucene?

Question

Мы проводим полную переиндексацию каждые 7 дней (т. е.создание индекса с нуля) для нашего индекса Lucene и дополнительных индексов каждые 2 часа или около того.Наш индекс содержит около 700 000 документов, а полный индекс занимает около 17 часов (что не является проблемой).

Когда мы выполняем инкрементальное индексирование, мы индексируем только тот контент, который изменился за последние два часа, поэтому это занимает гораздо меньше времени — около получаса.Однако мы заметили, что большая часть этого времени (около 10 минут) тратится на выполнение метода IndexWriter.optimize().

А LuceneFAQ упоминает, что:

Класс IndexWriter поддерживает методоптимизации(), который сжимает базу данных индексов и ускоряет запросы.Вы можете использовать этот метод после выполнения полной индексации набора документов или после дополнительных обновлений индекса.Если при добавочном обновлении документы часто добавляются, оптимизацию следует выполнять только время от времени, чтобы избежать дополнительных затрат на оптимизацию.

... но, похоже, это не дает никакого определения тому, что означает «часто».Оптимизация требует большого количества ресурсов ЦП и ОЧЕНЬ интенсивного ввода-вывода, поэтому мы бы предпочли не делать этого, если нам это сойдет с рук.Насколько велик ущерб от выполнения запросов к неоптимизированному индексу (я думаю, особенно с точки зрения производительности запросов после полного повторного индексирования по сравнению с после 20 дополнительных индексов, когда, скажем, изменилось 50 000 документов)?Должны ли мы проводить оптимизацию после каждого дополнительного индекса или снижение производительности того не стоит?

Answer 1

Мэт, поскольку ты, кажется, хорошо понимаешь, сколько времени занимает текущий процесс, я предлагаю тебе удалить optimize() и измерить эффект.

Многие ли документы меняются за эти 2 часа?Если постепенно переиндексируется лишь небольшая часть (50 000/700 000, это около 7%), то я не думаю, что вы получите большую пользу от optimize().

Некоторые идеи:

• Не делайте постепенного optimize() совсем.Мой опыт показывает, что вы все равно не увидите огромного улучшения запросов.
• Сделайте optimize() ежедневно вместо 2 часов.
• Сделайте optimize() в периоды малого объема (именно это Javadoc говорит).

И обязательно сделайте замеры.Без них такого рода изменения могут быть пустым звуком.

Answer 2

Ан optimize операция читает и записывает весь индекс, поэтому она требует столь большого количества операций ввода-вывода!

Идея операций оптимизации заключается в повторном объединении всех различных сегментов индекса Lucene в один сегмент, что может значительно сократить время запроса, поскольку вам не нужно открывать и искать несколько файлов для каждого запроса.Если вы используете обычную структуру индексного файла Lucene (а не комбинированную структуру), вы получаете новый сегмент для каждой операции фиксации;я полагаю, то же самое, что и ваши переиндексации?

Я думаю Мэтт у него отличный совет, и я поддерживаю все, что он говорит: руководствуйтесь имеющимися у вас данными.На самом деле я бы пошел еще дальше и оптимизировал бы только а) когда вам нужно и б) когда у вас небольшой объем запросов.

Поскольку производительность запросов тесно связана с количеством сегментов в индексе, простой ls -1 index/segments_* | count может быть полезным индикатором того, когда оптимизация действительно необходима.

Альтернативно, лучшим решением было бы отслеживание производительности и объема запросов и запуск оптимизации при достижении неприемлемо низкой производительности при приемлемо низком объеме.

Answer 3

В это письмо, Отис Господнетические советы против используйте оптимизацию, если ваш индекс постоянно обновляется.Это из 2007 года, но звоню optimize() по своей природе это операция с большим количеством операций ввода-вывода.Вы могли бы рассмотреть возможность использования более поэтапного подхода;а MergeScheduler