JPA 톺아보기

 

매일메일 백엔드 질문을 참고해 개인적으로 학습한 내용을 정리하였습니다.
오류가 있다면 언제든 피드백 주시면 바로 반영하겠습니다..!

 

 

 

시작하기에 앞서

 

JPA란?

 

JPA(Java Persistence API)는 자바 객체를 데이터베이스에 저장하고 불러오는 방법을 정의한 표준 API임

 

=> ORM(Object-Relational Mapping) 기술을 제공하는 자바의 공식 표준임

 

JPA는 자체적으로 동작하지 않고 Hibernate와 같은 구현체가 필요함

 

 

EntityManager란?

 

EntityManager에 대해 알기 위해선 Persistence Context에 대해 알아야함

 

Persistence Context는 엔티티를 영구 저장하는 환경으로 1차 캐싱, 쓰기 지연, 변경 감지를 통해 영속 로직을 효율적으로 할 수 있게 해줌

 

=> 이러한 효율적인 영속 로직 수행을 위해서 엔티티는 Persistence Context(영속성 컨텍스트)에 관리되어야함

이런 작업을 도와주는 것이 바로 EntityManager 임

 

=> 엔티티의 상태를 변경하고, Persistence Context와 상호작용함으로써 영속 로직을 수행하는 역할을 가지고있음

 

엔티티는 Persistence Context와 관련하여 4가지 상태(비영속, 영속, 준영속, 삭제)를 가질 수 있음

1. 비영속 상태는 엔티티 객체가 새로 생성되었지만, 아직 Persistence Context와 연관되지 않은 상태임
(데이터베이스와 관련이 없으며, 엔티티 객체는 메모리 상에만 존재)

ex. 

Member member = new Member("JunGyo");

2. 영속 상태는 엔티티 객체가 Persistence Context에 관리되고 있는 상태임
(엔티티의 변경 사항이 자동으로 데이터베이스에 반영됨)

ex.

em.persist(member); // 영속성 컨텍스트가 관리하는 엔티티가됨
em.merge(detachedMember); // 준영속 상태의 엔티티 (detached 상태)를 다시 영속 상태로 변경
em.find(Member.class, 1L); // 데이터베이스에서 엔티티를 조회

3. 준영속 상태는 엔티티 객체가 한 번 Persistence Context에 의해 관리되었지만, 현재는 Persistence Context와 분리된 상태임
(엔티티 객체의 변경 사항이 더 이상 데이터베이스에 반영되지 않음)

=> 영속성 컨텍스트 종료, 트랜잭션 종료 등으로도 준영속 상태로 전환됨

ex.

em.detach(member);
em.clear();
em.close();

4. 삭제 상태는 엔티티 객체가 Persistence Context에서 제거된 상태임
(엔티티 객체가 데이터베이스에서 삭제됨)

ex.

em.remove(member);

 

결론적으로 EntityManager는 Persistence Context의 1차 캐시로부터 엔티티를 조회할 수 있으며, 쓰기 지연 저장소에 있는 쿼리들을 flush하여 DB와 동기시킬 수 있음

또한, JPQL이나 Native Query를 이용해 직접 DB로부터 데이터를 불러올 수 도 있음

 

JPQL은 JPA가 지원하는 다양한 쿼리 방법 중 하나로 SQL이 테이블을 대상으로 쿼리했다면 엔티티 객체를 대상으로 쿼리하는 객체지향 쿼리임

=> 결국 JPQL은 SQL로 변환됨

 

Hibernate 란?

 

Hibernate는 JPA의 구현체 중 하나로, 객체와 RDB를 매핑하는 ORM 프레임워크임

 

• Hibernate는 JPA의 표준 명세를 구현한 라이브러리임
  
  
• JPA를 사용하면 구현체를 Hibernate, EclipseLink, OpenJPA 등으로 쉽게 교체 가능
  
  
• @Entity, @Table, @Column 같은 어노테이션을 활용해서 DB 테이블과 Java 클래스를 연결할 수 있음
  
  
• Hibernate는 SQL이 아니라 객체 지향적인 쿼리 언어 JPQL을 사용함
  (SQL도 사용은 가능)
  
  
• Lazy Loading (지연 로딩) 지원
  
  => 연관된 엔티티를 필요할 때만 조회하도록 설정할 수 있음
  
  

예를 들어 User와 Post라는 두 엔티티가 있다고 가정했을 때
User는 여러 개의 Post를 가질 수 있는 @OnetoMany 관계일 수 있음

이 때 Lazy Loading 작동 방식은

User 객체를 조회할 때 posts 목록은 바로 조회되지 않고 User 객체만 DB에서 가져오고
이후, user.getPosts()를 호출하려고 하면, 실제 DB에서 Post 데이터를 조회함

Lazy Loading의 장점으로는

처음에 필요한 데이터만 로드하므로 불필요한 DB 조회를 줄여 성능을 최적화 할 수 있고
관련된 데이터가 실제로 필요할 때만 로드되므로 메모리 사용을 줄일 수 있음

LazyLoading의 단점으로는

N+1 문제가 있음

=> 부모 엔티티를 로드한 후에 자식 엔티티를 접근할 때 추가 쿼리가 발생하여 성능 저하가 일어날 수 있음

 

• Hibernate는 자동으로 트랜잭션을 관리하고, 데이터베이스 성능을 높이기 위해 1차 캐시, 2차 캐시를 지원함

 

Spring Data JPA란?

 

Spring Data JPA는 JPA를 더 쉽게 사용할 수 있도록 도와주는 Spring 기반의 라이브러리임

 

=> 데이터베이스와 객체(Entity) 간의 매핑을 더 편하게 처리할 수 있도록 JPA를 감싸는 기술임

JPA의 단순 반복적인 작업을 자동화해 주는 라이브러리라고 보면됨

=> JpaRepository만 만들면 메서드 이름만으로도 쿼리를 자동 생성 해주기에 코드가 훨씬 간결해지고 유지보수가 쉬워져서 생산성이 향상됨
(EntityManager를 직접 쓰지 않아도 JpaRepository가 알아서 처리해줌)

결론은 Spring에서 JPA를 사용할거면 Spirng Data JPA도 함께 쓰자!

 

 

JPA(Spring Data JPA)를 사용하지 않는 경우는 어떤식으로?

 

 

JPA(Spring Data JPA)를 사용하지 않으면, 데이터베이스와 직접 SQL을 주고 받아야함

=> JPA는 자바 객체(Entity)와 DB 테이블을 자동으로 매핑해주기에 SQL을 직접 작성할 필요 X

 

 

JPA 사용하지 않는 경우 크게 2가지 방법을 찾을 수 있었음

 

• JDBC(Java Database Connectivity)를 사용
  
  => JDBC는 SQL을 직접 써야 하고, Connection, Statement, ResultSet을 관리해야 해서 JPA에 비해 상대적으로 코드가 복잡
  
  (JPA도 결국 내부적으로 JDBC를 사용함)
  
  
• MyBatis 사용 (SQL Mapper)
  
  => MyBatis는 SQL을 XML 파일이나 어노테이션으로 따로 관리해서, SQL을 쉽게 작성할 수 있음
  (똑같이 SQL을 직접 작성해야하지만 JDBC보다 깔끔하게 SQL을 관리할 수 있음)
  
  

그렇다면 무조건 JPA만 써야할까?

 

 

JPA를 쓰면 좋은 경우

 

• CRUD가 많고 SQL을 최대한 자동화 하고 싶을 때 (Spring Data JPA 사용)
  
  
• 객체 중심으로 개발하고 싶을 때 (OOP 스타일 유지 가능)
  
  => SQL 없이 객체 중심으로 개발 가능
  
  
• 유지보수를 쉽게 하고 싶을 때 (SQL을 최소화하고 코드만 관리)

 

JPA를 안 쓰는 경우

 

• 복잡한 SQL 튜닝이 필요한 경우
  
  
• 레거시 프로젝트에서 기존 SQL을 유지해야 할 때
  
  
• 단순한 데이터 조회만 필요하고, ORM이 오히려 오버헤드가 클 때

 

---

 

https://velog.io/@adam2/JPA는-도데체-뭘까-orm-영속성-hibernate-spring-data-jpa

 

 

=> JPA는 기본적으로 RDB와 매핑을 위한 기술이기에 NoSQL은 JPA를 확장하여 NoSQL 지원을 추가한 라이브러리 (ex. Hibernate-OGM) 를 사용하거나 전용 클라이언트 라이브러리 (ex. MongoDB Java Driver) 를 사용

