🍃[Spring] JPA에서 연관관계를 사용하는 것이 항상 좋을까요?

• JPA에서 연관관계를 사용하는 것이 많은 장점을 제공하지만, 항상 최선의 선택은 아닐 수 있습니다.
  • 상황에 따라 연관관계를 사용하지 않는 것이 더 유리하거나, 필요한 경우 신중하게 설정해야 할 때도 있습니다.
    • 연관관계의 무분별한 사용은 성능 문제나 설계의 복잡성을 초래할 수 있기 때문입니다.

1️⃣ 연관관계를 사용하지 않아야 하는 상황 또는 주의해야 할 상황.

1️⃣ 복잡한 연관관계로 인한 성능 문제.

• 연관관계가 많아질수록 SQL 조인 쿼리가 복잡해지고, 성능 저하의 원인이 될 수 있습니다.
• 특히 즉시 로딩(Eager Loading)을 남용하면 불필요한 데이터까지 모두 로드하므로 N+1 문제가 발생할 수 있습니다.
  • 이는 객체 그래프의 크기가 커질수록 성능을 크게 저하시킵니다.
• 필요한 데이터만 조회해야 할 경우 연관관계를 피하고 필요한 정보만을 가져오는 JPQL이나 네이티브 쿼리를 사용하는 것이 더 나을 수 있습니다.

🙋‍♂️ 객체 그래프(Object Graph)

객체들 간의 그래프로 표현한 것을 의미합니다.
객체 지향 프로그래밍에서 객체는 다른 객체와 연관 관계를 가질 수 있는데, 이러한 객체들이 서로 참조하면서 구성된 연결 구조를 그래프 형태로 나타낸 것이 객체 그래프입니다.
객체 그래프(Object Graph)는 특정 객체를 조회할 때 연관된 다른 객체들까지 함께 탐색하게 되는 구조를 보여줍니다.

🙋‍♂️ JPQL(Java Persistence Query Language)

JPA(Java Persistence API)에서 엔티티 객체를 대상으로 하는 쿼리 언어입니다.
JPQL은 SQL과 비슷한 문법을 사용하지만, 데이터베이스의 테이블이 아닌 엔티티 객체를 대상으로 쿼리를 작성하는 언어입니다.
이를 통해 JPA를 사용하는 애플리케이션이 데이터베이스에 독립적인 쿼리를 작성하고 실행할 수 있습니다.

2️⃣ 연관관계로 인한 복잡한 트랜잭션 관리.

• 연관관계가 얽힌 상태에서 트랜잭션을 처리할 때, 엔티티 간 데이터 일관성을 유지하기 위한 관리가 복잡해질 수 있습니다.
• Cascade 옵션이나 orphanRemoval 옵션을 설정하여 부모-자식 엔티티의 생명 주기를 함께 관리할 수 있지만, 잘못된 설정으로 인해 의도치 않은 데이터 삭제나 데이터 일관성 문제가 발생할 수 있습니다.

3️⃣ 필요 이상의 조인 테이블 생성.

• 다대다(N:M) 관계를 직접 연관관계로 설정하면 자동으로 조인 테이블이 생성되는데, 이로 인해 성능 저하 및 쿼리 최적화가 어려워질 수 있습니다.
• 실무에서는 다대다 관계를 직접 사용하기보다는 조인 테이블을 엔티티로 분리하여 다대일(N:1) 및 일대다(1:N) 관계로 나누어 관리하는 방식이 더 권장됩니다.

4️⃣ 연관관계로 인한 데이터 의존성.

• 연관관계를 통해 객체 간의 의존성을 높이면, 단일 엔티티의 독립적인 사용이 어려워질 수 있습니다.
  • 예를 들어 Order와 Customer가 강하게 연결된 상태에서는 Order를 조회할 때 항상 Customer와 관련된 데이터도 함께 조회될 수 있습니다.
    • 이는 서로 다른 도메인 로직에 영향을 미칠 수 있습니다.

5️⃣ 단순한 값 조회의 경우.

