JPA 심화 - ORM(JDBC , JQuery Mapper)

DB 를 Java 앱과 연동하기 위해 JDBC 탄생🎉

JDBC(Java Database Connectivity)

• JDBC Driver는 여러 타입의 DB와 연결할 수 있는 기능을 제공

• 

• JDBC Driver Manager는 런타임 시점에

  • Connection(연결)을 생성하여 쿼리를 요청할 수 있는 상태를 만들어 주고
  • Statement(상태)를 생성하여 쿼리를 요청하게 해주고
  • ResultSet(결과 셋)을 생성해 쿼리 결과를 받아올 수 있게 해준다.
  • ⚠️ 꼭 사용 후에는 close()를 호출해 자원 해제를 해줘야 한다. ⚠️

JDBC 의 여러 문제로 QueryMapper 탄생 🎉

• JDBC로 직접 SQL을 작성했을 때의 문제
  • SQL 쿼리 요청 시 중복 코드 발생
  • DB 별 예외에 대한 구분 없이 Checked Exception(SQL Exception) 처리
  • Connection, Statement...등 자원 관리를 따로 해줘야 한다.
    • 안해주면 메모리가 꽉 차서 서버가 죽음
• 이러한 문제를 해결하기 위해 처음으로 Persistence Framework 등장!
  • Persistence Framework
    1. SQL Mapper : JDBC Template, MyBatis
    2. ORM : JPA, Hibernate
• SQL Mapper(Query Mapper)
  • SQL ↔️ Object
  • SQL 문과 객체의 필드를 매핑하여 데이터를 객체화

JDBC Template

• SQL Mapper 첫번째 주자로 JDBC Template 탄생
  • 쿼리 수행 결과와 객체 필드 매핑
  • RowMapper로 응답 필드 매핑 코드 재사용
  • Connection, Statement, ResultSet 반복적 처리를 대신 해준다.
  • ⚠️ BUT, 결과 값을 객체 인스턴스에 매핑하는데 여전히 많은 코드가 필요하다.
  • 

MyBatis

• SQL Mapper 두번째 주자로 MyBatis 탄생
  • 반복적인 JDBC 프로그래밍을 단순화
  • SQL 쿼리들을 XML 파일에 작성하여 코드와 SQL을 분리!
  • ⚠️ BUT, 결국 SQL을 직접 작성하는 것은 피곤,,,, -> DB 기능에 종속적 ⚠️
  • ⚠️ BUT, 테이블마다 비슷한 CRUD 반복, DB타입 및 테이블에 종속적 ⚠️
  • 

QueryMapper의 DB 의존성 및 중복 쿼리 문제로 ORM 탄생 🎉

• ORM 은 DB의 주도권을 뺏어왔다고 표현해도 과언이 아니다.
• ORM 은 DAO 또는 Mapper를 통해서 조작하는 것이 아니라 테이블을 아예 하나의 객체와 대응시킨다.
  

릴레이션을 객체로 매핑하려는 이유?

• 객체 지향 프로그래밍의 장점을 활용할 수 있다.
• 이를 통해, 비즈니스 로직 구현 및 테스트 구현이 편리하다.
• 각종 디자인 패턴을 사용하여 성능 개선 가능
• 코드 재사용 가능

⚠️ ORM이 해결해야하는 문제점과 해결책 ⚠️

상속의 문제

• 객체 : 객체 간에 멤버 변수나 상속관계를 맺을 수 있다.
• RDB : 테이블들은 상속 관계가 없고 모두 독립적으로 존재한다.

💁‍♀️ 해결 방법 : 매핑 정보에 상속 정보를 넣어준다.(@OneToMany, @ManyToOne)

관계 문제

• 객체 : 참조를 통해 관계를 가지며 방향을 가진다. (다대다 관계도 있음)
• RDB : 외래키(FK)를 설정하여 Join으로 조회 시에만 참조가 가능하다.(즉, 다대다는 매핑 테이블 필요)

💁‍♀️ 해결 방법 : 매핑 정보에 방향 정보를 넣어준다.(@JoinColumn,@MappedBy)

탐색 문제

• 객체 : 참조를 통해 다른 객체로 순차적 탐색이 가능하며 콜렉션도 순회한다.
• RDB : 탐색 시 참조하는 만큼 추가 쿼리나, join이 발생하여 비효율적이다.

💁‍♀️ 해결 방법 : 매핑/조회 정보로 참조탐색 시점을 관리한다.(@FetchType, fetchJoin())

밀도 문제

• 객체 : 멤버 객체 크기가 매우 클 수 있다.
• RDB : 기본 데이터 타입만 존재한다.

💁‍♀️ 해결 방법 : 크기가 큰 멤버 객체는 테이블을 분리하여 상속으로 처리한다.(@embedded)

식별성 문제

• 객체 : 객체의 hashCode 또는 정의한 equals() 메소드를 통해 식별
• RDB : PK로만 식별

