Please enable JavaScript.

Coggle requires JavaScript to display documents.

N+1 문제와 해결 방법 - Coggle Diagram

- - - - 지연 로딩을 적절히 사용할 경우 성능 상의 이점이 있지만,
        쿼리 성능 최적화에 신경을 써야함.
        예를 들어, DB 조회가 너무 자주 발생하면
        응답 시간이 지연되거나 서버 부하가 증가할 수 있음.
      - 패턴 추적 공격을 방지하기 위해 Lazy Loading을 설정할 때 필요한 데이터만 로딩하도록 해, 불필요한 데이터까지 로딩하지 않도록 관리하는 방식이 필요
  - - - EntityGraph (선언적 fetch 전략)
        JPQL을 직접 수정하지 않고, 엔티티에 어노테이션으로 연관 로딩 전략 지정
        
        @EntityGraph(attributePaths = {"orders"}) @Query("SELECT m FROM Member m") List<Member> findAllWithOrders();
        
        쿼리 수정 없이 선언적으로 Fetch 전략을 통제할 수 있다는 점이 장점.
        유지보수성과 코드 가독성이 뛰어나지만, 복잡한 다중 관계나 조건 기반 쿼리에서는 Fetch Join보다 유연성이 떨어짐.
        
        장점
        
        JPQL을 수정하지 않아도 되므로 유지보수성 향상
        
        코드 가독성 높음
        
        단점
        
        복잡한 조인 조건을 제어하기 어려움
        
        단순 fetch 용도에 적합
      - BatchSize (대량 조회 성능 개선)
        지연 로딩을 유지하면서도 한 번에 여러 엔티티를 가져오도록 IN 쿼리 크기 조절
        
        @BatchSize(size=100) private List<Order> orders;
        
        기존 Lazy 전략을 유지하면서 N+1 문제를 완화할 수 있는 현실적 대안.
        완벽한 해결은 아니지만, 쿼리를 수백 회 → 수 회로 줄이는 효과만으로도 성능상 체감 개선이 큼.
        
        장점
        
        Lazy Loading을 유지하면서 N+1 완화
        
        기존 로직 수정이 거의 필요 없음
        
        단점
        
        완전한 해결책은 아님. "개선책" 에 가까움
        
        DB round-trip은 여전히 존재
      - 특수 코드 (특수 케이스에서 직접 해결)
        JPQL, Native Qiery, QueryDSL 등으로 복잡한 조인이나 조건이 있는 데이터를 직접 조회
        ORM이 생성하는 쿼리가 비효율적일 때 사용하는 마지막 수단
        
        ORM이 한계에 부딪히는 복잡한 쿼리나 대량 데이터 처리에서 유용.
        단, ORM의 장점(자동화, 유지보수성)을 일부 포기하는 트레이드오프가 있으므로 핵심 로직에 한정해 최소한으로 사용하는 것이 바람직함.
        
        장점
        
        복잡한 조인/필터/조건을 자유롭게 처리 가능
        
        성능 튜닝 최적화 여지가 큼
        
        단점
        
        ORM의 장점(자동화, 유지보수성) 일부 포기
        
        코드 복잡도 증가
      - Fetch Join
        연관된 데이터를 JOIN으로 한 번에 조회하는 방법
        Lazy Loading을 무시하고 조인을 통해 모든 데이터를 한 번에 로딩
        
        SELECT m FROM Member m JOIN FETCH m.orders
        
        JPQL 단위에서 즉시 로딩을 세밀하게 제어할 수 있는 강력한 방법.
        다만, 컬렉션 fetch나 다중 조인에서는 제약이 있으므로, 복잡한 쿼리에서는 EntityGraph나 BatchSize와 병행하는 전략이 유효함.
        
        단점
        
        컬렉션 Fetch Join은 페이징 불가
        
        한 엔티티에서 Fetch Join 2개 이상 사용 불가
        
        장점
        
        N+1 문제를 가장 단순하고 확실하게 해결
        
        성능상 이점이 가장 큼 (쿼리 한번으로 해결)
      - 즉시 로딩 (Eager Loading)
        엔티티를 조회할 때 연관된 엔티티를 즉시 함께 조회하도록 설정하는 방식
        Lazy Loading(필요할 때마다 쿼리 실행)을 끄고, 처음부터 조인으로 한 번에 데이터 조회
        
        즉시 로딩은 설정만으로 N+1 문제를 해결할 수 있는 단순한 방법이지만, 항상 조인 실행으로 불필요한 데이터까지 조회하는 부작용이 큼.
        따라서, 실무에서는 대부분 Lazy Loading, 필요한 구간만 Fetch Join 또는 EntityGraph로 제어하는 전략이 선호됨.
        
        장점
        
        단순하고 설정만으로 사용 가능
        
        N+1 문제를 근본적으로 방지
        
        소규모 데이터나 고정된 연관 관계에서 효율적
        
        단점
        
        항상 조인 쿼리가 발생해, 필요 없는 데이터까지 함께 가져올 수 있음
        
        복잡한 엔티티 구조에서는 오히려 성능 저하
        
        유지보수 어려움 - 로딩 전략을 코드 전역에서 제어하기 어려움
        
        @Entity public class Member { @OneToMany(fetch = FetchType.EAGER) private List<Order> orders; }
    - - Django → select_related, prefetch_related
      - SQLAlchemy → joinedload, subqueryload