JPA와 ORM

📌ORM(Object Realational Mapping)

ORM은 객체 관계 매핑을 의미한다. Java와 같은 객체지향 언어에서의 객체와 RDB의 테이블을 자동으로 매핑하는 방법이다.
클래스는 데이터베이스의 테이블과 매핑하기 위해 만들어진 것이 아니기 때문에 RDB의 테이블과 불일치가 존재할 수밖에 없다. ORM이 이러한 불일치를 해결하는 역할을 해준다.
ORM은 SQL 작성이 아닌 Java 코드(메서드)로 데이터를 조작할 수 있도록 도와준다.

ORM 기능

1. 객체-관계 매핑

• ORM은 객체와 데이터베이스 테이블 간의 매핑을 자동으로 처리한다. 즉, 클래스의 필드와 데이터베이스 테이블의 컬럼을 매핑하여 객체를 데이터베이스에 저장하고 검색할 수 있다.

2. SQL 생성 및 실행

• ORM은 개발자가 직접 SQL 쿼리를 작성하는 것을 대신하여 객체를 통해 데이터베이스에 대한 작업을 수행한다. ORM은 개발자가 객체 지향적인 방식으로 데이터를 다룰 수 있도록 SQL을 자동으로 생성하고 실행한다.

3. 데이터베이스 트랜잭션 관리

• ORM은 데이터베이스 트랜잭션을 관리하여 데이터의 일관성과 무결성을 유지한다. 개발자는 복잡한 트랜잭션 관리를 신경 쓰지 않고도 안전하게 데이터를 다룰 수 있다.

4. 성능 최적화

• ORM은 데이터베이스와의 통신을 최적화하여 성능을 향상시킨다. 데이터를 로딩하는 방식이나 쿼리의 실행 계획을 최적화하여 빠른 데이터 액세스를 제공한다.

ORM 장점

1. 개발 생산성 향상

• ORM을 사용하면 SQL 쿼리를 직접 작성하는 번거로움을 줄일 수 있으며, 객체 지향 프로그래밍 언어의 특징을 활용하여 개발을 빠르게 진행할 수 있다.

2. 유지보수성 향상

• ORM을 사용하면 데이터베이스 스키마의 변경에 대한 영향을 최소화할 수 있으며, 코드의 재사용성과 유지보수성을 높일 수 있다.

3. 플랫폼 독립성

• ORM은 다양한 데이터베이스에 대한 지원을 제공하므로, 애플리케이션의 플랫폼을 변경하거나 데이터베이스를 교체할 때 유연성을 제공한다.

4. 보안 강화

• ORM을 사용하면 SQL Injection과 같은 보안 취약점을 방지할 수 있으며, ORM이 제공하는 보안 기능을 활용하여 데이터베이스 보안을 강화할 수 있다.

📌JPA(Java Persistence API)

JPA란 자바 ORM 기술에 대한 API 표준 명세를 의미합니다.
JPA는 ORM을 사용하기 위한 인터페이스를 모아둔 것이며, JPA를 사용하기 위해서는 JPA를 구현한 Hibernate, EclipseLink, DataNucleus 같은 ORM 프레임워크를 사용해야 합니다.
"인터페이스"이기 때문에 JPA를 사용하기 위해서는 JPA를 구현한 Hibernate, EclipseLink, DataNucleus와 같은 ORM 프레임워크를 사용해야 한다.

JPA의 장점

1. 생산성이 뛰어나고 유지보수가 용이하다. 객체 중심 설계에 더 집중할 수 있기 때문이다.
2. DBMS에 대한 종속성이 줄어든다.
   ⇒ DB쿼리문을 코드단에서 해결이 가능하다. DBMS에서 DB만 생성하고, 테이블 생성&관리등 많은 부분들을 코드단에서 관리가 가능하다.
   

JPA의 단점

1. JPA를 학습하려면 많은 노력이 든다.
2. 복잡한 쿼리를 사용할 경우 불리하다.
   ⇒ 하나의 테이블에서는 이 정보, 다른 테이블에서는 이 정보를 가져와 하나의 데이터 객체로 만들기가 어렵다. SQL문에서는 join함수로 쿼리 한 줄이면 끝난다.
3. 잘못 사용하면 성능이 떨어질 수도 있다.

📌영속성 컨텍스트

JPA에서는 테이블과 매핑되는 엔티티 객체 정보를 영속성 컨텍스트를 통해 애플리케이션 내에서 오래 지속되도록 보관한다.
영속성 컨텍스트는 JPA를 이해하는데 가장 중요한 용어이다.

• 영속성 컨텍스트는 논리적인 개념
• 눈에 보이지 않음
• 엔티티 매니저를 통해 영속성 컨텍스트에 접근

엔티티의 생명주기

