<div id="readability-page-1" class="page"><div>
  <main>
    <h3 id="리액티브-데이터-스토어-요건">리액티브 데이터 스토어 요건</h3>
<hr>
<ul>
<li>
<p>데이터를 데이터베이스에 넣기 전에, 먼저 리액티브 프로그래밍의 핵심 요건을 이해해야 한다. 리액티브 프로그래밍을 사용하려면 모든 과정이 리액티브여야 한다.</p>
</li>
<li>
<p>웹 컨트롤러를 리액티브 방식으로 동작하게 만들고 서비스 계층도 리액티브 방식으로 동작하게 만들었는데, 블로킹 방식으로 연결되는 데이터베이스를 호출하면 리액티브는 무너진다.</p>
</li>
<li>
<p>블로킹 방식으로 호출한 스레드는 응답을 받을 때까지 다른 작업을 하지 못한 채 기다려야 한다. 리액터 기반 애플리케이션은 많은 수의 스레드를 가지고 있지 않으므로 데이터베이스 호출 후 블로킹 되는 스레드가 많아지면 스레드가 모두 고갈되서 결국 전체 애플리케이션이 데이터베이스부터 결과를 기다리면서 아무런 일도 할 수 없는 상태가 되어 망가지게 된다.</p>
</li>
<li>
<p>리액티브 프로그래밍고 관련해서 흔히 떠올리는 선입견 중 하나는 리액티브가 태생적으로 빠르다는 주장이다. 이는 물론 사실이 아니다. 작업을 수행하는 단일 스레드의 처리 속도 기준으로 보면 리액티브 프로그래밍은 여러 가지 오버헤드를 수반하므로 성능 저하가 발생한다.</p>
</li>
<li>
<p>똑같은 화물을 나른다고 해도 소형차와 대형 트럭은 차이가 있는데 대형 트럭이 소형차보다 훨씬 많은 화물을 실어 나를 수 있는 것은 분명하다. 하지만 물건 하나만 나르는데 트럭을 사용하는 것은 낭비인 것과 같다. 불필요한 오버헤드를 감수하면서 리액티브를 사용하는 것은 낭비다.</p>
</li>
</ul>
<h3 id="리포지토리-만들기">리포지토리 만들기</h3>
<hr>
<ul>
<li>
<p>업계에서는 <code>NoSQL</code> 데이터 스토어를 표준화하는 방법을 찾기 위해서 다양한 시도를 해왔지만, 아직까지 성공한 사례가 없다. 이유는 모든 <code>NoSQL</code> 엔진을 하나의 API로 통일해서 표준화하려면 매우 복잡한 과정을 거쳐야 하고, 그렇게 해도 개별 엔진의 고유한 특성을 잃게 되므로, 결국에는 실패로 이어진다.</p>
</li>
<li>
<p>스프링은 <code>JdbcTemplate, RestTemplate, JmsTemplate</code> 같은 템플릿 패턴으로 이를 해결한다. 템플릿이라는 이름이 붙은 이 다양한 도구는 타입 안전 방식으로 연산을 처리하고, 다루기 복잡하고 귀찮은 것들을 추상화해서 데이터베이스 등 협력 대상과의 상호작용이 바르게 동작하도록 보장한다.</p>
</li>
<li>
<p><code>ReactiveCurdRepository</code>를 상속하며, 상속받는 메서드는 다음과 같다, <code>save(), saveAll(), findById(), findAll(), findAllbyId(), existsById(), count(), deleteById(), delete(), deleteAll()</code> 여러가지 풍부한 CRUD 연산이 포함되어 있다.</p>
</li>
<li>
<p>눈여겨봐야할 부분은 모든 메서드의 반환 타입이 <code>Mono</code> 나 <code>Flux</code> 둘 중에 하나라는 점이다. 이 부분이 매우 중요한데, <code>Mono</code> 나 <code>Flux</code>를 구독하고 있다가 몽고디비가 데이터를 제공할 준비가 되었을 때 데이터를 받을 수 있다.</p>
</li>
</ul>
<h3 id="참고-문헌">참고 문헌</h3>
<hr>
<ul>
<li>
<p><a href="https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=271824446">스프링부트 실전 활용 마스터</a></p>
</li>
<li>
<p><a href="https://dzone.com/articles/you-dont-need-hibernate-with-spring-webflux-and-r2">WebFlux + R2DBC</a></p>
</li>
</ul>

    <a href="../../../../"> &gt;&gt; Home</a>
  </main>
