Solr подходит к повторной индексации большого массива документов - PullRequest
Новая
       19

Solr подходит к повторной индексации большого массива документов

5 голосов
/ 10 мая 2011

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

  • Новые функции введены вокруг поиск существующего корпуса, который требовать дополнительные поля схемы что мы не всегда можем предвидеть в заранее
  • Корпус индексируется через несколько Осколки. Когда он проходит мимо определенного порог, нам нужно создать больше осколки и перебалансовые документы равномерно по всем из них (что SolrCloud пока не похоже поддержка).

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

Подходы, которые мы рассматриваем на данный момент:

  • Создайте новую группу осколков и партия переиндексировать там, пока старый кластер по-прежнему доступен для поиск. Новые документы, которые не являются часть переиндексированной партии отправлены и старый кластер и новый кластер. Когда будете готовы переключиться, укажите балансировщик нагрузки на новый кластер.
  • Использование CoreAdmin: порождает новое ядро осколок и отправить переиндексированную партию на новые ядра. Новые документы, которые не являются частью переиндексированной партии отправляются как на старые ядра и новые ядра. Когда будешь готов переключиться, использовать CoreAdmin для динамического обмена ядра.

Мы были бы признательны, если бы люди могли подтвердить или пробить дыры в одном или во всех этих подходах. Является ли один более подходящим, чем другой? Или мы полностью выключены? Заранее спасибо.

1 Ответ

2 голосов
/ 22 мая 2011

Это может не относиться к вам, ребята, но я предложу свой подход к этой проблеме.

Наша установка Solr в настоящее время является одним ядром. В будущем мы будем добавлять больше ядер, но подавляющее большинство данных записывается в одно ядро.

Имея это в виду, шардинг не был действительно применим к нам. Я посмотрел на распределенные поиски - разрезание данных и запуск их на разных серверах. Мне казалось, что это слишком усложняло ситуацию. Это усложнит резервное копирование / восстановление, и вы потеряете некоторые функции при выполнении распределенного поиска.

Подход, который мы в итоге сделали, заключался в очень простой кластерной установке master / slave.

Каждый кластер состоит из базы данных master и двух подчиненных solr, которые сбалансированы по нагрузке. Все новые данные записываются в базу данных master, а ведомые устройства настроены на синхронизацию новых данных каждые 5 минут. В нормальных условиях это очень хорошая настройка. Операции переиндексации выполняются на ведущем устройстве, и пока это происходит, ведомые устройства все еще могут считываться.

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

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

Надеюсь, это поможет!

...