• 비영속(new/transient) : 영속성 컨텍스트와 전혀 관계가 없는 새로운 상태
• 영속(managed) : 영속성 컨텍스트에 관리되는 상태
• 준영속(detached) : 영속성 컨텍스트에 저장되었다가 분리된 상태
• 삭제(remove) : 삭제된 상태

EntityManager의 주요 역할

• persist(): 엔티티를 영속성 컨텍스트에 저장
• find(): 영속성 컨텍스트 또는 데이터베이스에서 엔티티 조회
• remove(): 엔티티를 영속성 컨텍스트에서 제거
• merge(): 준영속 상태의 엔티티를 다시 영속 상태로 변경
• detach(): 엔티티를 준영속 상태로 전환

JPA의 데이터 변경 감지

• 영속성 컨텍스트는 엔티티 객체의 상태를 추적합니다.
• 트랜잭션이 커밋되면, JPA는 영속성 컨텍스트에서 변경된 엔티티를 찾아 SQL을 생성하고 데이터베이스와 동기화합니다.

Member member = em.find(Member.class, 1L); // 영속성 컨텍스트에서 조회
member.setName("Alice"); // 엔티티 상태 변경

em.getTransaction().commit(); // 변경 감지를 통해 UPDATE SQL 실행

영속성 컨텍스트는 JPA의 성능 최적화 기법에 기여

• 1차 캐시: 동일 트랜잭션 내에서 조회된 엔티티를 캐싱해, 데이터베이스 조회 비용을 줄임.
• 쓰기 지연: 트랜잭션 커밋 시점에 한 번에 SQL 실행.
• 지연 로딩 (Lazy Loading): 실제로 필요한 시점에만 데이터를 조회.

📌N+1 문제란?

연관 관계에서 발생하는 이슈로 연관 관계가 설정된 엔티티를 조회할 경우에 조회된 데이터 갯수(n) 만큼 연관관계의 조회 쿼리가 추가로 발생하여 데이터를 읽어오게 된다. 즉, 1번의 쿼리를 날렸을 때 의도하지 않은 N번의 쿼리가 추가적으로 실행되는 것이다. 이를 N+1 문제라고 한다.

When 언제 발생하는가?

• JPA Repository를 활용해 인터페이스 메소드를 호출할 때(Read 시)

Who 누가 발생시키는가?

• 1:N 또는 N:1 관계를 가진 엔티티를 조회할 때 발생

How 어떤 상황에 발생되는가?

• JPA Fetch 전략이 EAGER 전략으로 데이터를 조회하는 경우
• JPA Fetch 전략이 LAZY 전략으로 데이터를 가져온 이후에 연관 관계인 하위 엔티티를 다시 조회하는 경우

Why 왜 발생하는가?

• JPA Repository로 find 시 실행하는 첫 쿼리에서 하위 엔티티까지 한 번에 가져오지 않고, 하위 엔티티를 사용할 때 추가로 조회하기 때문에.
• JPQL은 기본적으로 글로벌 Fetch 전략을 무시하고 JPQL만 가지고 SQL을 생성하기 때문에.

EAGER(즉시 로딩)인 경우

1. JPQL에서 만든 SQL을 통해 데이터를 조회
2. 이후 JPA에서 Fetch 전략을 가지고 해당 데이터의 연관 관계인 하위 엔티티들을 추가 조회
3. 2번 과정으로 N + 1 문제 발생

User(사용자)와 Order(주문)은 현재 일대다 관계로 연관관계가 존재한다. User 엔티티를 findAll()를 이용해 모든 사용자들을 조회하려고 할때, 원래는 사용자들에 관한 내용만 조회되어야 하는데 User의 연관관계 엔티티도 함께 조회되기 때문에 각 사용자마다 연관된 Order 엔티티도 조회가 함께 되는 것이다.

즉, 사용자가 5명일때, 사용자 조회에 대한 내용(1) + 각 5명의 사용자가 가지고 있는 주문 Entity에 대한 내용(5)으로 1+5 로 조회가 되어 1+N이 발생하는 것이다. 따라서, 연관관계까지 데이터를 모두 조회하는 즉시로딩일 경우 N+1 문제가 발생하는 것이다.

1. findAll()을 한 순간 select u from User u이라는 JPQL 구문이 생성되고 해당 구문을 분석한 select * from user 이라는 SQL이 생성되어 실행된다.
2. DB의 결과를 받아 User 엔티티의 인스턴스들을 생성한다.
3. User와 연관되어 있는 Order 도 로딩을 해야 한다.
4. 영속성 컨텍스트에서 연관된 User가 있는지 확인한다.
5. 영속성 컨텍스트에 없다면 2에서 만들어진 User 인스턴스들 개수에 맞게 select * from order where User_id = ? 이라는 SQL 구문이 생성된다. ( N+1 발생 )

