Антон Котов - Почему мы решили переходить на R2DBC и чем это закончилось
HTML-код
- Опубликовано: 19 июн 2022
- Ближайшая конференция - Joker 2024, 9 октября (Online), 15-16 октября (Санкт-Петербург + трансляция).
Подробности и билеты: jrg.su/Ypf1HW
- -
Если Spring WebFlux, то Spring Data R2DBC. Часто выбор совсем нового способа реактивного взаимодействия с реляционными базами данных строится именно по такой логике. Что мы покупаем и чем платим? Какие трудности ждать, если годами писали на JDBC, а теперь грядет переезд в новую реактивную реальность? Когда это оправдано? Обо всем этом Антон расскажет в своем докладе.
Ссылка на презентацию: squidex.jugru.team/api/assets... 
Наука
Спасибо за видео.Коммент в поддержку!
Зачётный доклад, послушал с интересом. Спасибо, Антон!
Спасибо за хороший доклад!
Интересный доклад. Было бы здорово иметь возможность посмотреть на исходники 3 тестовых систем, которые рассматривались в докладе.
С выходом loom в jdk19 блокирующий вызов уже не выглядит, как ругательство с т.з перфоманса.
Материала про R2DBC уже немало, но никто не говорит о миграции. Если у нас есть жирненький сервис на классическом стеке, то как нам перейти в светлый мир реактивщины? За один коммит переписать 30к строчек кода и потом год это отлаживать?
кому надо уже переписали
Спасибо за доклад, некоторых вещей не знал, хотя работаю с этой штукой чуть ли не с момента её релиза, проблемы есть, но они решаемые, во всяком случаи при применении этой штуки не надо думать про блокировки реактора
Мне кажется, применимо другое правило - если ты используешь реляционку, то скорее всего тебе реактивщина не нужна, ибо такого-кол-ва одновременных запросов у тебя нет. А если есть, то реляционка вряд ли это потянет
Если меряет перформанс то надо сначала создать гипотезу а потом ее проверять.
Иначе намерять можно много чего.
Но если даже померяли, без теории и гипотезы не понятно почему у реактившины выше задержки и лучше стабильность.
А если я просто 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и вы не программируете на хаскеле
Исходники хоть смотрели драйвера? Набор костылей. Да и сама постгря не создана для реактивного подключения.
не в восторге от этого дела, как-то слишком много сложностей спрятано под капотом, слишком много граблей на которые можно неожиданно наступить, отказоустойчивость сервисов можно огранизовать просто на уровне горизонтально скалируемой архитектуры, и вовсе необязательно настолько несвежие либы тащить на прод для этого