Материала про R2DBC уже немало, но никто не говорит о миграции. Если у нас есть жирненький сервис на классическом стеке, то как нам перейти в светлый мир реактивщины? За один коммит переписать 30к строчек кода и потом год это отлаживать?
Если меряет перформанс то надо сначала создать гипотезу а потом ее проверять. Иначе намерять можно много чего. Но если даже померяли, без теории и гипотезы не понятно почему у реактившины выше задержки и лучше стабильность. А если я просто rate limiter перед блокирующим поставлю, графики улучшаться? Слишком много неизвестных.
Мне кажется, применимо другое правило - если ты используешь реляционку, то скорее всего тебе реактивщина не нужна, ибо такого-кол-ва одновременных запросов у тебя нет. А если есть, то реляционка вряд ли это потянет
Окей, когда есть легаси база R2DBC имеет смысл. Но если мы дизайним систему какой смысл юзать R2DBC который кастрированый? Типо когда нужна реактивщина + ACID? Намного проще взять NoSql типа Монги где будет нативный реактивный драйвер и не нужно будет менеджить транзакции/entity-relations которые создают кучу тяжелых объектов + это неудобно. Как по мне reactive + реляционка это странное решение.
Наверное с приходом лума это перестанет быть актуальным. Кстати redhat сделали прорыв в реактивщине. Связка vertx и hibernate reactive. Зацените, кому интересно. Там работает pagination, relations и прочее.
Спасибо за доклад, некоторых вещей не знал, хотя работаю с этой штукой чуть ли не с момента её релиза, проблемы есть, но они решаемые, во всяком случаи при применении этой штуки не надо думать про блокировки реактора
@@rusmemes почитайте про асинхронность и неблокирующий I/O, как это работает, чтобы голословным не быть. В любом случае, как бы вы не хотели, запрос к СУБД идёт через сервера бекенда, так что упереться в базу можно только в одном случае: сервер СУБД слабее сервера бекенда, что довольно редкая ситуация. А благодаря асинхронщине вы уменьшаете оверхед в виде кучи тредов, которые просто ждут СУБД, и Requests Per Second растёт кратно
@@rusmemes вот вот, уже давным давно придумали circuit-breaker, если внешний провайдер данных, будь то БД или сторонний сервис начинает торомозить, нет никакого смысла засыпать его запросами и подкидывать ему работы, он от этого быстрее работать не станет. Есть целый ряд способов решить эту ситуацию, не переходя в асинхронщину...
не в восторге от этого дела, как-то слишком много сложностей спрятано под капотом, слишком много граблей на которые можно неожиданно наступить, отказоустойчивость сервисов можно огранизовать просто на уровне горизонтально скалируемой архитектуры, и вовсе необязательно настолько несвежие либы тащить на прод для этого
Зачётный доклад, послушал с интересом. Спасибо, Антон!
Материала про R2DBC уже немало, но никто не говорит о миграции. Если у нас есть жирненький сервис на классическом стеке, то как нам перейти в светлый мир реактивщины? За один коммит переписать 30к строчек кода и потом год это отлаживать?
кому надо уже переписали
Отличный доклад, спасибо!
С выходом loom в jdk19 блокирующий вызов уже не выглядит, как ругательство с т.з перфоманса.
Интересный доклад. Было бы здорово иметь возможность посмотреть на исходники 3 тестовых систем, которые рассматривались в докладе.
Если меряет перформанс то надо сначала создать гипотезу а потом ее проверять.
Иначе намерять можно много чего.
Но если даже померяли, без теории и гипотезы не понятно почему у реактившины выше задержки и лучше стабильность.
А если я просто rate limiter перед блокирующим поставлю, графики улучшаться?
Слишком много неизвестных.
Спасибо за видео.Коммент в поддержку!
Мне кажется, применимо другое правило - если ты используешь реляционку, то скорее всего тебе реактивщина не нужна, ибо такого-кол-ва одновременных запросов у тебя нет. А если есть, то реляционка вряд ли это потянет
К сожалению, нет данных по производительности чисто БД, без этого не все ясно.
Окей, когда есть легаси база R2DBC имеет смысл. Но если мы дизайним систему какой смысл юзать R2DBC который кастрированый? Типо когда нужна реактивщина + ACID? Намного проще взять NoSql типа Монги где будет нативный реактивный драйвер и не нужно будет менеджить транзакции/entity-relations которые создают кучу тяжелых объектов + это неудобно. Как по мне reactive + реляционка это странное решение.
Наверное с приходом лума это перестанет быть актуальным. Кстати redhat сделали прорыв в реактивщине. Связка vertx и hibernate reactive. Зацените, кому интересно. Там работает pagination, relations и прочее.
Спасибо за доклад, некоторых вещей не знал, хотя работаю с этой штукой чуть ли не с момента её релиза, проблемы есть, но они решаемые, во всяком случаи при применении этой штуки не надо думать про блокировки реактора
Спасибо за хороший доклад!
В общем и целом, всё ещё сыро. Фич мало, проблем много.
вот вот, и нахрена оно в итоге нужно - непонятно, тупо хайп
@@rusmemes зачем оно нужно, как раз понятно: дать больше перформанса за счёт асинхронного I/O
@@hgfyos так не будет перформанса, ибо в любом случае упрешься в перформанс базы гораздо раньше чем в перформанс кода
@@rusmemes почитайте про асинхронность и неблокирующий I/O, как это работает, чтобы голословным не быть.
В любом случае, как бы вы не хотели, запрос к СУБД идёт через сервера бекенда, так что упереться в базу можно только в одном случае: сервер СУБД слабее сервера бекенда, что довольно редкая ситуация. А благодаря асинхронщине вы уменьшаете оверхед в виде кучи тредов, которые просто ждут СУБД, и Requests Per Second растёт кратно
@@rusmemes вот вот, уже давным давно придумали circuit-breaker, если внешний провайдер данных, будь то БД или сторонний сервис начинает торомозить, нет никакого смысла засыпать его запросами и подкидывать ему работы, он от этого быстрее работать не станет. Есть целый ряд способов решить эту ситуацию, не переходя в асинхронщину...
Каждый разработчик должен попробовать функциональное программирование, реактивное программирование и... забыть его.
только в случае если не осилил
@@CyanideBtmи вы не программируете на хаскеле
Исходники хоть смотрели драйвера? Набор костылей. Да и сама постгря не создана для реактивного подключения.
не в восторге от этого дела, как-то слишком много сложностей спрятано под капотом, слишком много граблей на которые можно неожиданно наступить, отказоустойчивость сервисов можно огранизовать просто на уровне горизонтально скалируемой архитектуры, и вовсе необязательно настолько несвежие либы тащить на прод для этого