Большое строковое поле настраиваемого анализатора ElasticSearch

Занимаюсь поиском документов. Основная идея заключается в том, что документы читаются (с помощью Tika), а затем добавляются в индекс для создания полнотекстового поиска по документам.

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

IllegalArgumentException[Document contains at least one immense term in field\"<field>\" (whose UTF8 encoding is larger than the max length 32766),

то же, что и в этом потоке: Кодировка UTF8 длиннее максимальной длины 32766

Помимо ограничения фактической строки, передаваемой в ElasticSearch, другим предложением было создать собственный анализатор для этого конкретного поля. Таким образом, я пытаюсь создать один такой анализатор, но, поскольку я новичок в ES, я не могу понять, как это сделать. К сожалению, документация не очень помогает в этом.

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


java analyzer apache-tika
person randyr    schedule 23.08.2016    source источник
comment
Вы в итоге создали анализатор, который работал так, как вы ожидали?   -  person justisb    schedule 22.02.2017
comment
@justis См. ответ ниже.   -  person randyr    schedule 22.02.2017

Ответы (1)


arrow_upward
0
arrow_downward

Это было давно, так что я не все помню, но начнем.

Проблема UTF8 encoding is longer than the max length 32766, с которой я столкнулся, была вызвана установленным флагом. Это привело к тому, что вся строка вообще не анализировалась, и поэтому ElasticSearch рассматривал ее как один термин. Apache Lucene (движок под ElasticSearch) имеет значение 32766 как максимальную длину термина. Если вы дадите один термин длиннее этого, будет выдана эта ошибка.

Написание пользовательского анализируемого файла определенно могло бы решить проблему, но наличия дескриптора анализатора по умолчанию этого было достаточно для моего варианта использования. Установив определенный флаг (sort = false) в нашем собственном коде, я смог снова включить анализатор по умолчанию для строки, которую я отправляю.

Другой опыт

Вы столкнетесь с ошибочными PDF-файлами. Много. Это вызовет проблемы с Apache Tika, такие как Zip bomb ошибки. Они часто вызваны глубоко вложенным XML в PDF.

Также не стоит недооценивать количество PDF-файлов, созданных с помощью OCR. Хотя PDF-файл может нормально выглядеть, фактический текст может быть совершенно бессмысленным. Быстрый способ проверить это - просто скопировать текст из PDF в блокнот и проверить, правильно ли он.

Подготовьте для этого достаточно оперативной памяти. Некоторые отдельные документы могут иногда увеличивать использование ОЗУ программой на 1-2 ГБ. Я не знаю, сколько из этого было на самом деле в употреблении, а не только в ожидании GC.

Выберите, какие файлы вы действительно хотите проанализировать. Например, для синтаксического анализа XML-файлов может быть бесполезно.

Сканирование большего количества документов занимает много времени. Возможно, лучше всего разделить процесс на обновление и индексацию. Таким образом, вы можете ограничить количество документов, сканируемых в день, проверив, был ли документ уже проиндексирован. Если нет, проиндексируйте его. Если он изменился, обновите его. Я обнаружил, что в нашем случае сканирование ~ 80000 документов заняло около 4 часов. Это было сделано с помощью одного процессора и около 2 ГБ оперативной памяти.

Надеюсь, это помогло хоть немного.

person randyr    schedule 22.02.2017