Да, безусловно перед стартом разработки было исследование решений на рынке, и подходящих на тот момент не нашлось.
Какие-то не соответствовали желаемому бизнес-процессу, где-то не было необходимых функциональностей таких, как разделение пользователей по сегментам. А часть не подошли просто по техническим требованиям и возможностям интегрироваться в существующий ландшафт.
Нет, вопрос не бессмысленный. Если есть требования к сервису, то они фиксируются для него в целом, а не на часть компонентов. Потому весь выбираемый набор инструментов и их конфигураций должно работать достаточно слажено, чтобы выполнять требования.
Нельзя сказать, что API работает быстро, когда код в сервисе супер быстрый, база отвечает мгновенно, а сеть между ними едва существует.
А для low-latency сервисов, как сервис сплитования, шумы в сети и малозаметные задержки на балансерах / ингрессах могут повлиять на времени ответа из API в процентилях 99.9% и даже 99% катастрофически.
Хороший поинт задумываться о таких мелочах до реализации важных и сложных решений. В одной из следующих статьей, мой коллега расскажет, как мы столкнулись с такого рода проблемой, и как ее решали :)
Исследование проводили. Была гипотеза, что требуется много времени на конвертацию объектов для передачи из python в rust и обратно. (Это, кстати, и правда занимает существенное время)
Если json-logic на rust быстрее python, то при очень больших выражениях, требующих много вычислений, rust должен начать обгонять python.
Для проверки этой гипотезы, провели замеры времени для выражений разной "жирности".
График отношения времени работы варианта python к варианту rust
На небольших выражениях разница в скорости небольшая, в 1k раз, а на больших выражениях уже в 2k раз и продолжает расти.
Вывод, к которому мы пришли, что операторы для выполнения json-logic, реализованные на rust, сами по себе требуют времени больше, чем аналогичные операции в CPython.
Честно не представляю, как использовать какую-либо БД в данной задаче: Если считаем, что каждый сегмент - отдельная запись, то в этой записи как-то будет описано правило, по которому пользователь попадет в этот сегмент.
А в самом запросе соответственно будет информация об этом пользователе.
Как проверить, что сотни разных таких правил, не прибегая к eval - не тривиальная задача.
Окэй, опустим, что eval - это зло, и мы сделали такое решение, но это не все тех. требования.
Насколько решение будет масштабируемым? Получится держать несколько тысяч RPS в real-time? Будет гарантированное время ответа в до 5 мс с учетом сети от сервиса до базы?
Лично у меня есть сомнения, что от КХ легко можно такого добиться.
json-logic с GitHub по сути самостоятельная виртуальная машина, которая исполняет выражения как есть. Скорость расчета сегментов зависит прямо и от кода в либе, и от скорости Python
реализация, которую мы сделали в команде - не виртуальная машина, а скорее компилятор для Python VM. В этом случае на время расчета сегмента может повлиять только скорость самого Python
Однако можно попробовать из этой схемы убрать Python в целом, оставить только вызов чего-то написанного на другом языке. В статье не говорится, но подобные исследования мы проводили до того, как начать пилить свой велосипед :)
В частности сравнивали с либой на rust, и наше решение оказывается на порядки быстрее.
Да, безусловно перед стартом разработки было исследование решений на рынке, и подходящих на тот момент не нашлось.
Какие-то не соответствовали желаемому бизнес-процессу, где-то не было необходимых функциональностей таких, как разделение пользователей по сегментам. А часть не подошли просто по техническим требованиям и возможностям интегрироваться в существующий ландшафт.
Нет, вопрос не бессмысленный. Если есть требования к сервису, то они фиксируются для него в целом, а не на часть компонентов. Потому весь выбираемый набор инструментов и их конфигураций должно работать достаточно слажено, чтобы выполнять требования.
Нельзя сказать, что API работает быстро, когда код в сервисе супер быстрый, база отвечает мгновенно, а сеть между ними едва существует.
А для low-latency сервисов, как сервис сплитования, шумы в сети и малозаметные задержки на балансерах / ингрессах могут повлиять на времени ответа из API в процентилях 99.9% и даже 99% катастрофически.
Хороший поинт задумываться о таких мелочах до реализации важных и сложных решений.
В одной из следующих статьей, мой коллега расскажет, как мы столкнулись с такого рода проблемой, и как ее решали :)
Исследование проводили. Была гипотеза, что требуется много времени на конвертацию объектов для передачи из python в rust и обратно. (Это, кстати, и правда занимает существенное время)
Если json-logic на rust быстрее python, то при очень больших выражениях, требующих много вычислений, rust должен начать обгонять python.
Для проверки этой гипотезы, провели замеры времени для выражений разной "жирности".
На небольших выражениях разница в скорости небольшая, в 1k раз, а на больших выражениях уже в 2k раз и продолжает расти.
Вывод, к которому мы пришли, что операторы для выполнения json-logic, реализованные на rust, сами по себе требуют времени больше, чем аналогичные операции в CPython.
Честно не представляю, как использовать какую-либо БД в данной задаче:
Если считаем, что каждый сегмент - отдельная запись, то в этой записи как-то будет описано правило, по которому пользователь попадет в этот сегмент.
А в самом запросе соответственно будет информация об этом пользователе.
Как проверить, что сотни разных таких правил, не прибегая к eval - не тривиальная задача.
Окэй, опустим, что eval - это зло, и мы сделали такое решение, но это не все тех. требования.
Насколько решение будет масштабируемым?
Получится держать несколько тысяч RPS в real-time?
Будет гарантированное время ответа в до 5 мс с учетом сети от сервиса до базы?
Лично у меня есть сомнения, что от КХ легко можно такого добиться.
Думаю, в этом нет большой необходимости.
json-logic с GitHub по сути самостоятельная виртуальная машина, которая исполняет выражения как есть. Скорость расчета сегментов зависит прямо и от кода в либе, и от скорости Python
реализация, которую мы сделали в команде - не виртуальная машина, а скорее компилятор для Python VM. В этом случае на время расчета сегмента может повлиять только скорость самого Python
Однако можно попробовать из этой схемы убрать Python в целом, оставить только вызов чего-то написанного на другом языке. В статье не говорится, но подобные исследования мы проводили до того, как начать пилить свой велосипед :)
В частности сравнивали с либой на rust, и наше решение оказывается на порядки быстрее.
На картинках ниже сравнение: