Зоомагазин: 12 000 SKU в каталоге и поиск, который тормозит на общем хостинге

MAATRIX

Зоомагазин — это не сто товаров, это тысячи. Один и тот же корм существует в пяти вкусах, трёх фасовках и двух формулах — «для стерилизованных» и «обычный». Умножьте на десяток брендов, добавьте наполнители, лакомства, амуницию, товары для аквариумистики — и каталог на 12 000 SKU перестаёт быть чем-то необычным, это нормальная реальность среднего интернет-зоомагазина. Проблема в том, что общий хостинг, на котором сайт запускался с сотней товаров, к такому объёму не готов: поиск и фильтры начинают тормозить именно тогда, когда покупатель уже готов купить. Разберём, почему это происходит и что реально меняет свой сервер.

Откуда в зоомагазине берётся 12 000 SKU

Если считать позиции формально, магазин с виду небольшого ассортимента — условно 40-60 «товарных линеек» — легко разрастается в каталог на порядок больше самой номенклатуры:

• Фасовки. Корм для собак крупных пород обычно продаётся минимум в 3-4 вариантах веса — от пробника до мешка на 15-20 кг. Каждая фасовка — отдельная карточка со своим артикулом, ценой и остатком.
• Вкусы и формулы. «Курица», «ягнёнок», «индейка», «для чувствительного пищеварения», «для стерилизованных», «беззерновой» — у одного бренда таких вариаций может быть больше десятка.
• Возрастные и породные линейки. Щенячий, взрослый, для пожилых животных; отдельно для мелких, средних и крупных пород.
• Размеры и цвета для непродовольственных товаров. Амуниция, лежанки, переноски, одежда для животных — размерная сетка сама по себе умножает число SKU в разы.
• Сопутствующие мелочи. Игрушки, лакомства, витамины, средства от паразитов, наполнители для туалетов в разных объёмах — длинный «хвост» с низкой оборачиваемостью, но большим числом позиций.

В сумме даже не самый крупный магазин упирается в 10-15 тысяч активных SKU, а у сетевых игроков счёт идёт на десятки тысяч. И это ещё без учёта товаров, которые то появляются, то уходят с витрины по сезону.

Пока каталог маленький, любой поиск работает быстро вне зависимости от того, насколько грубо он реализован — таблица на пару сотен строк переберётся за миллисекунды на чём угодно. С ростом каталога в разы возрастает и цена неэффективного запроса, и именно тут проявляются ограничения общего хостинга.

Что реально происходит на общем хостинге при поиске по большому каталогу

Общий (shared) хостинг устроен так, что один физический сервер обслуживает десятки, а то и сотни независимых сайтов. Ваш зоомагазин соседствует с чьим-то блогом, интернет-магазином одежды, визиткой стоматологии — и все они делят один процессор, один пул оперативной памяти под MySQL, один диск. Для статичных страниц это почти незаметно. Для поиска по каталогу на тысячи товаров — заметно очень сильно, и вот почему:

Поиск чаще всего — это LIKE '%запрос%' по таблице товаров. Большинство движков интернет-магазинов из коробки ищут именно так: полнотекстовый индекс либо не настроен, либо плохо работает с русской морфологией («корм» не находит «кормов»). LIKE с маской в начале строки не может использовать обычный индекс — база сканирует таблицу целиком. На 12 000 строк с десятком колонок это уже не «моментально».

У вас нет отдельных ресурсов под пиковую нагрузку. На общем хостинге лимиты CPU и число одновременных процессов PHP жёстко ограничены тарифом — вы видите, что сайт «подвисает», когда одновременно ищут несколько посетителей, а соседний сайт на том же сервере в это время долбит диск бэкапом.

Фильтры множат нагрузку на поиск. Покупатель зоомагазина редко ищет один товар — он комбинирует фильтры: порода, вес, вкус, бренд, цена. Каждый такой фильтр в неоптимизированной схеме — это дополнительный JOIN или WHERE по неиндексированному полю. Простой полнотекстовый поиск превращается в тяжёлый комбинированный запрос, а на общем хостинге у вас нет возможности донастроить конфигурацию базы под такую нагрузку — конфиг общий на весь сервер, и провайдер его менять под один сайт не будет.

