Как обрабатывать очень частые обновления индекса Lucene

Question

Я пытаюсь создать прототип приложения индексирования / поиска, которое использует очень нестабильные источники данных индексации (форумы, социальные сети и т. Д.), Вот некоторые требования к производительности,

1. Очень быстровремя оборота (под этим я подразумеваю, что любые новые данные (например, новое сообщение на форуме) должны быть доступны в результатах поиска очень скоро (менее минуты))

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

3. И последнее, но не менее важное: приложение поиска должно реагировать.(задержка порядка 100 миллисекунд и должна поддерживать не менее 10 кадров в секунду)

Все требования, которые у меня есть в настоящее время, могут быть выполнены без использования Lucene (и это позволило бы мнеудовлетворить все 1,2 и 3), но в будущем я ожидаю другие требования (например, релевантность поиска и т. д.), которые Lucene упростит для реализации.Однако, поскольку Lucene разработан для вариантов использования, гораздо более сложных, чем тот, над которым я сейчас работаю, мне трудно удовлетворять моим требованиям к производительности.

Вот несколько вопросов,

а.Я прочитал, что метод optimize () в классе IndexWriter стоит дорого, и его не следует использовать приложениям, которые часто обновляются. Какие есть альтернативы?

b.Чтобы делать постепенные обновления, мне нужно продолжать фиксировать новые данные, а также обновлять программу чтения индекса, чтобы убедиться, что в ней есть новые данные.Это повлияет на 1 и 3 выше.Должен ли я попробовать дубликаты индексов?Каковы некоторые общие подходы к решению этой проблемы?

c.Я знаю, что Lucene предоставляет метод удаления, который позволяет вам удалить все документы, которые соответствуют определенному запросу, в моем случае мне нужно удалить все документы, которые старше определенного возраста, теперь один вариант - добавить поле даты к каждомудокумент и использовать это, чтобы удалить документы позже.Можно ли выполнять диапазонные запросы по идентификаторам документов (я могу создать собственное поле идентификатора, поскольку я думаю, что поле, созданное lucene, постоянно меняется), чтобы удалить документы?Это быстрее, чем сравнивать даты, представленные в виде строк?

Я знаю, что это очень открытые вопросы, поэтому я не ищу подробный ответ, я постараюсь рассматривать все ваши ответы как предложения и использовать их для информирования моего дизайна.Спасибо!Пожалуйста, дайте мне знать, если вам нужна другая информация.

Answer 1

Lucene теперь поддерживает Поиск в реальном времени .По сути, вы получаете Reader от IndexWriter каждый раз, когда вы выполняете поиск.Изменения в памяти не отправляются на диск до тех пор, пока не будет достигнут размер буфера ОЗУ или не будет вызван явный commit на записывающем устройстве.Поскольку дисковый ввод-вывод исключается путем пропуска commit, поиск быстро возвращается даже с новыми данными.

Одной из проблем с NRT Lucene является алгоритм слияния логарифмов индекса.Объединение инициируется после добавления 10 документов в сегмент.Затем такие 10 сегментов объединяются для создания сегмента с 100 документами и так далее.Теперь, если у вас есть 999 999 документов, и слияние инициировано, потребуется много времени, чтобы вернуться, нарушая ваше обещание в режиме реального времени.

LinkedIn выпустила Zoie , библиотеку поверх Lucene, которая решает эту проблему.Он работает в режиме реального времени и обрабатывает миллионы обновлений и выполняет поиск каждый день.

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

Answer 2

Возможно, вы захотите использовать Solr, а не прямой Lucene. Solr обрабатывает все требования, которые вы упомянули (обновления почти в реальном времени, удаление документов, производительность / разбиение, запросы диапазона), и это будет лучше, чем ваш собственный свернутый вручную код. Вам не придется иметь дело с проблемами на уровне IndexReader, то есть когда обновлять IndexReader после обновления.

Что касается запросов диапазона, Solr обладает возможностями TrieField, что делает запросы числового диапазона очень быстрыми. Смотри http://www.lucidimagination.com/blog/2009/05/13/exploring-lucene-and-solrs-trierange-capabilities/

Answer 3

Вы можете кешировать ваш поисковик индексов на короткое время и снова открыть его. Для этой цели мы используем asp.net WebCache с CacheItemUpdateCallback, который вызывается непосредственно перед истечением времени действия элемента chached.

Answer 4

A: Я думаю, что в последних версиях Lucene метод оптимизации на самом деле не нужен, и с моим предложением по пункту C он действительно не нужен.

B: Опять же, я думаю, что с последней версией Lucene поисковики знают, когда обновления сделаны, и могут справиться с этим без необходимости делать что-то особенное.

C: я бы избегал удаления и просто ежедневно создавал новый индекс. Если вы храните возраст документа в индексе, то вы можете использовать существующий индекс для создания нового. Во время написания индекса извлеките все молодые документы, просмотрите их и добавьте в новый индекс. Иметь публичный метод утилит getCurrentIndex, который используется поисковиками для получения последнего живого индекса. Держите 1 или 2 старых индекса на всякий случай, и вам будет хорошо идти.