Антон Котов - Reactive для CRUD: фантазии и реальность
Vložit
- čas přidán 4. 04. 2024
- Ближайшая конференция - Joker 2024, 9 октября (Online), 15-16 октября (Санкт-Петербург + трансляция).
Подробности и билеты: jrg.su/Ypf1HW
- -
Казалось бы, что может быть проще самого простого CRUD-сервиса, тем более на Spring? Тем не менее многообразие технологий и подходов для решения самых базовых проблем не дает нам однозначного ответа, когда ту или иную технологию лучше использовать.
В последнее время набирают популярность реактивные технологии, такие как WebFlux, в том числе на уровне взаимодействия с реляционными базами данных R2DBC. Появился и новый подход Project Loom.
Спикер разбирает, когда стоит использовать тот или иной подход, и подкрепляет выводы результатами нагрузочного тестирования.
Скачать презентацию с сайта Joker - jrg.su/ewxkPL
#crud #spring - Věda a technologie
Доклад начинается с 6:05
Как может быть бедный Hikari при R2DBC, если там используется специальный реактивный пул?
То есть автор указал причину бессмысленности реактивного стека из-за HikariCP, хотя сам и не использовал реактивный пул. К тому же данный пул уже автоматически идет со стартером spring-data-reactive
Интересно
Доклад - хорош.
я что-то не услышал главного в этом докоаде, а зачем реактивный подход в crud функциях? микроскопом тоже гвозди забивать не удобно, значит ли, что микроскоп как инструмент не оправдал ожиданий?
Комментарий от автора доклада: просто в последнее время все ударились в реактивщину, в том числе тащат ее для работы с реляционными базами данных, я же показал, что в большинстве случаев в этом как раз нет смысла. Я оставил свой развернутый комментарий к этому видео.
@@kotoant спасибо за ответ. поясню что я услышал в докладе "перечисленные варианты использования реактивного подхода с crud функционалом не состоятельны, следовательно вам не нужен реактивный подход в 99%". я считаю что это не корректный посыл. нет смысла перебирать разные варианты реализации реактивного подхода в случае с crud. потому что в функции crud нет тех проблем, которые решаются реактивным подходом. то есть вся ценность этих сравнений производительности разных реализации сводится к нулю просто потому что рассматриваемая функция в принципе своём не должна решаться реактивно. но при этом реактивный подход может помочь в 95% функции всего проекта, если эти функции НЕ crud.
Очень хороший доклад. Действительно, развенчивает миф о асинхронщине.
не понятно почему loom так обладжался
там же подкапотом используется forkjoin pool а он берет количество потоков из количества процессоров кот у вас было 4
следовало бы увеличить его размер явно
Дак в итоге где выигрыш от реактивщины будет, если не в CRUD то где? Получается чисто в модулях сетевой логики, роутинга и расчётов типа ETL? НО ETL это тоже EXTARCT и LOAD.... НУ ок выделим TRANSFORM в отдельный Async модуль - ну хрень какая-то....
Ну да, смысл Project Loom больше в запросах по сети, где нет ограниченных пулов коннекта, которые будут блокировать все потоки
а где вообще есть неограниченные пулы коннекта ?
@@xz8928 правильное замечание, на него ответ "нигде" :)
Я хотел сказать, что виртуальные потоки не создают своих ограниченных пулов, но работают поверх обычных пулов потоков, емнип. Тот же ForkJoin по дефолту.
То есть JVM эффективно управляет этими виртуальными потоками и для запросов по сети они будут большую часть времени спать, когда при запросах в базу будут блокироваться на чтение/запись и быстро выжирать предоставленный пул коннекта к базе.
Наверно можно сказать так: пулы будут везде, просто виртуальные потоки получат преимущество там, где нет блокировок
@@xz8928 нигде нет)
Наверно стоило сказать что Project Loom юзается там, где потоки могут ожидать (сетевые запросы), поэтому от размера пула нет сильной зависимости. Но работают виртуальные потоки все равно поверх пулов и в коннектах к базе, например, пул будет забиваться блокирующими операциями в потоках.
@@xz8928 нигде нет)
Наверно стоило сказать что Project Loom юзается там, где потоки могут ожидать (сетевые запросы), поэтому от размера пула нет сильной зависимости. Но работают виртуальные потоки все равно поверх пулов и в коннектах к базе, например, пул будет забиваться блокирующими операциями в потоках.
@@xz8928 нигде нет) Наверно стоило сказать что Project Loom юзается там, где потоки могут ожидать (сетевые запросы), поэтому от размера пула нет сильной зависимости. Но работают виртуальные потоки все равно поверх пулов и в коннектах к базе, например, пул будет забиваться блокирующими операциями в потоках.
Код на корутинах выглядит, как костыли, какой же котлин все таки убогий стал - превращается в джаваскрипт потихонечку)
Код на корутинах выглядит как код без корутин если убрать ключевое слово suspend.