fetch join을 N+1 해결책 정도로만 쓰는지, ToMany 페이징의 한계를 알고 운영 리스크와 대안 설계까지 보는지를 가르려는 질문이다.
ToMany 관계를 fetch join하면 부모 행이 자식 수만큼 중복돼 결과 집합이 부풀어 오른다. 여기에 Pageable을 더하면 Hibernate가 SQL의 limit/offset을 적용하지 못하고 전체 결과를 메모리에 올린 뒤 잘라내는 방식으로 떨어진다. 그래서 데이터가 많을수록 힙 사용량이 폭증해 OOM과 응답 지연으로 이어진다. 컬렉션 fetch join은 빼고 @BatchSize·default_batch_fetch_size로 N+1을 잡거나, ID만 먼저 페이징한 뒤 상세를 따로 조회하는 두 단계 전략으로 분리하는 게 정석이다.
조회 API가 갑자기 느려지거나 OOM이 났던 경험이 있다면 fetch join + 페이징 조합과 연결할 수 있다
@BatchSize 도입 전후로 쿼리 수와 응답 시간 변화를 측정해 본 경험이 있다면 비교 데이터를 답변 근거로 가져갈 수 있다
fetch join을 걷어내고 두 단계 조회로 바꿔 안정성이 회복된 경험이 있다면 의사결정 과정을 풀어낼 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.