Обновление 2015-10-15
В 2012 году я создавал персональное онлайн-приложение и на самом деле хотел изобретать колесо, потому что любопытно по природе, для обучения и улучшения навыков работы с алгоритмом и архитектурой. Я мог бы использовать apache lucene и других, однако, как я уже говорил, я решил создать свою собственную мини-поисковую систему.
Вопрос: Так ли вообще невозможно улучшить эту архитектуру, за исключением использования доступных сервисов, таких как elasticsearch, lucene и других?
Оригинальный вопрос
Я разрабатываю веб-приложение, в котором пользователи ищут определенные заголовки (скажем, например, book x, book y и т.д.), данные которых находятся в реляционной базе данных (MySQL).
Я следую принципу, что каждая запись, извлеченная из db, кэшируется в памяти, так что приложение имеет меньше вызовов в базе данных.
Я разработал свою собственную мини-поисковую систему со следующей архитектурой:
Вот как это работает:
- a) Пользователь выполняет поиск имени записи
- b) Система проверяет, с какого символа начинается запрос, проверяет, есть ли там запрос: получить запись. Если нет, добавляет его и получает все соответствующие записи из базы данных двумя способами:
- Любой запрос уже существует в таблице "Запросы" (которая является своего рода таблицей истории), таким образом, получается запись на основе идентификаторов (Быстрая производительность)
- Или, в противном случае, используя оператор Mysql LIKE %%, чтобы получить записи/идентификаторы (Также сохраните использованный запрос пользователем в таблице истории Запросы вместе с идентификаторами, которые он сопоставляет).
- > Затем он добавляет записи и их идентификаторы в кеш и только идентификаторы к инвертированной карте индексов.
- Любой запрос уже существует в таблице "Запросы" (которая является своего рода таблицей истории), таким образом, получается запись на основе идентификаторов (Быстрая производительность)
- c) результаты возвращаются в пользовательский интерфейс
Система работает нормально, однако у меня есть основные проблемы Two, что я не смог найти подходящее решение для (пытался за последний месяц):
Первая проблема:
если вы проверяете точку (b), где не найден запрос "история", и он должен использовать оператор Like %%: этот процесс становится time потребляющим, когда запрос соответствует многочисленным записям в базе данных (вместо одного или двух):
- Для получения записей из Mysql потребуется некоторое время (именно поэтому я использовал INDEXES для конкретных столбцов)
- Тогда время для сохранения истории запросов
- Затем время для добавления записей/идентификаторов в кеш и инвертированные карты индексов
Вторая проблема:
Приложение позволяет пользователям добавлять новые записи, которые могут сразу использоваться другими пользователями, зарегистрированными в приложении.
Однако для этого необходимо обновить карту инвертированных индексов и "запросы" таблицы, чтобы в случае, если какой-либо старый запрос соответствует новому слову. Например, если добавлена новая запись "woodX", все же старый запрос "дерево" отображает его. Поэтому, чтобы перехватить запрос "wood" на эту новую запись, вот что я делаю сейчас:
- новая запись "woodX" добавляется в таблицу "records".
- тогда я запустил оператор Like %%, чтобы увидеть, какой уже существующий запрос в таблице "запросы" отображает эту запись (например, "дерево" ), затем добавьте этот запрос с новым идентификатором записи как новую строку: [дерево, новый идентификатор].
- Затем в памяти обновите инвертированный указатель. Введите значение ключа "дерево" (т.е. список), добавив новый идентификатор записи в этот список.
- > Таким образом, теперь, если удаленный пользователь ищет "дерево", он получит из памяти: дерево и дерево X
Проблема здесь также потребление времени. Согласование всех историй запросов (в табличных запросах) с добавленным словом занимает много времени (чем больше совпадающих запросов, тем больше времени). Тогда обновление памяти также занимает много времени.
То, что я считаю мышлением для исправления этой проблемы времени, заключается в том, чтобы вернуть желаемые результаты пользователю first, а затем пусть приложение POST a ajax вызовите необходимые данные для выполнения всех этих задач UPDATE. Но я не уверен, что это плохая практика или непрофессиональный способ делать что-то?
Так что за последний месяц (немного больше) я попытался подумать о лучшей оптимизации/модификации/обновлении для этой архитектуры, но я не эксперт в области поиска документов (на самом деле это моя первая мини-поисковая система, когда-либо построенная).
Я был бы признателен за любые отзывы или рекомендации относительно того, что я должен сделать, чтобы достичь такой архитектуры. Спасибо заранее.
PS:
- Это приложение j2ee, использующее сервлеты.
- Я использую MySQL innodb (поэтому я не могу использовать полнотекстовый поиск)