LAZY(지연 로딩)인 경우

1. JPQL에서 만든 SQL을 통해 데이터를 조회
2. JPA에서 Fetch 전략을 가지지만, 지연 로딩이기 때문에 추가 조회는 하지 않음
3. 하지만, 하위 엔티티를 가지고 작업하게 되면 추가 조회가 발생하기 때문에 결국 N + 1 문제 발생

필요할때만 연관데이터를 가져오기 때문에 단순히 User 엔티티를 조회할때는 N+1 문제가 발생하지 않지만, 하위 엔티티인 Order를 조회하는 경우, Order엔티티는 프록시 객체이기 때문에 User를 조회하고 나서 Order를 조회하는 쿼리가 나가기 때문에 즉시로딩과 같이 N+1문제가 발생한다.

1. findAll()을 한 순간select u from User u 이라는 JPQL 구문이 생성되고 해당 구문을 분석한 select * from user 이라는 SQL이 생성되어 실행된다.
2. DB의 결과를 받아 User 엔티티의 인스턴스들을 생성한다.
3. 코드 중에서 User 의 Order 객체를 사용하려고 하는 시점에 영속성 컨텍스트에서 연관된 Order가 있는지 확인한다
4. 영속성 컨텍스트에 없다면 2에서 만들어진 User 인스턴스들 개수에 맞게 select * from order where User_id = ? 이라는 SQL 구문이 생성된다. ( N+1 발생 )

📌N+1 해결 방법

1. Fetch join

N+1 자체가 발생하는 이유는 한쪽 테이블만 조회하고 연결된 다른 테이블은 따로 조회하기 때문이다.
미리 두 테이블을 JOIN 하여 한 번에 모든 데이터를 가져올 수 있다면 애초에 N+1 문제가 발생하지 않을 것이다.
ex) select * from owner left join cat on cat.owner_id = owner.id

그렇게 나온 해결 방법이 FetchJoin 방법이다. 하지만 이는 jpaRepository에서 제공해주는 것은 아니고 JPQL로 작성해야 한다.

@Query("select o from Owner o join fetch o.cats")
List<Owner> findAllJoinFetch();

결과를 보면 쿼리가 1번만 발생하고 미리 owner와 pet 데이터를 조인(Inner Join)해서 가져오는 것을 볼 수 있다.

Fetch Join(패치 조인)의 단점

• 연관관계 설정해놓은 FetchType을 사용할 수 없다. Fetch Join을 사용하게 되면 데이터 호출 시점에 모든 연관 관계의 데이터를 가져오기 때문에 FetchType을 Lazy로 해놓는것이 무의미하다.
• 페이징 쿼리를 사용할 수 없다. 하나의 쿼리문으로 가져오다 보니 페이징 단위로 데이터를 가져오는것이 불가능하다.

2. @Entity Graph

@EntityGraph 의 attributePaths에 쿼리 수행시 바로 가져올 필드명을 지정하면 Lazy가 아닌 Eager 조회로 가져오게 된다. Fetch join과 동일하게 JPQL을 사용하여 query 문을 작성하고 필요한 연관관계를 EntityGraph에 설정하면 된다. 그리고 Fetch join과는 다르게 join 문이 outer join으로 실행되는 것을 확인할 수 있다.

@EntityGraph(attributePaths = "cats")
@Query("select o from Owner o")
List<Owner> findAllEntityGraph();

결과를 보면 쿼리가 1번만 발생하고 미리 owner와 pet 데이터를 조인(outerJoin)해서 가져오는 것을 볼 수 있다.

3. Fetch Join과 EntityGraph 사용시 주의할 점

Fetch Join과 EntityGraph는 JPQL을 사용하여 JOIN문을 호출한다는 공통점이 있다. 또한, 공통적으로 카테시안 곱(Cartesian Product)이 발생하여 Owner의 수만큼 Cat이 중복 데이터가 존재할 수 있다. 그러므로 중복된 데이터가 컬렉션에 존재하지 않도록 주의해야 한다.

※ 카테시안 곱
두 테이블 사이에 유효 join 조건을 적지 않았을 때 해당 테이블에 대한 모든 데이터를 전부 결합하여 테이블에 존재하는 행 갯수를 곱한만큼의 결과 값이 반환되는 것

출처

https://velog.io/@tmdwns1521/DAO%EC%99%80-ORM-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0
https://velog.io/@jeong-god/ORM%EA%B3%BC-JPA%EC%97%90-%EB%8C%80%ED%95%B4%EC%84%9C
https://victorydntmd.tistory.com/195
https://ittrue.tistory.com/254
https://s-y-130.tistory.com/184
https://jh2021.tistory.com/21
https://velog.io/@pdy000726/fetch-join-vs-EntityGraph