проблема была в прежней некорректной реализации фильтров, нескольких лишних сервисах и 17-40Gb потребляемой оперативной памяти на процесс фильтрации товаров
в случае данного проекта избавились от ресуемкого приложения, большой его минус был в трудной поддержке, оно было не расширяемо, потому что проект легаси, без документации, тестов, изменения в коде влияло на многие вещи и приводило к непредвиденным ошибкам, плюсом его роль была просто посредником между сайтом и редис, что было лишним, так как сайт при наличии фасетных индексов может сам получать отфильтрованные множества без необходимости перебирать итеративно товары на удовлетворение условиям фильтра
на фильтры накладываются определенные бизнес правила, и тут недостаточно стандартной битриксовой реализации фильтров на модели EAV, и их кешированием, (если мы вас правильно понимаем), нужно было “готовить” фасетный поиск по требованиям бизнеса, и оперативно реагировать на их изменения
У нас была цель избавиться от ресурсоемкого приложения (на nodejs) как можно скорее, и мы решили переместить фасетный индекс в redis. Конечно, можно было это реализовать на базе mysql, но redis будет побыстрее
не совсем поняли, что вы имеете ввиду, если мы все перенесем в эластик, тогда не нужно ничего будет пересекать с редисом, в таком случае мы получим дубль данных по товарам в эластике, а чтобы от него избавиться придется переписать каталог с редиса на эластик - это пеработка, которая не вписывается в трудозатраты по текущим приоритетам клиента
>>15 лет назад подобная операция занимала секунды на сервере с 2Гб памяти, и требовала один запрос в БД. И полагаю, сейчас тоже так можно
такой запрос в БД учитывая изначальное правило фильтра, например, синий
"( ( group_color НЕ ПУСТОЙ ) И ( ( group_color СОДЕРЖИТ "Синяя" ) ) ) ИЛИ ( ( group_color ПУСТОЙ ) И ( ( ( tabletop_group_color СОДЕРЖИТ "Синяя" ) ) ИЛИ ( ( ( tabletop_group_color ПУСТОЙ ) ИЛИ ( tabletop_group_color = "Зеркальная" ) ИЛИ ( tabletop_group_color = "Неокрашенная" ) ) И ( ( ( facade_group_color_m СОДЕРЖИТ "Синяя" ) ) ИЛИ ( ( ( facade_group_color_m ПУСТОЙ ) ИЛИ ( facade_group_color_m = "Зеркальная" ) ИЛИ ( facade_group_color_m = "Неокрашенная" ) ) И ( ( ( covering_group_color СОДЕРЖИТ "Синяя" ) ) ИЛИ ( ( ( covering_group_color ПУСТОЙ ) ИЛИ ( covering_group_color = "Зеркальная" ) ИЛИ ( covering_group_color = "Неокрашенная" ) ) И ( ( armat_group_color_m СОДЕРЖИТ "Синяя" ) ) ) ) ) ) ) ) )"
будет достаточно сложно написать, учитывая архитектуру таблиц битрикса и количество свойств у товаров, тем более когда множественные свойства лежат в отдельной таблице. Такие запросы дадут большую нагрузку на таблицы каталога, а с ними непрерывно работает обмен товаров. А есть свойства фильтра, у которых правила сложнее, причем условие не полное равенство, а вхождение, что потребует like запроса
худший случай - это правило с большим количеством условий
В заключении статьи написали, что «нам пришлось бы индексировать в elastic все свойства каталога, а поскольку все товары у нас уже есть в redis - в этом нет смысла, мы только продублируем данные, поэтому нам достаточно проиндексировать товары и сохранить фасетные индексы в redis.»
Немного раскроем:
в разрезе этого проекта это достаточно трудозатратный процесс, а мы были очень ограничены по времени, чтобы наладить стабильную работу сайта. Чтобы уйти от редис как от хранилища данных, придётся переписать весь каталог и все процессы оформления заказа, так как весь каталог работает из редис, иначе мы просто продублируем данные, что не есть хорошо
На проекте уже был elastic, что вполне удовлетворяло требованиям
весь каталог уже хранился в redis, мы просто использовали то, что есть от redis и добавили лишь фасетные индексы
Спасибо! Мы двигаемся в этом направлении с клиентом
проблема была в прежней некорректной реализации фильтров, нескольких лишних сервисах и 17-40Gb потребляемой оперативной памяти на процесс фильтрации товаров
да, отказаться от битрикса на текущий момент невозможно, это потребует огромное количество ресурсов, так как все процессы на нем завязаны
в целом - да, мы хотели поделится опытом, к каким проблемам это может приводить и как непросто потом это исправлять в рамках ограничений клиента
нет, речь не об этом проекте
~9 тысяч
в случае данного проекта избавились от ресуемкого приложения, большой его минус был в трудной поддержке, оно было не расширяемо, потому что проект легаси, без документации, тестов, изменения в коде влияло на многие вещи и приводило к непредвиденным ошибкам, плюсом его роль была просто посредником между сайтом и редис, что было лишним, так как сайт при наличии фасетных индексов может сам получать отфильтрованные множества без необходимости перебирать итеративно товары на удовлетворение условиям фильтра
на фильтры накладываются определенные бизнес правила, и тут недостаточно стандартной битриксовой реализации фильтров на модели EAV, и их кешированием, (если мы вас правильно понимаем), нужно было “готовить” фасетный поиск по требованиям бизнеса, и оперативно реагировать на их изменения
У нас была цель избавиться от ресурсоемкого приложения (на nodejs) как можно скорее, и мы решили переместить фасетный индекс в redis. Конечно, можно было это реализовать на базе mysql, но redis будет побыстрее
не совсем поняли, что вы имеете ввиду, если мы все перенесем в эластик, тогда не нужно ничего будет пересекать с редисом, в таком случае мы получим дубль данных по товарам в эластике, а чтобы от него избавиться придется переписать каталог с редиса на эластик - это пеработка, которая не вписывается в трудозатраты по текущим приоритетам клиента
>>15 лет назад подобная операция занимала секунды на сервере с 2Гб памяти, и требовала один запрос в БД. И полагаю, сейчас тоже так можно
такой запрос в БД учитывая изначальное правило фильтра, например, синий
"( ( group_color НЕ ПУСТОЙ ) И ( ( group_color СОДЕРЖИТ "Синяя" ) ) ) ИЛИ ( ( group_color ПУСТОЙ ) И ( ( ( tabletop_group_color СОДЕРЖИТ "Синяя" ) ) ИЛИ ( ( ( tabletop_group_color ПУСТОЙ ) ИЛИ ( tabletop_group_color = "Зеркальная" ) ИЛИ ( tabletop_group_color = "Неокрашенная" ) ) И ( ( ( facade_group_color_m СОДЕРЖИТ "Синяя" ) ) ИЛИ ( ( ( facade_group_color_m ПУСТОЙ ) ИЛИ ( facade_group_color_m = "Зеркальная" ) ИЛИ ( facade_group_color_m = "Неокрашенная" ) ) И ( ( ( covering_group_color СОДЕРЖИТ "Синяя" ) ) ИЛИ ( ( ( covering_group_color ПУСТОЙ ) ИЛИ ( covering_group_color = "Зеркальная" ) ИЛИ ( covering_group_color = "Неокрашенная" ) ) И ( ( armat_group_color_m СОДЕРЖИТ "Синяя" ) ) ) ) ) ) ) ) )"
будет достаточно сложно написать, учитывая архитектуру таблиц битрикса и количество свойств у товаров, тем более когда множественные свойства лежат в отдельной таблице. Такие запросы дадут большую нагрузку на таблицы каталога, а с ними непрерывно работает обмен товаров. А есть свойства фильтра, у которых правила сложнее, причем условие не полное равенство, а вхождение, что потребует like запроса
худший случай - это правило с большим количеством условий
В ответе выше раскрыли вопрос
В заключении статьи написали, что «нам пришлось бы индексировать в elastic все свойства каталога, а поскольку все товары у нас уже есть в redis - в этом нет смысла, мы только продублируем данные, поэтому нам достаточно проиндексировать товары и сохранить фасетные индексы в redis.»
Немного раскроем:
в разрезе этого проекта это достаточно трудозатратный процесс, а мы были очень ограничены по времени, чтобы наладить стабильную работу сайта. Чтобы уйти от редис как от хранилища данных, придётся переписать весь каталог и все процессы оформления заказа, так как весь каталог работает из редис, иначе мы просто продублируем данные, что не есть хорошо