또한, 그림을 살펴보면 JPA는 애플리케이션과 JDBC 사이에서 동작하고 있는데

개발자가 JPA를 사용하면, JPA 내부에서 JDBC API를 사용하여 SQL을 호출하여 DB와 통신함
(개발자가 직접 JDBC 사용 X)

 

JPA의 ddl-auto 옵션은 각각 어떤 동작을 하고 어떤 상황에서 사용해야 할까?

 

ddl-auto 옵션은 스프링 부트 애플리케이션에서 Hibernate와 같은 JPA 구현체를 사용할 때 데이터베이스 스키마 관리를 제어하는 설정임

(application.properties 또는 application.yml 파일에서 설정할 수 있음)

 

=> 다양한 값에 따라 DB 스키마에 대해 다른 동작을 수행함

 

• none 
  
  => 데이터베이스 스키마와 관련된 어떠한 작업도 수행하지 않음
  
  (수동으로 관리하고 싶을 때 유용하며, 프로덕션 환경에서 주로 사용)
  
  
• validate
  
  => 애플리케이션이 시작될 때, 엔티티 매핑이 데이터베이스 스키마와 일치하는지 검증하며 스키마 변경은 따로 수행 X
  
  (프로덕션 환경에서 엔티티와 데이터베이스 스키마가 일치하는지 확인하고 싶을 때 사용)
  
  
• update
  
  => 엔티티 매핑과 데이터베이스 스키마를 비교하여 필요한 경우 스키마를 업데이트함
  
  (기존 데이터는 유지되지만, 새로운 엔티티나 변경된 엔티티 필드는 스키마에 반영되므로 프로덕션 환경에서는 예기치 않은 스키마 변경을 방지하기 위해 주의가 필요함)
  
  
• create
  
  => 애플리케이션이 시작될 때 기존 스키마를 삭제하고 새로 생성함
  
  (기존 데이터가 모두 삭제되므로 프로덕션 환경에서는 사용하지 않고 개발 초기에 빈 데이터베이스 스키마를 반복적으로 생성해야할 때 유용함)
  
  
• create-drop
  
  => create와 유사하지만, 애플리케이션이 종료될 때 스키마를 삭제함
  
  (마찬가지로 프로덕션 환경에서는 사용하지 않고 테스트 환경에서 일시적인 데이터베이스 스키마가 필요한 경우 유용하며, 매 테스트 실행 시마다 깨끗한 데이터베이스 상태를 유지하고자 할 때 사용함)

 

프로덕션 환경에서 스키마 변경은 어떻게 해야할까?

 

스키마 변경이 필요할 때는 적절한 데이터베이스 마이그레이션 도구(Flyway, Liquibase 등)을 사용하여 제어된 방식으로 스키마를 관리하거나, 사용자가 없는 새벽에 스키마 변경 작업을 수동으로 진행하는 것이 더 안전할 수 있음

 

 

JPA의 N + 1 문제

 

연관 관계가 설정된 엔티티를 조회할 경우에, 조회된 데이터 개수(N) 만큼 연관 관계의 조회 쿼리가 추가로 발생하는 현상임

예를 들어, 블로그 게시글과 댓글이 있는 경우, 게시글을 조회한 후 각 게시글마다 댓글을 조회하기 위한 추가 쿼리가 발생할 수 있음

 

이를 N + 1 문제라고 함

 

쉽게 말하면 조회 시 1개의 쿼리를 생각하고 설계했는데 나오지 않아도 되는 조회의 쿼리가 N개가 더 발생하는 문제

 

findAll 메서드의 글로벌 패치 전략 별 N + 1 문제 상황

 

findAll 메서드는 spring data jpa에서 제공하는 repository의 메서드이고

글로벌 패치 전략(Global Fetch Strategy)은 JPA에서 연관된 엔티티를 어떻게 가져올 것인지를 결정하는 전략임

=> 즉시로딩, 지연로딩 방식이 있음

 

 

글로벌 패치 전략을 즉시로딩으로 설정하고 findAll()을 실행하면 N + 1 문제가 발생함

