Лучшая практика для обеспечения того, чтобы индекс Solr / Lucene был «актуальным» после длительного перестроения

Question

У нас есть общий вопрос о передовом опыте / программировании при длительной перестройке индекса. Этот вопрос не является "специфичным для solr" и может с таким же успехом применяться к необработанному Lucene или любому другому подобному инструменту индексирования / библиотеке / черному ящику.

Вопрос

Какова лучшая практика для обеспечения того, чтобы индекс Solr / Lucene был «абсолютно актуальным» после длительной перестройки индекса, т.е. если в течение 12-часового перестроения индекса пользователи имеют возможность добавлять / изменять / удалять записи или файлы БД ( PDF), как вы гарантируете, что индекс перестроения в самом конце «включает» эти изменения?

Context

• Большая база данных и файловая система (например, pdfs), проиндексированные в Solr
• Экземпляр многоядерного solr, где core0 предназначен для «поиска», а все добавления / изменения / удаления core1 - для «перестроения». Core1 - «временное ядро».
• После окончания перестройки мы «перемещаем» core1 в core0, поэтому поиск и обновления идут по отношению к недавно перестроенной базе данных

Текущий подход

• Процесс перестройки запрашивает базу данных и / или пересекает файловую систему для «всех записей базы данных» или «всех файлов»
• Перестройка «получит» новые записи / pdf в БД, если они произойдут в конце обхода запроса / файловой системы. (Например, запрос «выбрать * из порядка элементов по element_id». Если мы оставим результирующий набор открытым, т. Е. Вместо того, чтобы создавать большой список сразу, результирующий набор будет содержать записи, добавленные в конце. Аналогично, если новые файлы добавляются «в конце» (новая папка или новый файл), обход файлов будет включать эти файлы.
• Перестройка не «получит» следующее: изменения или удаление в БД записей / документов, которые процесс перестройки уже обработал, «просто переиндексация»

Предлагаемый подход

• Отслеживание в клиенте Solr (т.е. через таблицу db) всех добавлений / изменений / удалений, которые происходят в db / filesystem
• В конце перестройки (но до замены ядра) обработайте эти изменения: то есть удалите из индекса все удаленные записи / PDF-файлы, переиндексируйте все обновления и дополнения

Следуйте

• Есть ли лучший подход
• Есть ли у solr какие-либо магические средства для «объединения» core0 в core1

Спасибо

Answer 1

Есть несколько способов сделать скин для этого кота .... Я предполагаю, что во время длительного процесса индексации core1 (он же ядро ​​"на палубе") вы выполняете пользовательские запросы к уже заполненному core0 (он же "live").«ядро».

1. Если вы можете различить, что изменилось, почему бы просто не обновить живое ядро?Если вы можете выполнять запросы к живому ядру и вашей файловой системе PDF, чтобы выяснить, какие документы были обновлены, а какие удалены, просто сделайте все это с живым ядром и отбросьте этот автономный процесс.Это было бы самым простым .... Просто поместите время обновления pdf в ваш документ solr, чтобы определить, какие из них изменились.Если PDF не существует в Solr, то добавьте его.Сохраните список идентификаторов документов Solr, и, в конце концов, любой, у которого нет соответствующего PDF, может быть удален.В то же время у вас все еще есть обновления, поступающие в режиме реального времени.

2. Вы можете проксировать входящие живые обновления и мультиплексировать (?) Их, чтобы они шли как в Core1, так и в Core0.Я построил простой интерфейс прокси и нашел его очень простым.Таким образом, все ваши обновления будут поступать в оба ваших ядра, и вам не нужно будет делать какие-либо «сверки».

3. Наконец, вы можете объединить два ядра: http://wiki.apache.org/solr/MergingSolrIndexes#Merging_Through_CoreAdmin Я действительно не знаю, что происходит, если у вас есть два документа с одинаковым идентификатором или если документ не существует в одном ядре, но существует в другом ... Я предполагаю, что это все аддитивный процесс, но выЯ хотел бы покопаться в этом.

Мне нравится слышать, как это происходит!