При базе данных свыше 500 000 SKU время отклика сервера (TTFB) на поисковый запрос часто прыгает до 2-3 секунд, что убивает конверсию на 20-30% при каждом лишнем полусекунде ожидания. Сокращение TTFB до приемлемых 200-400 мс требует перехода от стандартных SQL-запросов к специализированным архитектурам индексации.
Проблема Full-Text Search в реляционных БД
Использование оператора LIKE '%запрос%' в MySQL или PostgreSQL на таблицах от 1 млн строк приводит к полному сканированию индекса (Full Table Scan). В реальности это означает, что сервер перебирает каждую строку, нагружая CPU на 90-100%, что раздувает TTFB до 3-5 секунд при высокой нагрузке.
Кейс: переход с обычного поиска по БД на полнотекстовые индексы (Full-Text Index) в PostgreSQL сократил время выполнения запроса с 1.8 сек до 120 мс, но лишь для простых точных совпадений. Как только добавляется морфология или поиск по части слова, производительность снова падает.
Экспертный вывод: реляционные БД не предназначены для поиска. Для проектов с оборотом от 1 млн товаров использование SQL-поиска — это технический долг, который приведет к отказу сервера при первом же всплеске трафика.
Внедрение Elasticsearch и Solr для мгновенного отклика
Перенос поискового индекса в Elasticsearch позволяет достичь TTFB в пределах 50-150 мс даже при базе в 10 млн документов. Это достигается за счет инвертированного индекса, который хранит не сами записи, а карту слов и соответствующих им ID документов.
Сравнение: классический SQL-запрос по трем полям (название, категория, описание) занимает около 800 мс. Аналогичный запрос в Elasticsearch отрабатывает за 40-70 мс. Затраты на внедрение и настройку кластера для среднего e-commerce составляют от 50 000 до 150 000 рублей, но окупаются за счет удержания пользователей.
Экспертный вывод: Elasticsearch — стандарт индустрии. Если ваш бюджет ограничен, начните с Meilisearch; он проще в развертывании и дает сопоставимую скорость на объемах до 2-3 млн записей.
Кэширование результатов и денормализация данных
Самый быстрый запрос — тот, который не выполняется. Внедрение Redis для кэширования топ-1000 самых популярных поисковых запросов позволяет отдавать страницу результатов за 30-50 мс. Статистика показывает, что 20% запросов генерируют 80% трафика.
Важный нюанс: денормализация данных. Вместо того чтобы собирать цену, остаток и рейтинг из пяти разных таблиц при каждом поиске, создайте одну плоскую таблицу (или документ в NoSQL), содержащую все данные для выдачи. Это сокращает количество JOIN-операций с 5-7 до нуля.
Экспертный вывод: используйте Redis с TTL (временем жизни) от 1 до 6 часов для популярных запросов. Это снимет до 60% нагрузки с основной БД в пиковые часы.
Оптимизация пагинации и Offset-проблема
Традиционная пагинация через OFFSET (например, LIMIT 20 OFFSET 10000) заставляет БД прочитать все предыдущие 10 000 строк, прежде чем отдать нужные 20. На глубоких страницах поиска TTFB растет экспоненциально: с 200 мс на первой странице до 2.5 сек на сотой.
Решение: переход на курсорную пагинация (Keyset Pagination), где запрос идет по условию `WHERE id > last_seen_id`. Это фиксирует время отклика на уровне 100-200 мс независимо от глубины просмотра.
Экспертный вывод: забудьте про классический Offset для больших каталогов. Курсорная пагинация — единственный способ сохранить скорость на длинных хвостах выдачи, что критично для SEO-индексации.
Асинхронная обработка и оптимизация фронтенда
Чтобы пользователь не видел белый экран, пока сервер считает результаты, используйте стратегию Skeleton Screens и асинхронную подгрузку контента. Это не уменьшает физический TTFB, но снижает воспринимаемое время загрузки (Perceived Performance) на 40-50%.
Пример: вместо ожидания полной генерации HTML-страницы, сервер отдает пустой каркас за 100 мс, а данные подтягиваются через API. Это позволяет параллельно реализовать сравнение алгоритмов ранжирования внутреннего поиска: поиск по ключевым словам vs семантический поиск, не перегружая основной поток рендеринга.
Экспертный вывод: разделяйте доставку структуры страницы и данных. Это позволяет избежать таймаутов шлюза (504 Gateway Timeout) при очень тяжелых запросах.
Вывод
Для сокращения TTFB на больших БД начните с внедрения Redis для кэширования популярных запросов и отказа от OFFSET в пользу курсоров — это даст быстрый эффект без смены архитектуры. Однако для систем с базой >500к товаров единственным надежным решением является перенос поиска в Elasticsearch или Meilisearch. Избегайте попыток «дотюнить» SQL-запросы через индексы на огромных объемах — это путь в никуда, который закончится падением сервера при первой акции или распродаже.