Каталог бытовой электроники — это десятки и сотни тысяч SKU, у каждого из которых десятки атрибутов: диагональ, разрешение, тип матрицы, чипсет, объём памяти, класс энергопотребления, совместимость, габариты. Покупатель не ищет «телевизор» — он ищет «4K OLED 55 дюймов с HDMI 2.1 до 90 000 ₽». Бизнес-результат, на который влияет платформа, измеряется просто: какая доля посетителей доходит от поиска до карточки нужного товара и добавляет его в корзину, не уходя к конкуренту из-за медленного фильтра или неполной выдачи. Ниже — открытый разбор того, что на этом классе задач даёт Magento (Adobe Commerce), без привязки к конкретному проекту KT.Team.
Почему большой каталог электроники ломает «коробку»
Magento хранит атрибуты товаров в модели EAV (Entity-Attribute-Value). Это даёт гибкость — можно добавить любой атрибут без изменения схемы БД, — но на больших объёмах оборачивается проблемой: данные одного товара «размазаны» по множеству таблиц, и каждый запрос к каталогу, поиску и фильтрам превращается в дорогие JOIN-ы. По наблюдениям практиков, многие платформы начинают деградировать уже на 10 000–50 000 SKU, а рост числа атрибутов напрямую снижает пропускную способность БД и замедляет административную панель вплоть до таймаутов (Medium, Yegor Shytikov; Abbacus Technologies).
Вывод, который делают и сами разработчики Adobe, и сообщество: каталог в сотни тысяч SKU на Magento реален, но требует осознанной работы с индексацией и выносом поиска за пределы MySQL.
Индексация: read-only витрина вместо живых JOIN-ов
Magento решает проблему EAV через индексаторы — они заранее «расплющивают» данные в плоские таблицы, которые читает витрина. Для большого каталога критичны несколько практик из официальной документации Adobe (Indexer Optimization):
- Режим «Update by Schedule» обязателен для индексаторов с переключением таблиц: система пишет в таблицу-реплику, а затем атомарно подменяет рабочую, не давая покупателю увидеть «полупересчитанный» каталог.
- Раздельные read/write таблицы (например, `catalog_product_index_price` и её реплика) предотвращают взаимные блокировки во время переиндексации — витрина продолжает отдавать данные, пока в фоне идёт пересчёт.
- Размер батча — параметр, а не константа. Adobe приводит пример: снижение батча `catalog_product_price` с 5 000 до 1 000 сократило полную переиндексацию на 40 000 товаров «с примерно 4 часов до менее 2 часов».
- Исключение ненужных комбинаций website × customer group из индекса заметно сокращает время пересчёта — особенно при множестве групп клиентов и B2B-каталогах.
Для электроники это означает: цены, акции и наличие у сотен тысяч SKU обновляются по расписанию, без «замораживания» витрины в часы трафика.
Поиск и фасеты: Elasticsearch вместо MySQL
Слабое место «голого» Magento — слоистая навигация (layered navigation) на MySQL. На большом каталоге фильтры по бренду, диагонали, цене считаются медленно. Перенос поиска и фасетов в Elasticsearch/OpenSearch даёт значительный выигрыш и по скорости, и по UX: атрибуты-фильтры индексируются и обслуживаются поисковым движком, а не реляционной БД (Folio3, Magento Elasticsearch Guide).
Зрелое международное решение здесь — open-source модуль ElasticSuite от Smile-SA, который надстраивает над Elasticsearch управление релевантностью и фасетами на уровне каждого атрибута (Smile-SA/elasticsuite Wiki):
- Search weight — числовой вес атрибута в ранжировании: «название модели» можно сделать важнее «материала корпуса».
- Coverage rate (по умолчанию 90%) — фасет показывается, только если им покрыта значимая доля результатов. Так из выдачи «ноутбуки» уходит фильтр «диагональ объектива», уместный лишь для камер.
- Maximum size фасета и кнопка «показать ещё» — чтобы фильтр «бренд» не выводил сразу 300 значений.
- Сортировка значений фильтра — по числу результатов, вручную, по алфавиту или релевантности; настраивается глобально и переопределяется для отдельной категории.
- Числовые слайдеры для диапазонов (цена, диагональ, мощность) с настройкой точности.
Это и есть «точность подбора товара покупателем»: правильно настроенные веса и фасеты выводят релевантные модели в первых строках и убирают шум из фильтров.
Сравнение товаров и структура атрибутов
Magento «из коробки» поддерживает сравнение: каждому атрибуту задаётся флаг «Comparable on Storefront», и выбранные характеристики выводятся в таблицу сравнения (mgt-commerce). Для электроники, где покупатель сопоставляет 3–4 модели по два десятка параметров, это ключевой шаг к конверсии.
Чтобы EAV не убивал производительность, практики рекомендуют не один гигантский attribute set «на всё», а логичное деление по типам товаров: у телевизора и наушников разные наборы атрибутов. Конфигурируемые товары (configurable products) используются для вариаций — цвет, объём памяти — и считаются «хребтом» крупных каталогов в электронике.
Подход к расширению без форка ядра
Перечисленные механизмы — индексаторы, Elasticsearch, ElasticSuite — расширяют Magento штатными точками, а не правкой ядра. Это соответствует инженерному принципу минимальной модификации инструмента: бизнес-логику и интеграции выносят в модули и сервисы рядом, опираясь на зрелые международные стандарты (Elasticsearch, готовый open-source модуль фасетов) вместо самописных решений. Так система остаётся обновляемой и отчуждаемой — её можно передать другой команде без переписывания.
Вывод для бизнес-процесса
Главный сдвиг — не «настроить фильтры», а изменить процесс управления каталогом: контент-команда работает с атрибутами и наборами как с продуктовым активом (полнота и единообразие характеристик напрямую определяют качество фасетов и сравнения), а инженеры держат поиск в Elasticsearch и индексацию по расписанию. Метрика, по которой проверяют результат: доля сессий, в которых посетитель из поиска или фасета дошёл до карточки нужной модели и добавил её в корзину. Если фасет неполон или поиск медленный — её можно вернуть настройкой весов, coverage rate и режима индексации, а не миграцией платформы.
