Индексирование Lucene с параллельными расширениями

Question

Я бы хотел ускорить индексацию 10 ГБ данных в индекс Lucene.Будет ли TPL хорошим способом сделать это?Нужно ли разбивать данные на куски, а затем каждый поток начнет индексировать куски?

Чтобы обеспечить отзывчивость пользовательского интерфейса, будет ли BackgroundWorker лучшим подходом, или задачей, или чем-то еще?

SOLR уже делает что-то подобное?Или все же стоит написать это самому.

Answer 1

Предполагается, что вы используете Java - у меня был хороший опыт индексирования с использованием нескольких потоков.По моему опыту, индексирование Lucene в основном связано с процессором, поэтому если вы создаете N потоков, вы можете использовать все свои N ядер.

Lucene IndexWriter обрабатывает параллелизм, поэтому вам не нужно об этом беспокоиться.Ваши потоки могут просто вызывать indexWriter.addDocument всякий раз, когда они готовы сделать это.

В одном проекте документы поступили из оператора SELECT из базы данных.Я создал N потоков, и каждый из них взял следующий документ из ResultSet и добавил его в индекс.Поток завершился, когда больше не было строк, и основной поток ожидал CountDownLatch.

Второй проект был немного более сложным.Система «сканировала» набор документов, то есть с самого начала было неясно, сколько документов будет.Поэтому необходимо было поддерживать «очередь» документов, которые уже были обнаружены.И в процессе анализа и индексации этих документов было возможно обнаружить больше документов, которые затем были также добавлены в очередь.Вначале очередь заполнялась исходным / начальным документом.Я создал класс AutoStopThreadPool для управления потоками, вы можете скачать , если хотите.(Пулы потоков JVM должны «добавить» все задачи, а затем «ждать завершения», что не подходит, поскольку обработка задачи может привести к обнаружению новых задач)

Answer 2

Если вы хотите, чтобы несколько потоков писали в один IndexWriter, я бы просто создал один поток, который делает что-то вроде

Parallel.ForEach(docs, d => { writer.Add(d,analyzer) });

Так что .NET имеет дело с разделением данных.

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

Solr по своей сути является многопоточным, поэтому вы будете делать тот же фрагмент, который я дал вам ранее, за исключением того, что вместо непосредственного вызова средства записи вы вызовете свой метод REST / SolrNet.

Как правило, если вы спросите: «Должен ли я использовать Solr или сделать это сам?» ответ почти всегда "использовать Solr". Я не могу представить себе причину, по которой вы захотите сделать это сами, если только ваш jvm не очень плохой или вы действительно ненавидите java.