</div></div>

Home on 개발자 이동욱

Lee Dong Wook

리액티브 데이터 스토어 요건
데이터를 데이터베이스에 넣기 전에, 먼저 리액티브 프로그래밍의 핵심 요건을 이해해야 한다. 리액티브 프로그래밍을 사용하려면 모든 과정이 리액티브여야 한다.
웹 컨트롤러를 리액티브 방식으로 동작하게 만들고 서비스 계층도 리액티브 방식으로 동작하게 만들었는데, 블로킹 방식으로 연결되는 데이터베이스를 호출하면 리액티브는 무너진다.
블로킹 방식으로 호출한 스레드는 응답을 받을 때까지 다른 작업을 하지 못한 채 기다려야 한다. 리액터 기반 애플리케이션은 많은 수의 스레드를 가지고 있지 않으므로 데이터베이스 호출 후 블로킹 되는 스레드가 많아지면 스레드가 모두 고갈되서 결국 전체 애플리케이션이 데이터베이스부터 결과를 기다리면서 아무런 일도 할 수 없는 상태가 되어 망가지게 된다.
리액티브 프로그래밍고 관련해서 흔히 떠올리는 선입견 중 하나는 리액티브가 태생적으로 빠르다는 주장이다. 이는 물론 사실이 아니다. 작업을 수행하는 단일 스레드의 처리 속도 기준으로 보면 리액티브 프로그래밍은 여러 가지 오버헤드를 수반하므로 성능 저하가 발생한다.
똑같은 화물을 나른다고 해도 소형차와 대형 트럭은 차이가 있는데 대형 트럭이 소형차보다 훨씬 많은 화물을 실어 나를 수 있는 것은 분명하다. 하지만 물건 하나만 나르는데 트럭을 사용하는 것은 낭비인 것과 같다. 불필요한 오버헤드를 감수하면서 리액티브를 사용하는 것은 낭비다.
리포지토리 만들기
업계에서는 NoSQL 데이터 스토어를 표준화하는 방법을 찾기 위해서 다양한 시도를 해왔지만, 아직까지 성공한 사례가 없다. 이유는 모든 NoSQL 엔진을 하나의 API로 통일해서 표준화하려면 매우 복잡한 과정을 거쳐야 하고, 그렇게 해도 개별 엔진의 고유한 특성을 잃게 되므로, 결국에는 실패로 이어진다.
스프링은 JdbcTemplate, RestTemplate, JmsTemplate 같은 템플릿 패턴으로 이를 해결한다. 템플릿이라는 이름이 붙은 이 다양한 도구는 타입 안전 방식으로 연산을 처리하고, 다루기 복잡하고 귀찮은 것들을 추상화해서 데이터베이스 등 협력 대상과의 상호작용이 바르게 동작하도록 보장한다.
ReactiveCurdRepository를 상속하며, 상속받는 메서드는 다음과 같다, save(), saveAll(), findById(), findAll(), findAllbyId(), existsById(), count(), deleteById(), delete(), deleteAll() 여러가지 풍부한 CRUD 연산이 포함되어 있다.
눈여겨봐야할 부분은 모든 메서드의 반환 타입이 Mono 나 Flux 둘 중에 하나라는 점이다. 이 부분이 매우 중요한데, Mono 나 Flux를 구독하고 있다가 몽고디비가 데이터를 제공할 준비가 되었을 때 데이터를 받을 수 있다.
참고 문헌
스프링부트 실전 활용 마스터
WebFlux + R2DBC

스프링부트 실전 활용 마스터 (2)

댓글