Антон Котов - Почему мы решили переходить на R2DBC и чем это закончилось

Ближайшая конференция - Joker 2024, 9 октября (Online), 15-16 октября (Санкт-Петербург + трансляция).
Подробности и билеты: jrg.su/Ypf1HW
- -
Если Spring WebFlux, то Spring Data R2DBC. Часто выбор совсем нового способа реактивного взаимодействия с реляционными базами данных строится именно по такой логике. Что мы покупаем и чем платим? Какие трудности ждать, если годами писали на JDBC, а теперь грядет переезд в новую реактивную реальность? Когда это оправдано? Обо всем этом Антон расскажет в своем докладе.
Ссылка на презентацию: squidex.jugru.team/api/assets...

[@roman_mf]

Зачётный доклад, послушал с интересом. Спасибо, Антон!

[@sovrinfo]

Спасибо за видео.Коммент в поддержку!

[@Nedlosster]

Интересный доклад. Было бы здорово иметь возможность посмотреть на исходники 3 тестовых систем, которые рассматривались в докладе.

[@denis_iii]

С выходом loom в jdk19 блокирующий вызов уже не выглядит, как ругательство с т.з перфоманса.

[@vikleb9817]

Спасибо за хороший доклад!

[@konstantinchudinov2553]

Мне кажется, применимо другое правило - если ты используешь реляционку, то скорее всего тебе реактивщина не нужна, ибо такого-кол-ва одновременных запросов у тебя нет. А если есть, то реляционка вряд ли это потянет

[@Panzerwatt]

Материала про R2DBC уже немало, но никто не говорит о миграции. Если у нас есть жирненький сервис на классическом стеке, то как нам перейти в светлый мир реактивщины? За один коммит переписать 30к строчек кода и потом год это отлаживать?

[@mrzoom214]

кому надо уже переписали

[@bananasba]

К сожалению, нет данных по производительности чисто БД, без этого не все ясно.

[@AlexeyPirogov]

Если меряет перформанс то надо сначала создать гипотезу а потом ее проверять. Иначе намерять можно много чего. Но если даже померяли, без теории и гипотезы не понятно почему у реактившины выше задержки и лучше стабильность. А если я просто rate limiter перед блокирующим поставлю, графики улучшаться? Слишком много неизвестных.

[@user-mm5ht3zj3s]

Спасибо за доклад, некоторых вещей не знал, хотя работаю с этой штукой чуть ли не с момента её релиза, проблемы есть, но они решаемые, во всяком случаи при применении этой штуки не надо думать про блокировки реактора

[@oleksandrkovsharov8974]

Окей, когда есть легаси база R2DBC имеет смысл. Но если мы дизайним систему какой смысл юзать R2DBC который кастрированый? Типо когда нужна реактивщина + ACID? Намного проще взять NoSql типа Монги где будет нативный реактивный драйвер и не нужно будет менеджить транзакции/entity-relations которые создают кучу тяжелых объектов + это неудобно. Как по мне reactive + реляционка это странное решение.

[@ogyct]

Наверное с приходом лума это перестанет быть актуальным. Кстати redhat сделали прорыв в реактивщине. Связка vertx и hibernate reactive. Зацените, кому интересно. Там работает pagination, relations и прочее.

[@hgfyos]

В общем и целом, всё ещё сыро. Фич мало, проблем много.

[@rusmemes]

вот вот, и нахрена оно в итоге нужно - непонятно, тупо хайп

[@hgfyos]

@@rusmemes зачем оно нужно, как раз понятно: дать больше перформанса за счёт асинхронного I/O

[@rusmemes]

@@hgfyos так не будет перформанса, ибо в любом случае упрешься в перформанс базы гораздо раньше чем в перформанс кода

[@hgfyos]

@@rusmemes почитайте про асинхронность и неблокирующий I/O, как это работает, чтобы голословным не быть. В любом случае, как бы вы не хотели, запрос к СУБД идёт через сервера бекенда, так что упереться в базу можно только в одном случае: сервер СУБД слабее сервера бекенда, что довольно редкая ситуация. А благодаря асинхронщине вы уменьшаете оверхед в виде кучи тредов, которые просто ждут СУБД, и Requests Per Second растёт кратно

[@alexshpaq]

​@@rusmemes вот вот, уже давным давно придумали circuit-breaker, если внешний провайдер данных, будь то БД или сторонний сервис начинает торомозить, нет никакого смысла засыпать его запросами и подкидывать ему работы, он от этого быстрее работать не станет. Есть целый ряд способов решить эту ситуацию, не переходя в асинхронщину...

[@user-fq3nn3ql3g]

Каждый разработчик должен попробовать функциональное программирование, реактивное программирование и... забыть его.

[@CyanideBtm]

только в случае если не осилил

[@hgfyos]

@@CyanideBtmи вы не программируете на хаскеле

[@prng792]

Исходники хоть смотрели драйвера? Набор костылей. Да и сама постгря не создана для реактивного подключения.

[@rusmemes]

не в восторге от этого дела, как-то слишком много сложностей спрятано под капотом, слишком много граблей на которые можно неожиданно наступить, отказоустойчивость сервисов можно огранизовать просто на уровне горизонтально скалируемой архитектуры, и вовсе необязательно настолько несвежие либы тащить на прод для этого