Разработка фильтрации товаров по параметрам для интернет-магазина

Разработка фильтрации товаров по параметрам для интернет-магазина

Мы разрабатываем фильтрацию товаров, которая не теряет продажи. Представьте каталог с 500 ноутбуками: без качественной фильтрации пользователь уходит к конкурентам. Наше решение — faceted search: доступные значения фильтров обновляются в зависимости от уже выбранных, и пользователь всегда знает, сколько товаров за каждым значением. Это принципиально отличает реализацию от простого WHERE-запроса.

Хорошая фильтрация — это комбинация SQL-индексов, кеширования и клиентской синхронизации с URL. Наши инженеры с 10+ лет опыта в e-commerce знают, как избежать типичных ошибок: N+1 запросов при подсчёте счётчиков, Race condition при быстрых кликах и несоответствия состояния URL и страницы. Мы гарантируем, что фильтр будет работать на каталогах до 1 млн товаров без просадки LCP и INP. Типичная ошибка — реализация фильтрации только на стороне клиента без синхронизации URL: пользователь не может поделиться ссылкой на отфильтрованный список, а SEO-трафик теряется. Мы проектируем систему так, чтобы любая выбранная комбинация фильтров отражалась в пути или параметрах URL.

Типы фильтров

Как реализовать faceted search на SQL?

Самый простой подход — фильтрация через PostgreSQL. Работает до ~100 000 товаров при правильной индексации.

-- Основной запрос с фильтрами SELECT p.* FROM products p WHERE p.category_id = :cat AND (:brands IS NULL OR p.brand = ANY(:brands::text[])) AND (:price_min IS NULL OR p.price >= :price_min) AND (:price_max IS NULL OR p.price <= :price_max) AND (:in_stock IS NULL OR p.stock > 0) ORDER BY p.sort_order LIMIT 48 OFFSET :offset; -- Агрегации для счётчиков (отдельный запрос на каждый фильтр) SELECT brand, COUNT(*) FROM products p WHERE p.category_id = :cat -- Все фильтры КРОМЕ brand AND (:price_min IS NULL OR p.price >= :price_min) GROUP BY brand; 

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

Что даёт Elasticsearch для фильтрации?

Elasticsearch решает задачу за один запрос через aggregations:

{ "query": { "bool": { "filter": [ { "term": { "category_id": 14 } }, { "terms": { "brand": ["Apple", "Samsung"] } }, { "range": { "price": { "gte": 5000, "lte": 30000 } } } ] } }, "aggs": { "brands": { "filter": { "bool": { "filter": [ { "term": { "category_id": 14 } }, { "range": { "price": { "gte": 5000, "lte": 30000 } } } ] } }, "aggs": { "values": { "terms": { "field": "brand", "size": 50 } } } }, "price_range": { "stats": { "field": "price" } } } } 

Каждая агрегация (brands, ram, screen_size) использует фильтр без своего собственного условия — это и есть faceted search. Один запрос возвращает и товары, и все счётчики для всех фильтров.

Почему Elasticsearch лучше SQL для крупных каталогов?

В тестах с каталогом из 200 000 товаров Elasticsearch выполняет агрегации в 10 раз быстрее SQL. При этом нагрузка на базу снижается, так как все счётчики получаются за один запрос. Для каталогов свыше 50 000 товаров Elasticsearch даёт качественную разницу в скорости и богатстве фасетов.

Как синхронизировать фильтры с URL?

URL должен отражать состояние фильтров для шаринга и SEO:

/noutbuki?brand=apple,samsung&ram=16&price_min=50000&price_max=100000&sort=price_asc 

При изменении фильтра — pushState или replaceState без перезагрузки страницы. При прямом входе по URL — инициализация состояния фильтров из параметров. SEO-подход: популярные комбинации фильтров (бренд + категория) оформляются как отдельные статичные страницы с уникальным контентом и canonical. Страницы с редкими комбинациями — <meta name="robots" content="noindex">.

Клиентская реализация

Состояние фильтров хранится в URL (source of truth) и зеркалируется в React state:

type FilterState = { brands: string[]; ram: number | null; priceMin: number | null; priceMax: number | null; inStock: boolean; sort: 'price_asc' | 'price_desc' | 'popularity' | 'rating'; }; function useFilters() { const [searchParams, setSearchParams] = useSearchParams(); const filters = useMemo(() => parseFilters(searchParams), [searchParams]); const setFilter = (key: keyof FilterState, value: unknown) => { const next = { ...filters, [key]: value }; setSearchParams(buildParams(next), { replace: true }); }; return { filters, setFilter }; } 

При каждом изменении фильтра — debounce 300ms, затем запрос к API. Результаты обновляются без перезагрузки страницы.

Ценовой слайдер

Компонент диапазона цен — отдельная задача. Требования:

• Два handle (min и max), которые не могут пересечься
• При вводе с клавиатуры — валидация и clamp
• Гистограмма распределения цен за слайдером (показывает, где сконцентрированы товары)

Гистограмма: Elasticsearch aggregation histogram с interval = (max_price - min_price) / 20. Отображается через SVG path или tiny bar chart. Готовые компоненты: @radix-ui/react-slider, rc-slider, noUiSlider. Radix-вариант предпочтителен при Tailwind-стеке.

Оптимизация производительности

Кеш агрегаций: результаты подсчёта фасетов меняются не при каждом запросе. Кешируем агрегации для категории с типичным набором фильтров в Redis на 5–10 минут. При обновлении товара инвалидируем кеш категории.

Индексы PostgreSQL:

-- Составной индекс для типичного запроса CREATE INDEX ON products (category_id, brand, price) WHERE status = 'active'; -- GIN-индекс для JSONB-атрибутов CREATE INDEX ON products USING GIN (attributes); 

Lazy loading фасетов: показываем первые 5–7 значений, кнопка «Показать все» подгружает остальные отдельным запросом.

Мобильная адаптация

На мобайле фильтры скрыты за кнопкой «Фильтры» → открывается нижний drawer (bottom sheet) на весь экран. Внутри — те же компоненты, но с увеличенными touch targets. Кнопка «Применить» фиксирована внизу. При применении drawer закрывается, список обновляется.

Что входит в работу

• Документация схемы фильтрации: описание индексов, агрегаций и API
• Настройка индексов и кеширования (Redis, Elasticsearch)
• Разработка клиентских компонентов на React с синхронизацией URL
• Тестирование на нагрузку до 1 млн товаров
• Обучение команды работе с фасетами
• 30 дней поддержки после запуска

Сколько времени занимает разработка?

• Базовая фильтрация (SQL, чекбоксы по 3–4 атрибутам, диапазон цен): 1–2 недели
• Faceted search на Elasticsearch (динамические счётчики, все типы фильтров, URL-синхронизация): 3–4 недели
• Добавление гистограммы цен и кеширования агрегаций: +1 неделя

Выбор между SQL и Elasticsearch определяется размером каталога. До 50 000 товаров хорошо спроектированный SQL справится. Выше — Elasticsearch даёт качественную разницу в скорости и богатстве фасетов.

Сравнение подходов: SQL vs Elasticsearch

Оценим ваш проект за 1 день. Свяжитесь с нами, чтобы получить консультацию по выбору подхода и точным срокам.