Кеширование ограничено или отсутствует. Многие тарифы общего хостинга не дают поставить полноценный кеш результатов (Redis, memcached) — только то, что встроено в CMS, и часто это кеш страниц целиком, а не кеш конкретных поисковых запросов с фильтрами, которых у зоомагазина комбинаторно много.

Результат предсказуем: чем больше товаров в каталоге и чем активнее покупатели фильтруют выдачу, тем чаще поиск «подвисает» на несколько секунд, а в моменты всплеска трафика — на десятки секунд или вовсе отдаёт ошибку тайм-аута.

Во что это обходится бизнесу

Медленный поиск — это не абстрактное неудобство, это точка, где покупатель либо доходит до корзины, либо уходит. У зоомагазина ситуация особая: значительная часть покупок — это не разовое открытие, а повторная покупка того же корма или наполнителя, которую человек делает «на автомате», часто с телефона. Если поиск по бренду и вкусу не выдаёт результат за разумное время, вероятность, что покупатель откроет вкладку конкурента и купит там — велика: он не привязан к вам эмоционально, ему нужен конкретный товар здесь и сейчас.

Отдельная беда — фильтры по параметрам, специфичным для зоотоваров: вес животного, порода, размер обуви, объём наполнителя. Если фильтрация тормозит или выдаёт неполные результаты из-за того, что запрос «отвалился» по тайм-ауту, покупатель либо видит пустую выдачу («ничего не найдено» при том, что товар есть), либо ждёт дольше, чем готов ждать. Оба сценария бьют по конверсии напрямую, и усиливаются именно в пиковые для отрасли периоды, когда важен каждый посетитель.

Есть и менее очевидная сторона: медленный поиск тормозит и внутренние процессы. Менеджер, который ищет товар по артикулу поставщика, чтобы обновить остаток, тратит на это не секунды, а минуты — и это уже прямые операционные издержки, просто их сложнее увидеть в отчёте, чем брошенную корзину.

Где именно упирается поиск: разбор по частям

Чтобы понять, что чинить, полезно локализовать, где конкретно теряется время. Три типичные точки:

1. Сам запрос к базе. Если у вас есть доступ к базе (даже на общем хостинге через phpMyAdmin), можно посмотреть план выполнения:

EXPLAIN SELECT * FROM products
WHERE name LIKE '%корм для кошек%'
   OR description LIKE '%корм для кошек%';

Если в столбце type видите ALL — это полное сканирование таблицы, самый медленный вариант. Именно так чаще всего и выглядит поиск «из коробки» в большинстве CMS для интернет-магазинов без доп. настройки.

1. JOIN на фильтрах. Проверьте, во сколько запросов разворачивается фильтрация по нескольким атрибутам одновременно (бренд + вес + вкус). В плохо спроектированной схеме атрибутов (EAV-подход, когда у каждого товара произвольный набор параметров в отдельной таблице) один такой фильтр — это несколько JOIN подряд, и на 12 000 товаров это заметно тяжелее, чем на 500.

1. Отсутствие индексов на полях фильтрации. Проверить просто: SHOW INDEX FROM products;. Если по полям brand_id, weight, category_id индексов нет — каждый фильтр это скан. Добавление индексов дёшево и быстро даже без переезда, но у него есть потолок: индекс ускоряет точный поиск по полю, а не текстовый поиск по названию и описанию с учётом опечаток и словоформ.

Диагностика на общем хостинге сама по себе неудобна: часто нет доступа к EXPLAIN ANALYZE, нет прав менять конфигурацию MySQL/MariaDB, нет возможности поставить отдельный процесс для полнотекстовой индексации. Вы упираетесь не в код, а в права администратора, которых на общем хостинге у вас просто нет.

Что меняется на своём сервере

Собственный сервер (VPS или выделенный) не «магическим образом» ускоряет поиск — он даёт вам то, чего на общем хостинге нет в принципе: полный контроль над ресурсами и конфигурацией под конкретную задачу.

Ресурсы не делятся с чужими сайтами. Выделенные вам CPU и RAM работают только на ваш каталог. Пиковая нагрузка от соседей по серверу больше не может «съесть» ваш поиск — её просто нет, вы на своей машине.

Можно настроить базу под тяжёлые запросы. У вас есть root-доступ, а значит можно увеличить буферы, вынести полнотекстовый поиск в отдельный индексный движок, настроить кеш результатов под конкретные комбинации фильтров, которые реально используют ваши покупатели.