=> findAll()이 select u from User u 라는 JPQL 구문을 생성해서 실행하기 때문

 

(JPQL은 글로벌 패치 전략을 고려하지 않고 쿼리를 실행하는데 모든 User를 조회하는 쿼리 실행 후, 즉시로딩 설정을 보고 연관관계에 있는 모든 엔티티를 조회하는 쿼리를 실행하는 것임)

=> N + 1 문제는 결국 쿼리의 개수가 문제여서 즉시로딩이 무슨 상관이지라고 생각했는데 즉시로딩이 한 번의 쿼리로 모든 데이터를 가져오는게 아니라 (이건 fetch join) 자동으로 연관된 엔티티를 따로 가져오는 방식으로 여러 개의 쿼리가 실행되는걸로 이해하였음 

---

 

글로벌 패치 전략을 지연 로딩으로 설정하고 findAll()을  실행하면 N + 1 문제가 발생하지 않음

=> 연관관계에 있는 엔티티를 실제 객체 대신 프록시 객체로 생성하여 주입하기 때문
(프록시 객체는 나중에 데이터를 가져올 수 있도록 가짜로 만들어진 객체라고 생각하면됨)

 

하지만 이렇게 프록시 객체를 사용할 경우에 실제 데이터가 필요하여 조회하는 쿼리가 발생하고 N + 1 문제가 발생할 수 있음

 

즉시 로딩(EAGER)은 findAll() 실행시 N + 1 문제가 발생하고,

지연 로딩(LAZY)은 findAll() 실행만으로는 N + 1 문제가 발생하지 않지만, 이후 실제 데이터를 조회하면 발생함

 

N + 1 문제 해결 방법

 

N + 1 문제를 해결하기 위해서는 fetch join, @EntityGraph를 사용해볼 수 있음

 

fetch join은 연관 관계에 있는 엔티티를 한 번에 즉시 로딩하는 구문임

(JOIN을 강제하여 한 번의 쿼리로 해결)

select distinct u
from User u
left join fetch u.posts

 

 

@EnttiyGraph도 비슷한 효과를 만들어내며, 쿼리 메서드에 해당 어노테이션을 추가해 사용할 수 있음

 

@EntityGraph(attributePaths = {"posts"}, type = EntityGraphType.FETCH)
List<User> findAll();

 

 

Spring Data JPA에서 새로운 Entity인지 판단하는 방법은 무엇일까?

 

@Override
public boolean isNew(T entity) {

    if(versionAttribute.isEmpty()
          || versionAttribute.map(Attribute::getJavaType).map(Class::isPrimitive).orElse(false)) {
        return super.isNew(entity);
    }

    BeanWrapper wrapper = new DirectFieldAccessFallbackBeanWrapper(entity);

    return versionAttribute.map(it -> wrapper.getPropertyValue(it.getName()) == null).orElse(true);
}

(JpaMetamodelEntityInformation -> @Version 필드의 값이 null 인지 여부로 판단)

 

 

새로운 Entity인지 여부는 JpaEntityInformation의 isNew(T entity)에 의해 판단됨

=> 다른 설정이 없으면 JpaEntityInformation의 구현체 중 JpaMetamodelEntityInformation 클래스가 동작

 

@Version이 사용된 필드가 없거나 @Version이 사용된 필드가 primitive 타입(기본형 ex. int, long 등)이면 AbstractEntityInformation의 isNew()를 호출함

=> @Version이 사용된 필드가 wrapper class(ex. Integer, Long 등)이면 null 여부를 확인

Primitive Type은 Stack에 위치하며 null이 허용되지 않고 (객체 X) Wrapper Class는 Heap에 위치하며 null이 허용됨 (객체 O)

 

@Version이란 Optimistic Lock을 적용할 때 사용하는 어노테이션으로 동시성 제어를 위해 사용되며, 트랜잭션 충돌을 방지할 수 있음

=> 엔티티가 저장될 때마다 @Version 필드 값이 증가하기에 @Version 필드가 null이면 새로운 엔티티라고 판단할 수 있음

 

public boolean isNew(T entity) {

    Id id = getId(entity);
    Class<ID> idType = getIdType();

    if (!idType.isPrimitive()) {
        return id == null;
    }

    if (id instanceof Number) {
        return ((Number) id).longValue() == 0L;
    }

    throw new IllegalArgumentException(String.format("Unsupported primitive id type %s", idType));
}

 

