DB에서 Join 쿼리로 데이터 조회하기 vs 각각 쿼리로 조회해서 Application Join하기

에프랩 온라인 커뮤니티에는 양질의 질문들이 올라오고 있는데요.

오늘은 ‘데이터'에 관한 질문을 가져와 봤습니다. 많은 분들이 참여해 서로 답글을 달아주는 것이 인상적이네요 😝

흐름에 따라 읽으면서 여러분의 생각도 대입해 보는 시간을 가지는 것을 추천드립니다! ✨

🙋🏼 안녕하세요 궁금한 게 있어서 질문 드려요!

현재 조회 API를 개발 중에 있는데요. 조회 Join 쿼리 사용을 지양하고, 각각 쿼리로 조회하여 Application 단에서 조인을 하라는 가이드를 받아서 Application Join 으로 개발을 진행 중입니다. 이에 따라 Backend 단에서 공통된 키를 잡고 매핑하는 과정이 추가되고 코드의 복잡성이 증가한다는 생각이 들었습니다.

그래서 이유를 여쭤보니 과거에 쿼리 Join을 하다가 성능상 이슈가 있어서 그런 것 같더라구요.(기존 코드에서도 어쩔 수 없는 부분은 Join을 사용하기도 합니다.) 여기서 궁금한 것이 DB에서 Join 쿼리로 데이터를 조회하는 방법이랑 각각 쿼리로 조회해서 Application Join을 하는 거랑 성능상 큰 차이가 있을까요?(직접적으로 DB에 부하를 최대한 줄이는 방법으로 선택한 방법인지 궁금하네요) 🥲 추가적으로 쿼리 작성은 쿼리빌더 혹은 로우 쿼리로 하고 있습니다! (Node — TypeORM)

💁🏻‍♂️Node쪽 ORM은 써보지 않아서 정확히는 모르겠지만,

본문에서 말씀하시는 문제가 Application단에서 조인하는 것보단 Lazy loading을 사용해 해결할 수 있는 부분이 아닐까 하는 생각이 드네요. 더 자세한 부분은 다른 분들 답변에 기대보겠습니다.

🙋🏼조금 더 확인을 해보니

Typeorm 쪽에서는 Join 쿼리가 의도치 않게 나가는 경우가 있었고, 현재 업무 특성상 DB가 조인을 하기 어려운 구조로 되어 있다 보니 팀 내에서는 App Join을 하는 것 같습니다.

🤦🏻‍♀️음..

단순한 조인도 모두 애플리케이션에서 처리한다면 개발에 상당히 불편할 것 같은데요, 쿼리튜닝으로는 해결이 어려운 상황일까요?

🙋🏼기본적으로 Entity 없이 인터페이스로 개발하고 있어서

기본적으로 ORM에서 제공하는 여러 기능들을 사용하기 어렵더라구요.

저도 이런 상황에서는 딱히 방법이 떠오르지 않아 기존 가이드 받은 대로 개발하고 있습니다(Map으로 돌려가면서요!🤣)

제 생각에는 말씀하신 쿼리튜닝은 사실 조회 쿼리가 단순해서 쿼리플랜 했을 때 인덱스도 모두 타서 딱히 튜닝할 부분이 없는 것 같아요.

💁🏽 이게 답변이 될지는 모르겠지만,

서브쿼리 성능 관련해서 읽다 보니 다음과 같은 내용을 발견하였습니다! 🙌🏻

결합 쿼리는 장기적인 관점에서 데이터 증가에 따라 통계 혹은 힌트의 변화로 옵티마이저가 동작하는 방식이 변경될 수 있기에 성능 저하의 주범이 될 수 있다. 또한, bulk data가 쌓이면 쌓일수록 메모리 이슈도 발생할 수 있다.

저희 쪽에선 JPA ORM을 사용 중인데 질문자님께서 활용 중이신 ORM 프레임워크의 Join 동작원리를 파악해야 정확한 답변을 드릴 수 있을 것으로 보입니다. 조금이나마 도움이 되길 바라는 마음에서 댓글 남겨봅니다. 🙇🏽‍♀️

Edited by F-Lab Marketer, Jen