Когда поиску нужен сервер
Браузерный поиск уже умеет загружать данные по требованию, выполнять запросы в Worker и работать с версиями индекса. Теперь нужно решить, подходит ли это устройство будущей библиотеке. Само число «двадцать тысяч страниц» ещё не даёт ответа: важны объём текстов, разнообразие словаря, устройства посетителей и требования к обновлению.
В этом уроке подготовим сравнение вариантов и критерии перехода к серверному сервису. Результатом будет объяснимое архитектурное решение, а не правило «после определённого количества файлов всегда нужен сервер».
Что получает браузер
В нашей текущей реализации устройство скачивает публичные документы и строит структуру Map. Даже если выводится десять карточек, локальному алгоритму нужен значительно больший корпус. Это первая существенная стоимость браузерного варианта.
Можно сократить данные: оставить заголовки, описания и компактный предварительно построенный индекс. Но тогда поиск по полному тексту и построение фрагментов потребуют другого решения. Уменьшение файла часто означает изменение возможностей, а не бесплатное сохранение всего поведения.
Рассмотрим расчёт для планирования. Если средняя запись занимает около двух килобайт, двадцать тысяч записей дают десятки мегабайт до учёта словаря и служебной структуры. Это приблизительная модель бюджета, не измеренный размер ProfessorWeb.
Сжатие в сети уменьшает передачу, но после загрузки строки и объекты снова занимают память. JSON, Map, нормализованные значения и копии при обмене сообщениями имеют разные накладные расходы. Поэтому размер скачанного файла нельзя объявлять полной памятью поиска.
Несколько наблюдений вместо одного числа
Для сравнения сохраняйте версию данных, устройство, браузер и режим запуска. Холодная первая выдача включает загрузку и подготовку; повторная — в основном запрос и отображение. Их следует показывать отдельно.
Нужны размер переданного файла, время построения, время типичных запросов и полное ожидание карточек. Дополнительно полезно наблюдать отзывчивость ввода и прокрутки. Число миллисекунд внутри Worker не описывает все действия страницы.
Для длинных серий запросов можно рассмотреть распределение задержек. Среднее скрывает редкие тяжёлые случаи. Но процентиль по нескольким случайным измерениям тоже создаёт ложную точность: сначала подготовьте достаточный повторяемый набор и условия.
Не сравнивайте быстрый настольный компьютер с мобильным устройством как две версии алгоритма. Меняются сразу несколько условий. Полезнее сначала сравнить реализации на одном окружении, а потом проверить различия устройств.
Ограничение времени определяется задачей сайта и наблюдением за интерфейсом. Мы не назначаем универсальный норматив заранее. Пользовательское ожидание подсказки может отличаться от ожидания сложного поиска по всей библиотеке.
Серверный вариант
При серверном поиске браузер передаёт запрос и получает небольшую страницу результатов. Полный индекс хранится отдельно. Контентные страницы при этом могут оставаться статическими: изменение устройства поиска не требует переноса всех материалов в CMS.
У сервера появляется постоянная ответственность: доступность процесса, обновление данных, ограничения запросов, наблюдение и стоимость сопровождения. Экономия браузерной памяти не означает исчезновение ресурсов, а переносит их в другое место.
Сеть участвует в каждом запросе. Для медленного соединения серверная операция может быть быстрее по вычислению, но дольше по полному ожиданию. Полезно сравнивать и холодную загрузку браузерного индекса, и серию коротких серверных обращений.
Публичный сервис получает пользовательские запросы. Это меняет политику журналирования: фразы могут содержать адреса, имена или другие личные сведения. Не обязательно сохранять каждую строку полностью ради оценки доступности.
Готовый движок может предоставить дополнительные анализаторы, управление релевантностью и векторный поиск. Но его результат всё равно оценивается нашим набором задач. Перенос на популярный инструмент не является самостоятельным доказательством улучшения.
Таблица решения
Заполните такую таблицу для своей библиотеки. В последней колонке записывается фактическое ограничение или наблюдение, а не заранее ожидаемый победитель.
| Критерий | Браузерный индекс | Поисковый сервис | Что проверить |
|---|---|---|---|
| Первая выдача | Загрузка и подготовка корпуса | Сеть и серверный запрос | Полное ожидание на целевых устройствах |
| Повторный запрос | Локальное вычисление | Новое обращение к сервису | Типичные и тяжёлые формулировки |
| Обновление | Новый файл и версия сессии | Обновление серверного индекса | Допустимая задержка свежести |
| Память клиента | Корпус и структуры поиска | Карточки и интерфейс | Размер и поведение устройства |
| Сопровождение | Статическая публикация | Процесс, ресурсы и API | Возможности команды и хостинга |
| Закрытые данные | Нельзя передавать весь закрытый корпус | Можно проверять права до ответа | Модель доступа |
Наш учебный корпус публичен, поэтому строка о правах показывает границу архитектуры, а не новую задачу текущего сайта. Скрытие документа фильтром браузера не защищает уже переданный текст.
Если браузерная версия соответствует требованиям, её можно сохранить. При этом серверные уроки полезны как отдельный вариант и объяснение перехода. В учебной серии мы продолжим к сервису, чтобы показать обе архитектуры на одних данных.
Как избежать ложного сравнения
Сохраняйте одинаковый набор документов и запросов. Если сервер получает только заголовки, а браузер ищет во всём тексте, различие результата связано не только с устройством выполнения. Аналогично, разные веса и синонимы меняют качество.
Разделяйте наблюдения о нагрузке и релевантности. Синтетическое размножение шести материалов до двадцати тысяч помогает исследовать память, но создаёт множество одинаковых ответов. Такой корпус нельзя выдавать за проверку полезности настоящей большой библиотеки.
Результаты готового движка могут иметь другой смысл общего счётчика и иной предел выдачи. Их нужно отразить в контракте интерфейса, а не переименовать поля без объяснения. Это станет отдельной частью следующего урока.
Сервис также может быть недоступен. Для контентного сайта полезно сохранить каталог и ясное сообщение об ошибке поиска. Не нужно делать загрузку всей статьи зависимой от здоровья поискового API.
Переход по частям
Сначала подготовим отдельный индекс на прежних документах и проверим его напрямую. Затем добавим адаптер между браузером и движком. Только после этого интерфейс сможет получать результаты нового типа.
Постоянные URL остаются в документах. Никакая миграция поисковой структуры не должна переименовать старые уроки. Экспортёр и реестр адресов становятся общим источником для обоих вариантов.
Сохраните браузерную контрольную версию как исходную точку сравнения. Она помогает объяснить, что изменилось в результатах и стоимости. Это не обязательный аварийный запас полного корпуса для каждого посетителя: автоматический запасной поиск нужно проектировать отдельно.
Теперь переход к серверу имеет конкретное обоснование и понятные последствия. Следующий урок создаст индекс Meilisearch, дождётся завершения его задач и рассмотрит ответ HTTP API на знакомых запросах.