Можно ли использовать Elasticsearch для поиска в файлах?

Question

[My1Name]

Всем доброго времени суток. Подскажите пожалуйста, можно ли использовать Elasticsearch для поиска в файлах? Например, у меня есть динамический файл размером 100Mb с текстовым содержанием следующего вида:

<!--START-block-1-->
тут какой-то текст в котором нужно искать
<!--END-block-1-->
<!--START-block-2-->
тут какой-то текст в котором нужно искать
<!--END-block-2-->

Я знаю как осуществить поиск в таком файле с помощью JAVA (core) и вернуть соответствующий текстовый блок при 100% совпадении искомого слова или словосочетания. Однако, возможности Elasticsearch гораздо более привлекательны по описаниям в интернете... Он может игнорировать ошибки в словах, и даже искать транслитерацию. Можно ли использовать Elasticsearch для такой задачи? И если можно, то как его подключить и настроить (желательно, через добавление jar-файла в Spring-boot проект и дальнейшей MVC сборки)?

Comments

[d'Ivan]

Что за процесс пишет в файл? Есть ли его исходники?

[My1Name]

Иерокопус Таманский, Обычная запись/перезапись в файл. Исходники можете найти в интернете.

[mayton2019]

Несколько наблюдений.
1) Elasticsearch не ищет в файлах сразу. Он строит текстовый индекс. Это займет какое-то
время. Тоесть холодный старт для приложения будет скорее всего неприятен.
2) Обычно Elasticsearch оперирует такими единицами как документ. Документ также
является содержанием ResultSet. Поэтому здесь надо поставить
вопрос что будет документом в случае с парсингом этой простыни? Может 1 строка. Может блок
строк. Может всегда 1 главный документ но со ссылкой на номер строки (здесь надо уточнить работает
ли это).
3) Elasticsearch любит фильтрацию. Возможно не стоит индексировать "START-block" чтоб не зашумлять индекс.

