Как оптимизировать «текстовый поиск» для инвертированного индекса и реляционной базы данных? [закрыто]

Закрыто. Этот вопрос должен быть более целенаправленным. В настоящее время ответы не принимаются.

Хотите улучшить этот вопрос?Обновите вопрос, чтобы он был сосредоточен только на одной проблеме, отредактировав этот пост.

Закрыто 2 года назад.

Update 2015-10-15

Еще в 2012 году я создавал личное онлайн-приложение и действительно хотел изобрести велосипед, потому что по своей природе я любопытен, для целей обучения и улучшения своих навыков алгоритмов и архитектуры. Я мог бы использовать apache lucene и другие, однако, как я уже упоминал, я решил создать свою собственную мини-поисковую систему.

Вопрос:Значит, нет никакого способа улучшить эту архитектуру, кроме как с помощью доступных сервисов, таких как elasticsearch, lucene и другие?

Исходный вопрос

Я разрабатываю веб-приложение, в котором пользователи ищут определенные заголовки (скажем, например: книга x, книга y и т. д.), данные которых находятся в реляционной базе данных (MySQL).

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

Я разработал свой собственный мини-поисковик со следующей архитектурой:
Architecture diagram
Вот как это работает:

а) Пользователь ищет имя записи
б) Система проверяет, с какого символа начинается запрос , проверяет, есть ли запрос: получить запись. Если нет, добавьте его и получите все совпадающие записи из базы данных двумя способами:
- Либо запрос уже есть в таблице «Запросы» (которая является своего рода таблицей истории), таким образом, получая запись на основе идентификаторов (быстрая производительность)
- Или, в противном случае, используя оператор Mysql LIKE %%для получения записей/идентификаторов (также сохраните используемый пользователем запрос в таблице истории запросов вместе с идентификаторами, с которыми он сопоставляется).
  --> Затем он добавляет записи и их идентификаторы в кеш и только идентификаторы в карту инвертированного индекса.
c) результаты возвращаются в пользовательский интерфейс

Система работает нормально, однако у меня есть двеосновные проблемы, для которых я не смог найти подходящее решение (пытался в течение последнего месяца) :

Первая проблема:
если вы проверите пункт (b), случай, когда запрос «история» не найден, и он должен использовать оператор Like %%: этот процесс становится Потребуется время, когда запрос соответствует многочисленным записям в базе данных (вместо одной или двух):

Получение записей из Mysql займет некоторое время (поэтому я использовал ИНДЕКСЫ для определенных столбцов)
Затем время для сохранения истории запросов
Затем время для добавления записей/идентификаторов в кеш и инвертированные карты индексов

Вторая проблема:
Приложение позволяет пользователям добавлять себе новые записи, которые могут немедленноиспользоваться другими пользователями, вошедшими в приложение to.
Однако для этого необходимо обновить перевернутую индексную карту и «запросы» таблицы, чтобы в случае, если какой-либо старый запрос соответствовал новому слову. Например, если добавляется новаязапись "woodX", старый запрос "wood" по-прежнему сопоставляется с ней. Итак, чтобы повторно привязать запрос "wood" к этой новой записи, вот что я сейчас делаю:

новая запись "woodX" добавляется в таблицу "records"
, затем я запускаю Like Оператор %%, чтобы увидеть, какой уже существующийзапрос в таблице «запросы» сопоставляется с этой записью (например, «дерево»), затем добавьте этот запрос с новым идентификатором записи в качестве новой строки: [дерево, новый идентификатор].
Затем в памяти обновите значение ключа "дерево" карты инвертированного индекса (то есть список), добавив новый идентификатор записи в этот список.

--> Таким образом, теперь, если удаленный пользователь ищет "дерево", он получит из памяти : дерево и деревоX

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

Что я думаюсделать, чтобы решить эту проблему со временем, так это вернуть желаемые результаты пользователю сначала, а затем позволить приложению POST ajax] с необходимыми данными для выполнения всех этих задач UPDATE. Но я не уверен, что это плохая практика или непрофессиональный подход?
Итак, в течение последнего месяца (чуть больше) я пытался придумать лучшую оптимизацию/модификацию/обновление для этой архитектуры, но я не эксперт в области поиска документов (на самом деле это моя первая когда-либо созданная мини-поисковая система).

Я был бы признателен за любые отзывы или рекомендации о том, что мне нужно сделать, чтобы реализовать такую архитектуру.
Заранее спасибо.

PS:

Это j2ee-приложение, использующее сервлеты.
Я использую MySQL innodb (поэтому я не могу использовать опцию полнотекстового поиска)

задан shadesco 15 October 2015 в 22:08

0 ответов

Другие вопросы по тегам:

architecture search-engine text-search inverted-index

Как оптимизировать «текстовый поиск» для инвертированного индекса и реляционной базы данных? [закрыто]

0 ответов

Похожие вопросы: