Оптимизация Lucid / Solr для индексации больших текстовых документов

Question

Я пытаюсь проиндексировать около 3 миллионов текстовых документов в solr. Около 1/3 этих файлов - это электронные письма, содержащие от 1 до 5 абзацев текста. В остальных 2/3 файлах есть только несколько слов в предложениях.

Lucid / Solr требуется почти 1 час, чтобы полностью проиндексировать весь набор данных, с которыми я работаю. Я пытаюсь найти способы оптимизировать это. Я настроил Lucid / Solr для фиксации только каждых 100 000 файлов, и он индексирует файлы в пакетах по 50 000 файлов одновременно. Память больше не является проблемой, поскольку она постоянно составляет около 1 ГБ памяти из-за пакетной обработки.

Сначала необходимо проиндексировать весь набор данных. Это похоже на унаследованную систему, которую нужно загружать в новую систему, поэтому данные должны быть проиндексированы и должны быть максимально быстрыми, но я не уверен, какие области следует изучить для оптимизации на этот раз.

Я думаю, что, может быть, есть много таких маленьких слов, как ", а, потому что, если, если, ...", которые вызывают много накладных расходов и являются просто "шумовыми" словами. Мне любопытно, если я отрежу их, если это резко ускорит время индексации. Некоторое время я просматривал документы Lucid, но не могу найти способ указать, какие слова не индексировать. Я наткнулся на термин «стоп-лист», но мимоходом не увидел ничего, кроме ссылки на него.

Существуют ли другие способы ускорения индексации или я просто застрял с индексированием в 1 час?

Answer 1

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

1. Используйте GZipOutput / InputStream и Bse64Output / InputStream для сжатия большого текста.Это может уменьшить размер текста примерно на 85%, это может сократить время на передачу запроса / ответа.

2. Чтобы уменьшить использование памяти на стороне клиента:

   2.1 Мы используем потоковый API(GSon stream или XML Stax) для чтения документа по одному.

   2.2 Определите пользовательский тип поля Solr: FileTextField, который принимает FileHolder в качестве значения.FileTextField в конечном итоге передаст читатель Lucene.Lucene будет использовать программу чтения для чтения содержимого и добавления в индекс.

   2.3 Если текстовое поле слишком большое, сначала распакуйте его во временный файл, создайте экземпляр FileHolder, а затем установите экземпляр FileHolder в качестве значения поля.

Answer 2

Из вашего запроса видно, что время индексации действительно важно для вашего приложения. Solr - отличная поисковая система, однако, если вам нужно сверхбыстрое время индексации, и если это очень важный критерий для вас, вам следует использовать Sphinx Search Engine. Вам не понадобится много времени, чтобы быстро настроить и сравнить результаты с помощью Sphinx.

Могут быть способы (например, тот, который вы упомянули, стоп-слова и т. Д.), Чтобы оптимизировать, однако, что бы вы ни делали в отношении времени индексации, Solr не сможет победить Сфинкса. Я сделал бенчмаркинг сам.

Я тоже очень люблю Solr из-за его простоты использования, его замечательных функций, таких как индексирование N-Gram, гранение, многоядерность, корректоры орфографии и его интеграция с другими продуктами apache и т. Д., Но когда это происходит оптимизированным алгоритмам (будь то размер индекса, время индекса и т. д.) Сфинкс качается !!

Sphinx тоже с открытым исходным кодом. Попробуйте это.