Полнотекстовая индексация становится реальным вариантом, а не мечтой. На своём сервере можно поднять отдельный сервис для поиска, который строит индекс по названиям, описаниям и атрибутам товаров и отдаёт результат за счёт структуры данных, заточенной под поиск, а не под хранение. Это принципиально другой подход по сравнению с LIKE по живой таблице: индекс строится заранее, а сам поиск — это уже не скан, а быстрое обращение к готовой структуре. Какой конкретно инструмент под это использовать — отдельный вопрос конфигурации, и универсального ответа тут нет: важно, что на своём сервере у вас появляется техническая возможность его развернуть и настроить под ваш ассортимент, а на общем хостинге такой возможности зачастую нет вовсе.

Оперативная память под кеш, а не «сколько дали в тарифе». Часто повторяющиеся запросы — топ брендов, топ категорий, сезонные фильтры — можно держать в памяти и отдавать мгновенно, не трогая базу каждый раз заново.

Ниже — качественное сравнение, без придуманных цифр, просто по набору возможностей:

Как подойти к переезду и настройке без лишней драмы

Переход с общего хостинга на свой сервер ради поиска не обязан быть «большим проектом на полгода». Разумный порядок действий:

1. Сначала измерьте, а не гадайте. Прямо на текущем хостинге посмотрите EXPLAIN для 3-5 самых частых поисковых запросов и запросов с фильтрами. Это покажет, действительно ли дело в сканировании таблиц, или проблема шире — например, в самом коде, который дёргает базу по кругу.

1. Определите реальный объём каталога и его рост. 12 000 SKU сегодня — это не то же самое, что 12 000 через год, если ассортимент растёт. Закладывайте запас, а не тариф впритык под текущий объём.

1. Выбирайте конфигурацию под характер нагрузки. Поиск и фильтрация — это в первую очередь нагрузка на CPU и RAM (буферы БД, кеш, при необходимости отдельный поисковый индекс), а не на диск как таковой — если у вас база на SSD/NVMe и достаточно памяти под кеш горячих данных, это даст больше, чем формальный прирост числа ядер.

1. Перенесите базу и настройте её отдельно, не «как было». Перенос — это не просто дамп и импорт. Это ещё и момент, чтобы добавить недостающие индексы на поля фильтрации, проверить кодировку и коллацию (для корректного поиска по русским словам это критично), и настроить буферы под объём вашей базы.

1. Разверните полнотекстовый поиск отдельно от «обычных» запросов к базе. Не обязательно переписывать весь магазин сразу — можно начать с того, что поиск по каталогу и фильтры уходят на отдельный индексный сервис, а корзина, заказы и личный кабинет продолжают работать как есть.

1. Настройте мониторинг. Отслеживание времени ответа поиска и загрузки CPU/RAM позволяет заметить деградацию заранее — до того, как отдел продаж придёт с вопросом «почему падают заказы».

Если вы делаете это впервые, само по себе решение о переезде часто откладывают именно из-за ощущения масштаба задачи. На практике перенос сайта с общего хостинга на VPS — это хорошо описанный процесс, и если сомневаетесь, с чего начать, полезно сначала честно оценить, когда вообще пора уходить с shared-хостинга — не каждому магазину это нужно прямо сейчас, но на 12 000 SKU с активной фильтрацией признаки обычно уже видны невооружённым глазом.

Как не переплатить и не купить лишнего

Соблазн взять сервер «с запасом на вырост» понятен, но здесь важнее подобрать конфигурацию под реальный характер нагрузки, чем просто взять побольше ядер. Для каталога на 12 000 SKU с поиском и фильтрами в приоритете обычно оперативная память (под буферы базы и кеш) и быстрый диск, а не количество виртуальных ядер само по себе.

Полезно заранее прикинуть, сколько ресурсов реально нужно VPS для интернет-магазина именно вашего масштаба, а не ориентироваться на готовые «магазинные» тарифы наугад. Отдельно стоит держать в голове цену простоя: если поиск или весь магазин ляжет в разгар сезонной распродажи кормов, потери считаются не абстрактно — почитайте, сколько стоит минута простоя магазина, чтобы соотнести это с бюджетом на инфраструктуру.

Если аудитория международная, имеет смысл сразу смотреть в сторону сервера в подходящей локации — например, какой VPS для интернет-магазина в Великобритании подойдёт по балансу цены и задержки до аудитории.

Частые вопросы