• 단순히 ID만 필요하거나 간단한 조회를 해야 하는 경우에도 굳이 연관관계를 설정하여 객체를 참조하는 것은 과도할 수 있습니다.
  • 이 경우에는 연관관계를 설정하지 않고, ID를 통해 필요한 데이터를 조회하거나 DTO를 사용하여 필요한 데이터만 가져오는 것이 더 나을 수 있습니다.

6️⃣ API 응답 시 데이터 과다 로딩 문제.

• REST API 개발 시 연관관계를 설정하면, 직렬화 과정에서 양방향 관계에 의한 무한 루프나 과도한 데이터 로딩이 발생할 수 있습니다.
  • 이를 방지하기 위해 단방향 연관관계로 설계하거나, 필요한 경우 DTO(Data Transfer Object)를 사용해 필요한 데이터만 선택적으로 전달하는 방법이 더 적절할 수 있습니다.

🙋‍♂️ DTO(Data Transfer Object)

DTO(Data Transfer Object)는 데이터 전송 객체라는 뜻으로, 애플리케이션의 여러 계층 간에 데이터를 전달하기 위해 사용하는 객체입니다.
주로 데이터를 운반하는 역할을 하며, 로직이나 기능 없이 순수하게 데이터만을 포함하고 있습니다.
DTO(Data Transfer Object)는 일반적으로 비즈니스 로직이 있는 엔티티 객체와 분리하여, 필요한 데이터만 추출하여 전송하거나 받아오는 데 사용됩니다.

7️⃣ 캐싱과의 충돌.

• 연관관계가 많을 경우, 캐싱 시스템과 충돌할 수 있으며, 데이터의 갱신 시점이나 조회 시점에서 캐시 데이터와 실제 데이터 간의 일관성을 관리하기 어려울 수 있습니다.
  • 특히 지연 로딩(Lazy Loading)과 캐싱을 함께 사용할 경우 예상치 못한 쿼리가 발생하거나, 캐시에서 잘못된 데이터가 반환될 가능성이 높습니다.

2️⃣ 연관관계 사용 시 주의사항.

1️⃣ 필요한 경우에만 사용.

• 연관관계는 필요한 경우에만 설정하고, 가능한 한 단순한 관계로 유지하는 것이 좋습니다.

2️⃣ 지연 로딩(Lazy Loading)을 기본으로 설정.

• 즉시 로딩(Eager Loading)은 N+1 문제를 일으킬 수 있으므로, 기본적으로 지연 로딩(Lazy Loading)을 사용하고, 필요할 때 페치 조인(Fetch Join)이나 직접적인 JPQL 쿼리로 필요한 데이터를 가져오는 것이 좋습니다.

🙋‍♂️ N+1 문제

N+1 문제는 JPA와 같은 ORM(Object-Relational Mapping) 도구를 사용할 때 연관된 데이터를 조회하는 과정에서 불필요하게 많은 쿼리가 실행되는 문제를 의미합니다.
주로 지연 로딩(Lazy Loading) 설정이 있는 연관 관계에서 발생하며, 하나의 데이터를 조회할 때 추가로 연관된 데이터를 각각 조회하느라 N+1개의 쿼리가 실행되는 현상을 말합니다.

3️⃣ 단방향 연관관계 우선.

• 양방향 관계는 서로 간의 참조로 인해 복잡성이 증가할 수 있으므로, 단방향 연관관계를 우선적으로 사용하고, 정말 필요한 경우에만 양방향 연관관계를 설정합니다.

4️⃣ 조회 전용 연관관계.

• 연관관계를 사용하는 경우, 데이터의 변경이 필요 없다면 읽기 전용으로 설정하여 변경 작업 시 성능 문제나 무결성 문제가 발생하지 않도록 합니다.

3️⃣ 요약.

• 연관관계는 객체 간의 관계를 자연스럽게 표현하고 코드의 직관성을 높이지만, 잘못된 설정이나 과도한 사용은 성능 저하와 복잡성을 초래할 수 있습니다.
• 상황에 따라 연관관계를 단순화하거나 필요한 데이터만 직접 조회하는 방식도 고려해야 하며, 특히 트랜잭션 관리와 데이터 일관성 유지에 주의해야 합니다.