Комментарии 40
А почему бы совсем не выкинуть редис и заменить его эластиком? Все равно ведь уже втащили.
В заключении статьи написали, что «нам пришлось бы индексировать в elastic все свойства каталога, а поскольку все товары у нас уже есть в redis - в этом нет смысла, мы только продублируем данные, поэтому нам достаточно проиндексировать товары и сохранить фасетные индексы в redis.»
Немного раскроем:
в разрезе этого проекта это достаточно трудозатратный процесс, а мы были очень ограничены по времени, чтобы наладить стабильную работу сайта. Чтобы уйти от редис как от хранилища данных, придётся переписать весь каталог и все процессы оформления заказа, так как весь каталог работает из редис, иначе мы просто продублируем данные, что не есть хорошо
вы же и так пересекаете множества из редиса с эластиком? Ну так перенесите всю логику в эластик и пересекайте "всё из редиса" с "то что нужно из эластика"
не совсем поняли, что вы имеете ввиду, если мы все перенесем в эластик, тогда не нужно ничего будет пересекать с редисом, в таком случае мы получим дубль данных по товарам в эластике, а чтобы от него избавиться придется переписать каталог с редиса на эластик - это пеработка, которая не вписывается в трудозатраты по текущим приоритетам клиента
Соглашусь с комментарием выше. Всю статью думал, почему просто не выкинуть нафиг все самодельные прослойки и не поставить тот же эластик?
Учитывая, что у вас строгая фильтрация, то и MySQL должна справляться, но ладно уж. Эластик будет делать все что вы сами понаписали через Redis, только эффективнее и без всего это геморроя с перестроением индексов. Просто при обновлении товаров помещайте их в эластик - дальше делайте запрос напрямую в него.
В ответе выше раскрыли вопрос
вопрос «почему не обойтись одним мускулом» не раскрыли.
У нас была цель избавиться от ресурсоемкого приложения (на nodejs) как можно скорее, и мы решили переместить фасетный индекс в redis. Конечно, можно было это реализовать на базе mysql, но redis будет побыстрее
Я может уже сплю в час ночи, но после абзаца про то, что в Node делается фильтрация прямо в памяти, что есть 5 копий, что почему-то рост трафика и числа товаров сделает больше копий, и пункта в следующем абзаце, что мол хочется "внести изменения в приложении Node.js", нет ни одного вхождения о дальнейшей судьбе ноды в статье.
Чем нода хуже остального зоопарка, как технология, пытались ли ее оптимизировать, пропала ли она из проекта, - все за кадром.
в случае данного проекта избавились от ресуемкого приложения, большой его минус был в трудной поддержке, оно было не расширяемо, потому что проект легаси, без документации, тестов, изменения в коде влияло на многие вещи и приводило к непредвиденным ошибкам, плюсом его роль была просто посредником между сайтом и редис, что было лишним, так как сайт при наличии фасетных индексов может сам получать отфильтрованные множества без необходимости перебирать итеративно товары на удовлетворение условиям фильтра
Почему бы не выкинуть битрикс, развели зоопарк во главе с химерой в лице битрикса, и героически бьються с мельницами и франкештейном в лице битрикса. Время потраченное на ковырянее в плохой архитектуре можно было с лёгкостью потратить на написание хорошо спроектированного портала для которого ни жалкие 150 rps, а даже 1500 rps будут не проблемой. Вообще в нашем мире говорить о 150 rps говорить мягко говоря уже не прилично, лет 10-20 назад когда только начал активно набирать обороты e-commerc и когда негде было черпать ответы как же это делаеться, тогда ещё да.
Вообще не понятно о чём и для кого статья, выглядит как, мы не очень умеем готовить redis, поэтому нам понадобился эластик, но мы не понимаем зачем, поэтому теперь есть и то и другое, и ещё mySql. И какие мы молодцы, не понимая как выжать максимум из того что есть, размазали везде по чуть-чуть, и стало сильно лучше.
>> Почему бы не выкинуть битрикс?
Клиент на текущий момент не готов отказаться от битрикс.
>>говорить о 150 rps говорить мягко говоря уже не прилично
это было не с целью "похвастаться", а просто рассказать о вводных данных проекта
>>поэтому нам понадобился эластик, но мы не понимаем зачем, поэтому теперь есть и то и другое, и ещё mySql
вся архитектура в таком виде живет на проекте уже более 7 лет и реализована не нами, нам нужно было просто в кратчайшие сроки привести проект в стабильное состояние, внося минимальное количество изменений, мы добавили только индексацию range свойств в эластик. Идея была в том, чтобы избавиться от лишнего сервиса управления фильтрами и лишнего, отжирающего много памяти, node.js
"Почему бы не выкинуть битрикс?"
Я клиент - у меня нет бюджета в 10 раз больше, чем коробка от битрикс. Битрикс с его "костылями" полностью перекрывает потребности моего бизнеса. Зачем платить больше? Где вообще найти денег на что-то другое? Что бы программистам было интереснее работать? Как вариант вообще тогда не делать, раз битрикс "говно".
нам нужно проверить 300к товаров, подходит ли каждый из них под это правило. Но мы не можем позволить себе делать такое количество запросов в БД
(ведь нужно проверить под 1 правило около 300к. товаров, а эта операция в худшем случае занимает 3 минуты)
Вот за это я и недолюбливаю некоторый современный инструментарий. 15 лет назад подобная операция занимала секунды на сервере с 2Гб памяти, и требовала один запрос в БД. И полагаю, сейчас тоже так можно :)
>>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 запроса
худший случай - это правило с большим количеством условий
Вывод не использовать битрикс а переписать на (laravel, yii)
Битрикс это зло ...
Кому лень гуглить, речь о 100sp.ru
Я думаю вы жертвы Легаси) Но плюсую за то, что с помощью палок, смогли улучшить, то что уже как бы и не предполагает улучшения и даже уже не живо.:) Это тоже не плохой опыт. Желаю вам запилить ещё статью, как вы выпилили Битрикс, перешли на современный стек opensource и улучшили rps на +100500.
Ну и в этих рамках, в принципе, сделано в итоге нормально.
Два раза начинал читать и так и не смог осилить до конца, в чем проблема то? Могу ошибаться, но 150rps и 300k записей в бд это же дефолтный мускул с адекватной схемой на дешевеньком сервере и больше ничего
это был ответ к этому сообщению
Решал подробную задачу, когда надо было "дёшево и сердито", без добавления новых сервисов, БД и в краткие сроки.
Добавил товарам новую колонку hstore, в которой хранил значения фильтров (filter_id: value). В результате, работа с каталогом не потребовала особых модификаций, однако для администрирования фильтров пришлось писать фоновую задачу переиндексации товаров - фильтры, кроме категорий и eav атрибутов, были завязаны на дополнительные условия.
Очень поучительная статья о том, что бывает, если городить костыль на костыле.
Почему не Manticore (форк Sphinx Search)? Гладко ложится на mysql, умеет в фасетный поиск, лишних ресурсов не жрет, работает очень быстро. Если использовать как прозрачное прокси между клиентом и базой не требует индексации.
А что мешало просто перейти на ClickHouse?
Как мы 40% RAM освободили