왜 JPA인가?

SQL 중심적인 개발의 문제점

---

관계형 DB를 사용하는 상황에서는 SQL에 의존적인 개발을 피하기 어렵다.
SQL의 객체화 / 객체의 SQL화, 반복적인 SQL 작성은 개발을 힘들게 한다.

 

관계형 DB가 등장한 배경과 객체지향이 등장한 배경 자체가 틀리다.

관계형 DB는 데이터를 잘 정교화해서 보관하는 것이 목표인 반면, 객체지향은 추상화, 캡슐화등을 통한 복잡성을 제어하기 위함이다.

 

개발을 진행함에 있어서 객체를 영구 보관하기 위해서는 여러 방법이 있지만, 결국 관계형 DB에 저장하는 것이 최선의 방법이다.

그렇다면 결국 객체를 SQL로 변환해야 하는 것일까? 개발자가 계속해서 SQL Mapper의 역할만 해야 하는 것일까?

 

또, 객체와 RDB의 차이를 보면, 상속, 연관관계, 데이터 타입 그리고 데이터 식별 방법이 있다.

예를 들어서, 객체를 상속 구조에 맞춰 모델링을 하고, 그에 맞는 DB설계를 했을 때, 어떤 Data를 등록할 때는 insert쿼리가 두 번 필요하며, 모든 테이블마다 각각의 조회 쿼리를 직접 만들어주어야 한다.

 

그 밖에도 연관관계 자체가 객체와 RDB는 틀리게 구성되어 있기 때문에 SQL을 직접 다루게 되면 엔티티의 신뢰성 문제와 더불어 계층을 분할하는 것이 어려워진다.

 

즉, 객체답게 모델링을 할수록 매핑 작업만 늘어난다.. 객체를 자바 컬렉션에 저장하듯이 DB에 저장할 수는 없을까?

그 해답이 바로 JPA다.

 

 

 

JPA

---

JPA는 Java persistence API의 줄임말로, 자바 진영의 ORM 기술 표준이다.

여기서 ORM이란, Object-Relational Mapping의 줄임말이다. 객체는 객체대로 설계하고, RDB는 RDB대로 설계하는데, ORM 프레임워크가 중간에서 매핑을 해준다.

즉, JPA는 Application과 JDBC 사이에서 동작한다.
( App -> JPA -> JDBC API -> SQL -> DB -> 결과 )

 

기존 자바에서 표준 스펙으로 EJB가 있었지만 성능, 사용성 모두 별로였다고.. 그러다가 개발자 중 한 명이 하이버네이트라는 오픈소스를 만들어 배포하게 되는데 선풍적인 인기를 끌자 자바에서 이 개발자를 데려와 JPA를 그대로 만들게 했고, 그렇게 자바 표준이 되었다. 

 

참고로 JPA는 인터페이스의 모음이고, JPA의 구현체는 3가지가 있는데, 하이버네이트 / EclipseLink / DataNucleus 이 그것이다.

 

 

JPA의 성능 최적화 기능

---

1. 캐싱기능

 

같은 트랜잭션 안에서는 같은 엔티티를 반환한다. (조회 성능 향상)
특정 Entity의 값을 조회하면, 같은 트랜잭션 내에서 캐시 기능으로 동일한 엔티티를 반환 (굉장히 짧은 시간)

 

2. 트랜잭션을 지원하는 쓰기 지연

 

트랜잭션을 커밋할 때까지 Insert SQL을 모은다. 메모리에 쌓아두었다가 커밋되는 순간 트랜잭션 한다.

 

3. 지연 로딩과 즉시 로딩

 

- 지연 로딩 : 객체가 실제 사용될 때 로딩

Member객체 안에 Team 객체가 포함되어 있을 때, Member 객체를 조회할 때는 Team 객체에 대해서는 조회하지 않는다. 그러나 만약 Member.getTeam() 으로 Team 객체에 접근할 때 그때서야 Team 객체를 조회하는 쿼리를 보낸다.

 

- 즉시 로딩 : Join SQL로 한 번에 연관된 객체까지 미리 조회

만약 특정 옵션을 켜면 위의 경우, Member를 조회할 때 Team까지 조회하도록 할 수 있다.

 

 

 

@ 출처 : inflearn 자바 ORM 표준 JPA 프로그래밍 - 기본편 (by 김영한님)