[d'Ivan]

My1Name,

Обычная запись/перезапись в файл. Исходники можете найти в интернете.

Мне не нужно было знать как пишутся данные в файл, а только какой процесс занимается записью таких блоков. С виду выглядит как XML/HTML. Поэтому если запись в этот файл подконтрольна и, скажем, выполняется вашим кодом на Java, тогда можно предложить другое решение для индексации текста. Поэтому и уточняю перед тем, как давать свой ответ.

[My1Name]

Иерокопус Таманский,

если запись в этот файл подконтрольна

- Да. Запись подконтрольна.

можно предложить другое решение для индексации текста

- Какое? Когда я написал "Я знаю как осуществить поиск в таком файле с помощью JAVA", я подразумевал поиск в стриме. Проблема в том, что так можно искать только точные совпадения. То есть ошибки в параметрах поиска и тем более транслитерация - недопустимы. Иначе нужно писать свой "поисковый движок"...

[d'Ivan]

у меня есть динамический файл размером 100Mb

Какова логика обновлений в файле и как часто пишутся изменения?
Дописывается ли файл в конец или перезаписывается заново?

[My1Name]

Иерокопус Таманский, В реальности файл гораздо меньше. Он где-то 10Мб (Max) и перезаписывается подобно стеку: Первый зашёл - первый ушёл. Дозапись в конец файла с фиксированным количеством текстовых блоков.

[сергей кузьмин]

My1Name, если можете в основной задаче заменить textfile логгер на lucene или elk
https://github.com/internetitem/logback-elasticsea...
то зад реш

[rPman]

My1Name,

Первый зашёл - первый ушёл. Дозапись в конец файла с фиксированным количеством текстовых блоков.

дозапись это простая операция, не затрагивает остальной файл, но что означает первый ушел? удаление первых записей? с точки зрения текстового файла это его полная перезапись

Так как ты ведешь запись самостоятельно, это твой код, настоятельно рекомендую изменить бизнеслогику этого процесса. Самое простое (минимизирует изменения в коде) - создавай несколько файлов, по одному на блок, в этом случае простое добавление и тем более блока не потребует переиндексации ВСЕХ данных. При переиндексации необходимо будет хранить дату последней индексации и сравнивать ее с датой модификации каждого файла, пропуская не изменившиеся.

[My1Name]

rPman,

дозапись это простая операция, не затрагивает остальной файл, но что означает первый ушел?

Это значит, что объём индексированных данных, по которым необходимо осуществлять полнотекстовый поиск - фиксированного размера (например: 100 текстовых блоков +- одинаковой длины. Типа "TOP-100"). И тема закрыта. Решение найдено в другой ветке комментариев... Ответ: Apache Lucene решает такие задачи без особых проблем и затрат ресурсов.

настоятельно рекомендую изменить бизнеслогику этого процесса

В этом нет необходимости.

Answer 1

[d'Ivan]

Можно ли использовать Elasticsearch для поиска в файлах?

Elasticsearch не предназначен для индексирования файлов непосредственно. Поскольку используется SDK для работы через API, при создании документов с текстом. Таким образом, они (документы) индексируются и доступны для последующего поиска.
Кроме того, Elasticsearch плохо работает в случае частых обновлений, поскольку ему надо часто обновлять кэш, и это приводит к дополнительным накладным расходам. Короче, Elasticsearch - это перебор для данной задачи.

Не понятно зачем используется файл, когда можно использовать СУБД. Например, RediSearch (из Redis Stack) - позволяет производить полнотекстовый поиск, включая русский.
Так, вместо большого файла приложение должно работать с СУБД, храня единицы документов (то, что в вашей терминологии называется блоком).

В реальности файл гораздо меньше. Он где-то 10Мб (Max) и перезаписывается подобно стеку: Первый зашёл - первый ушёл. Дозапись в конец файла с фиксированным количеством текстовых блоков.

Что касается очереди FIFO, то она поддерживается в Redis. В ней можно хранить идентификаторы документов, подлежащих обработке.

Comments

[My1Name]

Спасибо. Интересно. Но неужели нет ничего подобного для работы непосредственно с файлами? - Устанавливать СУБД, а сверху ещё и поисковый движок для работы с небольшими данными, звучит как-то абсурдно. Они займут больше места, чем весь проект.

p.s. Я думал Elasticsearch можно добавить в виде .jar файла и использовать как хороший парсер текста.

[d'Ivan]

p.s. Я думал Elasticsearch можно добавить в виде .jar файла и использовать как хороший парсер текста.

Apache Lucene?

[d'Ivan]

My1Name,

Устанавливать СУБД, а сверху ещё и поисковый движок для работы с небольшими данными, звучит как-то абсурдно.

ну так, Elasticsearch ещё больший перебор, чем просто Redis Stack.

Если хочется всё самому и неконвенционально, тогда подключать Apache Lucene, и в путь!

[My1Name]

Иерокопус Таманский, Apache Lucene похоже то, что надо.. Читаю на habr.

[d'Ivan]

My1Name, получилось ли с AL? Или решили таки по-другому?

[My1Name]

Иерокопус Таманский, Да, получилось. Ещё раз - спасибо. Там в принципе нет ничего сложного. Код нормально читаем и применим для разных проектов. Однако, я пока что отодвинул задуманное на потом...

[My1Name]

Иерокопус Таманский, по ссылке в комментариях есть кусок кода, который можно "поюзать":

Почему поиск FuzzyQuery (Apache Lucene) ничего не возвращает?

Answer 2

[Dimonchik]

можно разумеется
https://www.elastic.co/webinars/uploading-a-file-i...
https://hashnode.com/post/data-visualizer-to-uploa...
https://stackoverflow.com/questions/68326455/extra...

другое дело, что Ваша задача может решаться и более простыми средствами
https://www.postgresql.org/docs/current/textsearch.html
https://dev.mysql.com/doc/refman/8.0/en/fulltext-s...

Comments

[My1Name]

В Elasticsearch нужно загружать файл для создания индексов? - У меня динамический файл (не 100, а где-то 10Mb в реальности). Он постоянно видоизменяется (перезаписывается как стэк, типа LinkedList). В общем с Elasticsearch ничего не понятно... Реляционные БД, я думаю тоже не подходят для такой задачи.

[Kentavr16]

My1Name, я тоже подумал про бд. , услышав о файле 10мб. Скорость поиска в тексте наверняка О(n), и это будет не 0.1мс, не говоря уже про удобство поиска.

[My1Name]

Kentavr16,

Скорость поиска в тексте наверняка О(n)

Точный поиск в файле до 10Мб - осуществляется в пределах 1 секунды.

[Kentavr16]

My1Name, в скл-подобной бд - в сотни раз быстрее. Тем более совет выше вам предлагает вообще использовать поиск по индексированному тексту, из mysql а не переводить проект в формат другой бд. Я не "учу", вам виднее само собой.

[My1Name]

Kentavr16, Спасибо. Мне не нравится идея - использовать БД для работы с небольшими файлами. Особенно если ещё ставить "сверху" поисковый движок... Я думаю для таких задач нужен просто хороший парсер. И я пока что остановил свой взор на Apache Lucene.

По поводу

скл-подобной бд - в сотни раз быстрее

- Сомневаюсь. Потому-что перебирая документ по индексам, например через indexOf() основную часть времени забирает чтение файла. Если читать файл не построчно, а как массив байтов, например через readAllBytes() то поиск происходит в оперативной памяти (в стриме). То есть скорость зависит фактически от железа, ну и разумеется от алгоритмов выборки.