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

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

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

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

В настоящее время мы рассматриваем следующие подходы:

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

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


bigdata indexing clustered-index solr
person gstathis    schedule 10.05.2011    source источник
comment
как парень с несколькими многомиллионными индексами документов, я рассматривал подход, очень похожий на ваш вариант Use CoreAdmin:. Я думаю, ты на правильном пути.   -  person Frank Farmer    schedule 10.05.2011
comment
Спасибо, Фрэнк. Приятно знать, что я не совсем в отключке.   -  person gstathis    schedule 11.05.2011
comment
Да... CoreAdmin - довольно разумный подход.   -  person Brian    schedule 19.05.2011

Ответы (1)


arrow_upward
2
arrow_downward

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

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

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

В итоге мы остановились на очень простой кластерной установке master/slave.

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

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

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

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

person Jason Palmer    schedule 22.05.2011
comment
Эй, Джейсон, большое спасибо, что поделился этим. У нас в несколько раз больше документов, поэтому мы начали сегментирование, чтобы поддерживать производительность. Мы также рассматриваем подход ведущий/ведомый для разделения r/w; наша первая задача — разрешить повторную индексацию при принятии новых обновлений. Наш индекс обновляется постоянно, иногда несколько раз в минуту, и нам действительно нужно, чтобы эти обновления были доступны для клиентов в течение нескольких минут, даже во время серьезной переиндексации. Таким образом, мы находимся в середине реализации подхода CoreAdmin прямо сейчас по необходимости. - person gstathis; 23.05.2011