(AbstractEntityInformation -> @Id 값이 null인지 여부로 판단)

 

@Version이 사용된 필드가 없어서 AbstractEntityInformation 클래스가 동작하면 @Id 어노테이션을 사용한 필드를 확인해서 primitive 타입이 아니라면 null 여부, Number의 하위 타입이면 0인지 여부를 확인함

 

=> 위 코드에서 primitive 타입을 어떻게 다루는걸까 궁금했는데 getId(entity) 메서드가 자동으로 Wrapper Class로 Auto-Boxing (변환) 된다고 함 그래서, instanceof로 Number 라면 0인지 확인 (long, int 같은 primitive 타입이 0으로 초기화 되므로)

 

 

@GeneratedValue 어노테이션으로 키 생성 전략을 사용하면 DB에 저장될 때 id가 할당되기 때문에 DB에 저장되기 전 메모리에서 생성된 객체 id가 비어있음

 

=> isNew()는 true가 되어 새로운 entity로 판단

 

직접 ID를 할당하는 경우에는 어떤식으로 동작할까?

public class JpaPersistableEntityInformation<T extends Persistable<ID>, ID> 
        extends JpaMetamodelEntityInformation<T, ID> {

    public JpaPersistableEntityInformation(Class<T> domainClass, Metamodel metamodel, 
            PersistenceUnitUtil persistenceUnitUtil) {
        super(domainClass, metamodel, persistenceUnitUtil);
    }

    @Override
    public boolean isNew(T entity) {
        return entity.isNew();
    }

    @Nullable
    @Override
    public ID getId(T entity) {
        return entity.getId();
    }
}

 

JpaPersistableEntityInformation의 isNew()가 동작함

 

 

키 생성 전략을 사용하지 않고 직접 ID를 할당하는 경우 새로운 entity로 간주되지 않음

=> 위에서도 적어놨지만 @GeneratedValue 어노테이션으로 만든 키는 DB에 저장되기전 메모리에서 생성된 객체의 id가 비어있지만 이렇게 id를 수동으로 할당하면, entity가 메모리에서부터 id를 가지고 있기에 기본 JPA 판단 기준대로라면 ID가 존재하므로 "기존 데이터"로 간주됨

 

public interface Persistable<ID> {
    ID getId();
    boolean isNew();  // 새로운 엔티티인지 확인하는 메서드
}

 

import org.springframework.data.domain.Persistable;
import jakarta.persistence.*;

@Entity
public class MyEntity implements Persistable<Long> {

    @Id
    private Long id;

    @Transient  // JPA가 이 필드를 DB 컬럼으로 저장하지 않도록 함
    private boolean isNew = false;

    public MyEntity(Long id) {
        this.id = id;
        this.isNew = true;  // 수동으로 ID 할당할 때 새로운 엔티티로 간주
    }

    @Override
    public boolean isNew() {
        return this.isNew;
    }

    @Override
    public Long getId() {
        return this.id;
    }

    @PostPersist // JPA에서 엔티티가 처음 persist된 후 실행되는 메서드
    @PostLoad // JPA에서 엔티티가 DB에서 조회(로딩)된 후 실행되는 메서드
    public void markNotNew() {
        this.isNew = false;  // 저장되거나 로드된 후에는 기존 엔티티로 간주
    }
}

 

이 때는 위와 같이 Entity에서 Persistable<T> 인터페이스를 구현해서 JpaMetamodelEntityInformation 클래스가 아닌 JpaPersistableEntityInformation의 isNew()가 동작하도록 해야함

 

Spring Data JPA가 isNew()를 호출해주는 부분은 제공되지만, isNew()가 어떻게 동작할지는 직접 구현해야 함

 

 

그럼 여기서 궁금증이 드는 부분이 있을 수 있음

Entity가 Persistable을 구현했는지 어떻게 판별하고 흐름이 뭘까?

 

Spring Data JPA가 Entity 정보를 처리하는 흐름

 

우선 애플리케이션 시작 시 JpaRepositoryFactory가 SimpleJpaRepository를 생성하게됨

 

