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

Question

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

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

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

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

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

Answer 1

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

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

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

• Не делайте добавочного optimize() вообще. Мой опыт показывает, что вы все равно не видите значительного улучшения запросов.
• Делайте optimize() ежедневно вместо 2-х часов.
• Выполните optimize() во время малой громкости (это то, что говорит javadoc ).

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

Answer 2

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

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

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

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

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

Answer 3

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