개발이야기/DataBase
R2DBC 한 방 쿼리 고민s -> 안 된다!
대머리개발자
2024. 5. 21. 16:14
728x90
고성능 시스템을 구축하기 위해서는 필수라는데..손이 너무 많이 간다. ㅠ
최대한 한방 쿼리로 DB 자체의 요청 자제하는 방향으로 진행한다.
왜냐면 DB에서 발생하는 리소스가 높다것이다.
실상..비지니스로직에서 무한루프 준하는 프로세스가 돌지 않는이상 지연의 90%이상은 DB라고 본다.
뭐 암튼
(1 : N) * N 개의 쿼리는. R2DBC에서는....설명 ..은 코드로..보자.
fun searchQuestionByFormId(formId:Long): Mono<FormQuestionListDto>{
return Mono.zip(
formRepository.getFormById(formId), // (1)
questionRepository.searchQuestionByFormId(formId) // (2)
.flatMap { question ->
questionChoiceRepository.searchQuestionChoicesByQuestionIdOrderBySortAsc(question.id)
.collectList()
.map { questionViews -> question.toQuestionViewDto(questionViews)} // (2-1)
}.collectList() //(3)
).map {
FormQuestionListDto(form = it.t1, questions = it.t2)
}
}
(1)설문지의 기본 정보를 가져오고
(2)질문들을 가져오고
(2-1) 질문에 붙어 있는 선택지들을 가져온다.
==> 한방쿼리는 가능하지만 객체로 포팅이.... 쥐.쥐.
객관식의 질문들의 보기를 객관식 만큼 쿼리를 숑숑한다.
해서 앞선 내용에선 별도 테이블이 아닌 보기들을 딜리미터(,)로 이용했던 부분이긴 했다. ㅠㅠ
아무리 리액티브적으로.........고성능이라고 해도.......찝찝s
일단 PASS!!! 우리에겐 레디스가 있으니께.ㅠ
(3) 비동기적으로 처리되고 흘러가기 때문에 소팅이 필요하다.
//.collectList()
.collectSortedList { o1, o2 -> o1.sort.compareTo(o2.sort) }
728x90