Spring Data JPA에서는 JpaRepository를 구현하는 인터페이스가 있으면, 자동으로 프록시(proxy) 객체를 생성해서 JpaRepositoryFactory에서 처리하도록함

JpaRepositoryFactory는 요청받은 엔티티 타입에 맞게 적절한 리포지토리 구현체를 생성하는데, 이때 기본적으로 SimpleJpaRepository를 사용함

즉, 애플리케이션 시작 시 JpaRepositoryFactory가 SimpleJpaRepository를 생성해서 빈(bean)으로 등록

 

public class JpaRepositoryFactory extends RepositoryFactorySupport {

    private final EntityManager em;
    private final JpaMetamodelMappingContext context;

    public JpaRepositoryFactory(EntityManager entityManager) {
        this.em = entityManager;
        this.context = new JpaMetamodelMappingContext(entityManager.getMetamodel());
    }

    @Override
    protected <T, ID> JpaEntityInformation<T, ID> getEntityInformation(Class<T> domainClass) {
        Metamodel metamodel = em.getMetamodel();
        PersistentEntity<T, ID> entity = context.getRequiredPersistentEntity(domainClass);

        return Persistable.class.isAssignableFrom(domainClass)  // ✅ Persistable 인터페이스 구현 여부 확인
            ? new JpaPersistableEntityInformation<>(domainClass, metamodel, em.getPersistenceUnitUtil()) // ✅ Persistable 사용 시
            : new JpaMetamodelEntityInformation<>(domainClass, metamodel, em.getPersistenceUnitUtil());  // ✅ 일반 엔티티
    }

    @Override
    protected Object getTargetRepository(RepositoryInformation information) {
        JpaEntityInformation<?, ?> entityInformation = getEntityInformation(information.getDomainType()); // ✅ 여기서 호출됨

        return new SimpleJpaRepository<>(entityInformation, em);  // ✅ SimpleJpaRepository 생성
    }

    @Override
    protected Class<?> getRepositoryBaseClass(RepositoryMetadata metadata) {
        return SimpleJpaRepository.class;
    }
}

getEntityInformation 부분에서 A.class.isAssignableFrom(B.class) => B가 A를 상속 또는 구현했다면 ture

이 때, Spring Data JPA는 Repository를 만들 때 Entity 정보를 가져오는 과정에서 해당 Entity가 Persistable을 구현했는지 자동으로 판단함

 

• Persistable을 구현했다면 JpaPersistableEntitiyInformation 사용
  
  
• Persistable을 구현하지 않았다면 JpaMetamodleEntityInformation 사용

 

이렇게 생성된 JpaEntityInformation 객체는 SimpleJpaRepository의 생성자로 전달됨 (밑의 코드 참고)

 

public class SimpleJpaRepository<T, ID> implements JpaRepository<T, ID> {
    
    private final JpaEntityInformation<T, ID> entityInformation;
    private final EntityManager em;

    public SimpleJpaRepository(JpaEntityInformation<T, ID> entityInformation, EntityManager em) {
        this.entityInformation = entityInformation; // ✅ 생성자에서 할당
        this.em = em;
    }
    
    @Override
    @Transactional
    public <S extends T> S save(S entity) {
        if (entityInformation.isNew(entity)) {
            em.persist(entity);
            return entity;
        } else {
            return em.merge(entity);
        }
    }
}

save 호출 시에는 SimpleJpaRepository의 save 메서드가 호출됨 (새로운 entity면 persist, 아니면 merge)

 

이후 엔티티 저장 요청이 오면, SimpleJpaRepository.save()가 실행되는데 

entityInformation.isNew(entity)를 그대로 사용하게됨

 

새로운 Entity인지 판단하는게 중요한 이유

 

위의 SimpleJpaRepository의 코드를 보면 알 수 있듯, SimpleJpaRepository의 save() 메서드에서 isNew()를 사용하여 persist를 수행할지 merge를 수행할지 결정함

 

=> 만약 ID를 직접 지정해주는 경우에는 신규 entity라고 판단하지 않기 때문에 merge를 수행

이 때 해당 entity는 신규임에도 불구하고 DB를 조회하기 때문에 비효율적임

따라서, 새로운 entity인지 판단하는 것은 중요한 부분임

 

예시 코드는 GPT 선생님의 힘을 빌렸습니다.