Битрикс и поиск(фильтрация элементов)
По моему скромному опыту, Битрикс для интернет магазина, выбирают компании, которые уже прошли путь викса, wp и прочей мелкой хуеты, которая не предоставляет такого количества компонентов в стоке. С мелкими CMS надо долго и упорно копаться, чтобы сделать функционал как стоке битрикса. Я говорю о CMS - типо WP, в который можно поставить модуль woocommerce и вскрыться после того, как будет нужно доработать корзину например.
Или Modx с его убогим Shopkeeper или miniShop2.
Есть компании, которым объяснили разрабы или студии, что лучше изначально работать с коммерческим ПО.
Викс, wp и т.д. отлично подходят для очень мелкого бизнеса, с низкими требованиями и маленькими бюджетами. Они никак не подходят для среднего и крупного бизнеса, у которого задачи совершенно другого порядка.
Работники Битрикса это поняли и создали инструмент с большим количеством различных компонентов и модулей уже в коробке. Как говорится бери делай)
Битрикс - такой зверек, который является продуктом хороших маркетологов, которые работают без хороших программистов.
О фильтрах
Фильтрация товаров по свойствам - одна из самых важных функций любой CMS для ecommerce.
На битриксе работают очень крупные магазины, с большим количеством товаров. Когда вы заходите в магазин, вы в 99% процентов случаев воспользуетесь фильтром(по цвету, по цене и т.д.)
Для фильтрации товаров Битрикс предлагает умный фильтр - стандартный компонент.
А что если товаров много и свойств много? Битрикс предлагает фасетный индекс. Это такой лайфхак, который чем то похож на кэширование. Он индексирует все товары и складывает их в отдельную табличку. В итоге фильтрация происходит по этой табличке. Все круто! По сравнению с обычной фильтрацией достаточно быстро. Но, если у нас много товаров (>200тыс) и у товаров много фильтруемых свойств (>60), то этот фасетный поиск превращается в АД. Даже оптимизированный от лишних проверок, поиск по свойствам работает до 6-8 секунд на мощном сервере. В пики нагрузка (CPU/RAM/HDD <50%)!
Пользователь не готов ждать столько времени, чтобы получить свой результат. В итоге растет шкала отказов в метрике, магазин теряет клиентов. Печалька(
Вернемся к Elasticsearch. Это номер один(по рейтингу DB-Engines) поисковая система!
На текущий момент, помимо прочих задачек, я ускоряю работу каталога.
Поднял docker Elasticsearch, выгрузил все свойства и поля.
Весь день делал разные замеры, но файлик куда все выписывал куда-то проебался.
Elasticsearch:
size: 1.94Gi (1.94Gi)
docs: 108 595 (108 631)
Фильтр по одному полю - Битрикс(0.27) Elasticsearch (0.005)
Фильтр по нескольким полям - Битрикс(0.96) Elasticsearch (0.009 seconds)
ПОСМОТРИТЕ НА РАЗНИЦУ!
Это при том, что в Elasticsearch выбираются все ПОЛЯ (>2000)!!!
Оптимизированный mysql, с фасетом-хуетом, никогда таких результатов НЕ ПОКАЖЕТ! НИКОГДА!
Почему нельзя в коробку добавить поддержку Elasticsearch?
Это как, корзина в ИМ, один из самых нужных компонентов, сотням магазинов.
В итоге приходится делать компонент умного фильтра, который работает с эластиком.
Ребята из битрикса! В 21 веке больших данных, стек технологий ELK - это обязательная вещь для ecommerce!
У вас хороший продукт, который пользуется спросом на рынке. Ну сделайте вы проще жизнь вашим клиентам! Запилите и добавьте поддержку ELK!
В постике сугубо мои личные мысли. Прошу сильно не пинать)
Частный разработчик Чибиляев Александр