Как хранить данные при работе с Apache Lucene?

Question

[My1Name]

Допустим есть сайт, где у каждого пользователя есть своя страница и раздел "О себе". Необходимо организовать полнотекстовый поиск пользователей по этому разделу...

Вопрос: Нужно ли создавать отдельные файлы "О себе", если мы добавляем эту информацию в индекс Lucene? Или достаточно добавить в индекс и никакие вспомогательные файлы (для хранения текстовой информации) не нужны?

Comments

[d'Ivan]

Почему выбор пал на Apache Lucene (сам полнотекстовый движок), а не на Elasticsearch (полное решение)?

[My1Name]

Иерокопус Таманский, Lucene легче и проще для понимания. Это во-первых. А во-вторых это бесплатная библиотека.

[d'Ivan]

My1Name, тогда нужно ознакомиться с документацией. Ведь это уже сделано, не так ли?

[My1Name]

Иерокопус Таманский,
"Lucene разработан для высокоскоростного индексирования с низкими затратами, благодаря чему встроенные токенизаторы и фильтры могут быстро обрабатывать гигабайты текста, используя только мегабайты памяти".
https://www.toptal.com/database/full-text-search-o...

[d'Ivan]

My1Name, это и не оспаривалось.

Answer 1

[mayton2019]

Apache Lucene вообще не знает что такое файлы. Он оперирует понятием документ
(org.apache.lucene.document.Document) и поля документа (Field, StringField e.t.c).
Поля могут быть Stored (просто храниться) или Indexed (участовать в генерации текстового
индекса).

Поэтому посмотри учебные примереы с Lucene и попробуй перезадать вопрос по другому.

Comments

[My1Name]

Поля могут быть Stored (просто храниться) или Indexed (участовать в генерации текстового
индекса)

В этом и есть суть вопроса: Нужно ли создавать отдельные файлы, чтоб не нагружать Lucene? Ведь он (оно) может хранить документ целиком, а может хранить только индексы к соответствующему документу... В чём разница и как это отражается на производительности?

Если поискать ответ в интернете, то основная масса, в том числе те, кто использует Elasticsearch, пишут только таблицу индексов в дополнение к базе данных. На это наверно есть какие-то причины?

[mayton2019]

My1Name, показывай код.

[My1Name]

mayton2019, https://www.tutorialspoint.com/lucene/lucene_adddo...

По ссылке пример добавления 10 файлов в индекс, при этом файлы существуют отдельно.

[mayton2019]

My1Name, документ является минимальной гранулой которой Lucene тебе отдаст результат поисковой
операции. Допустим ты решил индексировать библию. Она имеет примерно такую структуру.

Библия -> Заветы (ветхий/новый) -> Книги (Исход, Бытие) -> Главы -> Строки (нумерованые)

Что здесь сделать документом? Ответ - то что ты хочешь получить в ScoreDoc. И он будет
содержать набор документов с рейтингом поиска. Если ты хочешь хранть в ДОКУМЕНТЕ вспомогательные файлы
то они будут участниками процесса поиска. Если не хранишь - не будут. Это и есть ответ на твой
вопрос.

По поводу твоей ссылки. Я не смотрел. Не интересно.

Я тебя просил дать твой макет на котором ты тестируешь свой код. Если он есть - мы можем продолжать
обсуждение. Ссылки на туториалы приводить не надо. Я не занимаюсь процессом обучения. Я могу просто ответить на вопрос. Но комментировать уроки я не буду. Не моя задача.

[My1Name]

Я могу просто ответить на вопрос

Я так и понял... Ты ничерта не знаешь, но хочешь выглядеть умным.

Если ты хочешь хранть в ДОКУМЕНТЕ вспомогательные файлы
то они будут участниками процесса поиска. Если не хранишь - не будут. Это и есть ответ на твой вопрос.

[mayton2019]

My1Name, как там говорили древние... Quot licet iovi....

[My1Name]

mayton2019, не интересно.

Answer 2

[d'Ivan]

Допустим есть сайт

Что из себя представляет страница на сайте? Документ HTML. У документа есть путь - как часть адреса URL.

Есть заголовок (header)
<title>Example Domain</title>

Есть тело документа (body)

<div>
    <h1>Example Domain</h1>
    <p>This domain is for use in illustrative examples in documents. You may use this
    domain in literature without prior coordination or asking for permission.</p>
    <p><a href="https://www.iana.org/domains/example">More information...</a></p>
</div>

Если я верно понял вопрос, то необходимо уметь искать по заголовку и телу страницы. Поскольку AL производит поиск по чистому тексту, а не HTML, то в понятиях AL нужно индексировать документ, состоящий из:

1. идентификатор страницы
   
2. заголовок
   
3. тело
   
4. дата создания
   
5. автор
   
6. метки
   

Необходимо обеспечить синхронизацию страниц в AL: при создании или изменении любой страницы сайта проиндексировать её в AL в качестве документа с заданными полями.

Comments

[My1Name]

Что из себя представляет страница на сайте?

На Спринге + Thymeleaf, это набор разных документов и методов с которых собирается (компилируется) страница по заданному адресу.

[d'Ivan]

My1Name, не важно какой фреймворк используется для сборки HTML.
Для AL нужно передавать чистый текст, без разметки. Документ AL - это не файл HTML, а экземпляр класса библиотеки и должен индексироваться при каждом изменении страницы в обработчике страницы.

[d'Ivan]

Такчто

никакие вспомогательные файлы (для хранения текстовой информации) не нужны

Индексирование может быть выполнено налету

[My1Name]

Иерокопус Таманский, на индексацию передаётся String, при этом он может быть сохранён вместе с построением индексов в AL, в отдельном файле или в БД.

Можно выбирать, что Lucene будет возвращать в результате поиска. Например:

Document.add(new TextField("body", text, Field.Story.NO));

В таком случае будут сохраняться только индексы; AL не вернёт сам документ. А если указать Field.Story.YES то в результате поиска будет возвращаться и text. То есть, в первом случае нужно хранить ссылку на файл, как это делают обычно с БД. А во втором случае, файл храниться в виде текстового поля в Lucene и файл в общем-то не нужен.

[d'Ivan]

My1Name, страницы сайта статические, в виде файлов? Или создаются налету из шаблона?
Если второе, то Field.Store.YES

[My1Name]

Иерокопус Таманский, интересная логика... Тут вопрос должен быть другой: Как объё данных влияет на скорость чтения индексов и выдачи объектов AL в результате поиска?

Любой программист, работающий с базами данных, скажет приблизительно следующее: Чем больше таблица, тем медленнее происходит поиск и выборка полей в любой БД. Поэтому при проектировании больших таблиц, основной тип данных для объёмных (больших) данных - это ссылка на файл. Однако, в отличие от обычных БД, Lucene имеет какую-то свою систему индексов и хранения. Поэтому и возник вопрос: Нужно ли создавать отдельно (текстовые) файлы? Как хранить данные при работе с Apache Lucene?

[d'Ivan]

Нужно ли создавать отдельно (текстовые) файлы?

если они изначально отсутствуют, то не нужно создавать, поскольку AL умеет хранить в своём хранилище документов. Главное, иметь идентификатор страницы у каждого документа (указатель).
Исходя из предложения,
что исходное поле в формате HTML, я предложил Field.Store.YES, поскольку оно будет храниться в чистом тексте и доступно, в том числе, и для целей верификации соответствия версии страницы, находящейся в СУБД.
Так что вопрос о поле Field.Store состоит в том какая архитектура у приложения.

[d'Ivan]

Как объё данных влияет на скорость чтения индексов и выдачи объектов AL в результате поиска?

О каком типе сайта и каком объёме документов идёт речь? Пока не приведены никакие данные, чтобы начинать рассуждения о производительности работы AL.