💁‍♀️ 해결 방법 : PK를 객체 id로 설정하고 EntityManager는 해당 값으로 객체를 식별하여 관리한다. (@Id, @GeneratedValue)

대신 ORM이 얻은 최적화 방법

1차, 2차 캐시

• 1차 캐시, 2차 캐시를 조회한 후 없으면 DataSource에서 조회한다.
• 캐싱 기능은 객체지향 프로그래밍이 가진 가장 큰 장점이다.

1차 캐시

• 영속성 컨텍스트 내부에는 엔티티를 보관하는 저장소가 있는데 이를 1차 캐시라고 한다.
• 일반적으로 트랜잭션을 시작하고 종료할 때까지만 1차 캐시가 유효하다.
• 1차 캐시는 한 트랜잭션에서 계속해서 원본 객체를 넘겨준다.

2차 캐시

• 애플리케이션 범위의 캐시로, 공유 캐시라고도 하며, 애플리케이션을 종료할 때 까지 캐시가 유지된다.
• 2차 캐시는 캐시 한 객체 원본을 넘겨주지 않고 복사본을 만들어서 넘겨준다.
• 복사본을 주는 이유는 여러 트랜잭션에서 동일한 원본 객체를 수정하는 일이 없도록 하기 위해서이다.
• 2차 캐시 적용방법
  1. Entity에 @Cacheable 적용 후 설정 추가
  2. # application.yml spring.jpa.properties.hibernate.cache.use_second_level_cache: true # 2차 캐시 활성화 spring.jpa.properties.hibernate.cache.region.factory_class: XXX # 2차 캐시를 처리할 클래스를 지정 spring.jpa.propertie.hibernate.generate_statistics: true # 하이버네이트가 여러 통계 정보를 출력하게 해주는데 캐시 적용 여부를 확인할 수 있다.
  3. sharedCache.mode 설정

cache mode 종류

• 1. 종류	설명
     ALL	모든 엔티티를 캐시
     NONE	캐시를 사용하지 않음
     ENABLE_SELECTIVE	Cacheable(true)로 설정된 엔티티만 캐시를 적용
     DISABLE_SELECTIVE	모든 엔티티를 캐시하는데, Cacheable(false)만 캐시하지 않음
     UNSPECIFIED	JPA 구현체가 정의한 설정을 따른다.

  2. # application.yml spring.jpa.properties.javax.persistence.sharedCache.mode: ENABLE_SELECTIVE

영속성 컨텍스트(1차 캐시)를 활용한 쓰기 지연

• 영속성이란?
  데이터를 생성한 프로그램이 종료되어도 사라지지 않는 데이터의 특성을 말한다.
  영속성을 갖지 않으면,데이터는 메모리에만 존재하게 되고 프로그램이 종료되면 해당 데이터는 모두 사라지게 된다.
  그래서 우리는 데이터를 파일이나 DB에 영구 저장함으로써 데이터에 영속성을 부여한다.
• 

영속성 4가지 상태(비영속>영속>준영속|삭제)

1. 비영속(new/transient) - 엔티티 객체가 만들어져서 아직 저장되지 않은 상태로, 영속성 컨텍스트와 전혀 관계가 없는 상태
2. 영속(managed) - 엔티티가 영속성 컨텍스트에 저장되어, 영속성 컨텍스트가 관리할 수 있는 상태
3. 준영속(detached) - 엔티티가 영속성 컨텍스트에 저장되어 있다가 분리된 상태로, 영속성 컨텍스트가 더 이상 관리하지 않는 상태
4. 삭제(removed) - 엔티티를 영속성 컨텍스트와 데이터베이스에서 삭제하겠다고 표시한 상태

• 객체의 영속성 상태는 Entity Manager 의 메소드를 통해 전환된다.

• Raw JPA 관점

  • persist(), merge() > (영속성 컨텍스트에 저장된 상태) > flush() > (DB에 쿼리가 전송된 상태) > commit() > (DB에 쿼리가 반영된 상태)

• 쓰기 지연이 발생하는 시점

  • flush() 동작이 발새하기 전까지 최적화한다.
  • flush() 동작으로 전송된 쿼리는 더 이상 쿼리 최적화는 되지 않고, 이후 commit()으로 반영만 가능하다.

• 효과

  • 여러 개의 객체를 생서할 경우 모아서 한 번에 쿼리를 전송한다.
  • 영속성 상태의 객체가 생성 및 수정이 여러 번 일어나더라도 해당 트랜잭션 종료 시 쿼리는 1번만 전송될 수 있다.
  • 영속성 상태에서 객체가 생성되었다 삭제되었다면 실제 DB에는 아무 동작이 전송되지 않을 수 있다.
  • 즉, 여러 가지 동작이 많이 발생하더라도 쿼리는 트랜잭션당 최적화되어 최소 쿼리만 날라가게 된다.