인프런 커뮤니티 질문&답변
작성자 없음
작성자 정보가 삭제된 글입니다.
지연로딩과 fetchJoin 성능 차이
작성
·
481
·
수정됨
1
즉시로딩을 사용하면 Member 객체를 불러 올 때 1+N문제가 발생하고 Lazy로딩을 사용하면 Team 객체를 사용할 때 쿼리문이 나가서 즉시로딩이든 지연로딩이든 결국 1+N 문제가 생기는 게 맞나요 ?
이 1+N 문제의 해결방법으로 fetchJoin이 나온 것 같은데 지연 로딩, 즉시 로딩보다 무조건 fetchJoin이 이점이 있는 것 아닌가요? 왜 디폴트값으로 지연로딩으로 설정하고 fetchJoin을 선택해서 사용하는지 궁금합니다. 기본적으로 fetchJoin을 사용하고 연관관계에 있는 객체를 사용하지 않을 것 같은 경우에만 지연로딩을 선택적으로 사용하는게 더 편하지 않나요?
사용하지 않는 객체를 가져오는 fetchJoin의 쿼리문 몇 줄이 성능에 그렇게 큰 영향을 미치나요?
답변 2
1
제가 질문자는 아니지만 질문이 공감이 가지만 답변이 살짝 이해가 안되어서, 제가 이해한게 맞나 궁금합니다.
멤버 - 팀 관계에서 멤버를 조회해서 사용할때 멤버를 조회하는 여러 쿼리들을 작성할 수 있을것 같습니다.
이때 멤버를 조회할때 항상 팀을 조회할 필요는 없으니까 lazy로 하는 경우 프록시만 가져오겠네요.
만약 특정 쿼리에서는 팀 정보를 가져와야하니 이때를 위해서 방어적으로 lazy를 걸어둔것이고, 그 특정 쿼리를 위한 메서드에 fetchjoin을 하라는것으로 이해했습니다.
이게 맞을까요?
0
안녕하세요, hjemsti 님! 공식 서포터즈 codesweaver 입니다.
1. Member 를 불러오는 시점에 추가적인 쿼리 (Team을 조회하는 쿼리)가 발생하지 않고 시간 갭이 생기므로(Lazy일 경우 Team 엔터티 값을 사용하는 시점에 쿼리가 나갈 것이므로 시차가 생깁니다) 이 경우는 N+1 문제라고 하지는 않습니다. 다만 결과적으로 보면 나가는 쿼리 횟수는 동일할 수 있습니다
2 이와 같은 문제를 해결하려면 fetchJoin을 사용하나, fetchJoin은 테이블 간 조인 후 쿼리를 날리므로 남용할 경우 서버 부하를 유발합니다. 처음엔 Lazy 관계로 두어 사이드 이펙트를 모두 제거한 상태에서 추후 최적화 과정에서 fetchJoin 으로 바꾸는게 효율적인 부분은 그렇게 변경하는 방법을 권합니다.
3 사실 트래픽이 과도하게 발생하지 않는 서비스 (동접자 100명 미만)의 경우, 이정도 차이로 서버가 다운되는 현상이 발생할 확률은 적습니다. 다만 서비스 기획/개발은 서비스가 점차 확장될것을 전제로 만듭니다. 또 확장을 고려하지 않아도 결국 확장하게 되는 경우가 많고요. 그래서 부하가 걸릴 수 있는 부분을 '인지'하고 있는것이 중요합니다.
감사합니다.