본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
강의 요약
오늘 강의에서는 R2DBC의 이론적 기반과 구성 요소를 다루었다. 기존 JDBC의 블로킹 I/O 모델이 리액티브 애플리케이션에서 병목이 될 수 있기 때문에 비동기 접근의 필요성을 해결하기 위해 등장한 표준인 R2DBC에 대해서 정리해보자.
R2DBC란
R2DBC는 JDBC의 블로킹 I/O 한계를 극복한 리액티브 데이터베이스 명세로, Reactive Streams 기반 논블로킹 API를 제공한다. Pivotal 주도로 PostgreSQL, H2, MySQL, SQL Server 드라이버를 지원한다.
설계 원칙
논블로킹 I/O로 스레드 블로킹 제거, Publisher-Subscriber 패턴으로 백프레셔 지원, SPI-Drivers-Client 3계층 구조로 벤더 독립성 보장.
핵심 구성
ConnectionFactory는 JDBC의 DataSource와 유사하며 r2dbc:driver:protocol://host/database 형식 URL로 설정한다. ReactiveCrudRepository는 Mono, Flux 기반 비동기 CRUD를 제공한다.
핵심 제약사항
관계 매핑, 지연 로딩, 1차 캐싱 미지원으로 연관 엔티티는 수동 조합이 필요하다.
R2DBC 저수준 API
Connection 획득 후 Statement 생성하고 파라미터 바인딩한다. 벤더별 바인드 마커(H2: $1, MySQL: ?, Oracle: :param)가 다르므로 Named Parameter 사용을 권장한다. Batch는 createBatch().add()로 여러 SQL을 추가하며, Transaction은 beginTransaction(), commitTransaction()이 Publisher 반환하는 비동기 방식이다.
JDBC vs R2DBC 성능
jdbc와 r2dbc 성능 비교한 글이 있어서 참고해서 인용해보았다.
벤치마크 결과
| 동시성 | JDBC + MVC | R2DBC + WebFlux |
| < 200 | 효율적 | 오버헤드 존재 |
| > 200 | 스레드 풀 고갈 | 안정적 처리량 |
- 10,000 동시 요청에서 R2DBC는 2-3배 높은 처리량, 50% 짧은 응답시간을 보인다.
- 동시성 200이 분기점이며, 마이크로서비스나 API 게이트웨이에서 명확한 이점을 제공한다.
적용 가이드
| 상황 | 권장 |
| I/O-bound, 동시성 200+ | R2DBC |
| 복잡한 도메인, 트랜잭션 | JDBC + JPA |
| 레거시 통합 | JDBC |
주요 고려사항
- Oracle 미지원
- Mono/Flux 학습 필요
- WebFlux + JDBC 혼합과 blocking() 호출 금지
- 완전한 리액티브 스택 구성 필요.
참고 출처
- https://docs.spring.io/spring-data/relational/reference/
- https://www.baeldung.com/r2dbc
- https://www.baeldung.com/jdbc-vs-r2dbc-vs-spring-jdbc-vs-spring-data-jdbc
