Поиск текста в базе данных: кэширование записей базы данных в доменной логике V / S с использованием полнотекстового поиска MySQL? - PullRequest
2 голосов
/ 24 ноября 2011

Я разрабатываю многоуровневое веб-приложение. Вкратце: 1001 *

Пользовательский интерфейс: html, javascript и jquery
Доменная логика: Java и сервлеты
Бизнес логика: MySQL

У меня есть большое количество записей в базе данных, содержащих информацию о книгах. Кроме того, приложение будет использоваться многими пользователями одновременно. Я хочу, чтобы пользователи могли вводить "название" книги в текстовое поле поиска произнесите «book1» и отобразите выпадающий список, используя jquery autocomplete .

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

Принимая во внимание твердый дизайн, который лучше (производительность и скорость):

Предварительная загрузка этих записей базы данных в объект кеша в доменной логике и позволяет пользователям искать (запрашивать) их из этого объекта? Или запрос непосредственно из база данных, использующая что-то вроде полнотекстового поиска MySQL?

Если вы используете полнотекстовый поиск MySQL, меня беспокоит то, что многие пользователи одновременно обращаются к базе данных. Что касается предварительной загрузки в объект кеша, я не уверен, если это вообще хорошая практика программного обеспечения, кто-нибудь рекомендует это? Должен я поставил таймер для записей, чтобы они оставались в кэше в памяти?

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

1 Ответ

6 голосов
/ 12 декабря 2011

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

Только на этот раз, поскольку записи не могут быть обновлены (т.е. не изменяемы), я буду использовать только функции кэширования карты удостоверений. Поэтому я буду загружать записи из базы данных в этот объект карты идентификации после запуска сервера. Таким образом, пользователь будет запрашивать их непосредственно с уровня домена, тем самым быстрее и меньше обращаясь к базе данных.

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

UPDATE:
Если вы сталкиваетесь с подобной ситуацией, хорошей идеей является использование индексация MySQL . Я использовал его в столбце «название книги», чтобы ускорить загрузку в объекте кеша, потому что в моем случае объект кеша будет содержать только имена книг, так как при использовании поля поиска в пользовательском интерфейсе пользователь касается только названия книги. PS: другие сведения о книге будут загружаться только тогда, когда пользователь нажимает на название книги в раскрывающемся списке, и в этот момент вы можете захотеть использовать другую карту идентичности, содержащую данные. Причиной этой архитектуры является то, что, по логике говоря, у вас никогда не будет всех книг (с их деталями) из вашей базы данных, которые будут искать (загружать) все пользователи вашего приложения одновременно ... таким образом, чтобы минимизировать память сервера и пропускную способность При первом компромиссе вы загружаете весь столбец названий книг в память для более быстрого поиска всех доступных названий книг НО их детали (т. е. больше места в памяти) будут загружаться только тогда, когда это необходимо пользователю, и будут сохранены в другой идентификационной карте, которая будет использоваться другим пользователем, который ищет ту же книгу с теми же данными. На мой взгляд, это сводит к минимуму использование памяти на сервере и уменьшает количество обращений к базе данных для получения сведений, которые уже были получены другими пользователями ранее.

...