2. JPA란 무엇인가?

💡 인프런의 김영한 선생님 강의를 정리한 글입니다.

JPA란?

JPA(Java Persistence Api) = 자바 진영의 ORM 기술 표준
ORM (Object Relational Mapping) = 객체와 관계형 데이터베이스를 매핑한다는 뜻이다.

ORM 프레임워크가 객체와 관계형 데이터베이스 중간에서 매핑해줌
대중적인 언어에 대부분 ORM 기술이 존재함 (ex : typescript도 type orm으로 제공한다.)

 

---

📕 어플리케이션과 JDBC 사이에서 동작한다.

 

⛏ JPA 동작 - 저장

 

⛏ JPA 동작 - 조회

---

JPA 소개

[History]
EJB-엔티티 빈 (자바 표준) -> 하이버네이트 (오픈 소스) -> JPA(자바 표준)

---

💻 JPA는 표준 명세

JPA는 인터페이스의 모음이다. (껍데기)
JPA 2.1 표준 명세를 구현한 3가지 구현체가 있다. (하이버네이트, EclipseLink, DataNucleus)

---

JPA를 왜 사용해야 하는가

• SQL 중심적인 개발에서 객체 중심으로 개발
• 생산성
• 유지보수
• 패러다임의 불일치
• 성능
• 데이터 접근 추상화와 벤더 독립성
• 표준

1. 생산성

JPA와 CRUD

• 저장: jpa.persist(member)
• 조회: Member member = jpa.find(memberId)
• 수정: member.setName("변경할 이름")
• 삭제: jpa.remove(member)

 

2. 유지보수

기존 : 필드 변경시 모든 SQL 수정 해야한다.

public class Member {
    private String memberId;
    private String name;
    private String tel; // 추가

-- SQL에 TEL 직접 추가해야 함.
INSERT INTO MEMBER(MEMBER_ID, NAME, TEL) VALUES
SELECTR MEMBER_ID, NAME, TEL FROM MEMBER M
UPDATE MEMBER SET ... TEL = ?

JPA : 필드만 추가하면 된다. SQL은 JPA가 처리한다.

public class Member {
    private String memberId;
    private String name;
    private String tel; // 추가

-- JPA가 SQP에 TEL 을 추가해 줌..
INSERT INTO MEMBER(MEMBER_ID, NAME, TEL) VALUES
SELECTR MEMBER_ID, NAME, TEL FROM MEMBER M
UPDATE MEMBER SET ... TEL = ?

 

3. JPA와 패러다임의 불일치 해결

• JPA와 상속
• JPA와 연관관계
• JPA와 객체 그래프 탐색
• JPA와 비교하기1.

 

1. JPA와 상속 : 객체 상속 관계 - Table 슈퍼타입 서브타입 관계

[저장]

개발자가 할 일

jpa.persist(album);

나머진 JPA가 처리 (INSERT 쿼리를 2개로 쪼개줌)

INSERT INTO ITEM ...
INSERT INTO ALBUM ...

[조회]

개발자가 할일

Album album = jpa.find(Album.class, albumId);

나머진 JPA가 처리한다.

SELECT I.*, A.*
    FROM ITME I
    JOIN ALBUM A ON I.ITEM_ID = A.ITEM_ID

이렇게 객체와 관계형 데이터베이스의 패러다임을 JPA가 해결해 주고 있음.

 

2. JPA와 연관관계

연관관계 저장

member.setTeam(team);
jpa.persist(member);

 

3. JPA와 객체 그래프 탐색

객체 그래프 탐색

Member member = jpa.find(Member.class, memberId);
Team team = member.getTeam();

→ 신뢰할 수 있는 엔티티, 계층

class MemberService {
    ...
    public void process() {
        Member member = memberDAO.find(memberId);
        member.getTeam(); // 자유로운 객체 그래프 탐색
        member.getOrder().getDelivery();
    }
}

memberDAO안에서 JPA가 제공하는 find 메서드를 통해 멤버 객체를 가져온다면 객체그래프를 자유롭게 정말 다 탐색할 수 있음.

JPA는 지연로딩이라는 기능이 있어서 실제로 객체안의 객체를 조회하는 시점에 SQL이 나가서 데이터가 채워지는 기능을 제공해서, 자유롭게 객체 그래프를 탐색할 수 있다.

이제 JPA를 통해 조회한 객체는 믿을 수 있다.

 

4. JPA와 비교하기

String memberId = "100";
Member member1 = jpa.find(Member.class, memberId);
Member member2 = jpa.find(Member.class, memberId);

member1 == membe2; // true

동일한 트랜잭션에서 조회한 엔티티는 같음을 보장한다.

 

4. JPA와 성능 최적화 기능

1. 1차 캐시와 동일성(identity) 보장
2. 트랜잭션을 지원하는 쓰기 지연(transactional write-behind)
3. 지연 로딩(Lazy Loading)

JPA는 어플리케이션과 JDBC 사의의 중간계층에 있다. 그래서 JPA를 쓰면 성능이 더 떨어지지 않을까? 고민할 수 있다.
하지만 이 중간 계층에 있으면 모아서 쏘는 버퍼링과 데이터를 읽을 때 캐싱을 할 수 있다. (마치 CPU와 메모리 구조와 비슷하다.)

따라서 JPA를 사용하면 오히려 더 성능을 최적화 할 수 있다.

 

1. 1차 캐시와 동일성 보장

1. 같은 트랜잭션 안에서는 같은 엔티티를 반환 - 약간의 조회 성능 향상
2. DB Isolation Level이 Read Commit이어도 애플리케이션에서 Repeatable Read 보장

String memberId = "100";
Member m1 = jpa.find(Member.class, memberId); // SQL
Member m2 = jpa.find(Member.class, memberId); // 캐시

println(m1 == m2) // true

→ SQL(SELECT) 1번만 실행

근데 이건 우리가 알던 캐시가 아니다. 트랜잭션동안, 고객을 조회하고 빠져나간다. 그 트랜잭션 사이에서의 동일성을 보장해 주는 것이기 때문에 사실상 굉장히 짧은 시간의 캐싱이다. 그래서 사실 실무에서 성능적으로 그렇게 큰 도움은 안된다.

 

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

1. 트랜잭션을 커밋할 때까지 INSERT SQL을 모음
2. JDBC BATCH SQL 기능을 사용해서 한번에 SQL 전송

transaction.begin(); // [트랜잭션] 시작

em.persist(memberA);
em.persist(memberB);
em.persist(memberC);
// 여기까지 INSERT SQL을 데이터베이스에 보내지 않는다.

// 커밋하는 순간 데이터베이스에 INSERT SQL을 모아서 보낸다.
transaction.commit(); // [트랜잭션] 커밋

네트워크로 한방에 보낸다. (하나씩 보내면 비효율)

jpa는 멤버 a,b,c를 메모리에 쌓아뒀다가, 커밋이 되는 순간, 쿼리3개를 한방에 네트워크로 보내버린다. (JDBC BATCH SQL을 통해)

개발자가 디테일한 코드를 신경쓰지 않고 옵션하나만 켜주면 된다.

 

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

1. UPDATE, DELETE로 인한 로우(ROW)락 시간 최소화
2. 트랜잭션 커밋 시 UPDATE, DELETE SQL 실행하고, 바로 커밋

transaction.begin(); // [트랜잭션] 시작

changeMember(memberA);
deleteMember(memberB);
비즈니스_로직_수행(); // 비즈니스 로직 수행 동안 DB 로우 락이 걸리지 않는다.

// 커밋하는 순간 데이터베이스에 UPDATE, DELETE SQL을 보낸다.
transaction.commit(); // [트랜잭션] 커밋

 

3. 지연로딩과 즉시 로딩

• 지연 로딩 : 객체가 실제 사용될 때 로딩
• 즉시 로딩 : JOIN SQL로 한번에 연관된 객체까지 미리 조회

// 지연 로딩
Member member = memberDAO.find(memberId); // SELECT * FROM MEMBER
Team team = member.getTeam();
String teamName = team.getName(); // SELECT * FROM TEAM

// 즉시 로딩
Member member = memberDAO.find(memberId); // SELECT M.*, T.* FROM MEMBER JOIN TEAM ...
Team team = member.getTeam();
String teamName = team.getName();

지연 로딩은 실제로 팀객체에서 해당 값들에 접근할 때 JPA에서 SQL을 그 시점에 날려서 데이터를 채워 주고 그 값을 반환해 준다.

스프링의 AOP 처럼 프록시 기술을 하이버네이트가 써서 이런 문제를 해결해 준다.

근데 이 지연로딩의 문제는 SQL이 두번 나가므로 네트워크를 2번 탄다.

근데, 만약 우리가 어플리케이션을 개발할 때, 거의 99% 이상이 멤버를 조회할 때마다 팀을 같이 쓴다면? 그냥 멤버를 조회할때 한방 쿼리로 팀까지 조인해서 가져오는게 맞다.

JPA에서 옵션을 키면 쿼리가 즉시로딩으로 한번에 멤버와 팀을 가져온다.

JPA사용하기 전 개발자들은 이 전략을 미리 정해놓고 가지않아서 중간에 바꾸게 되면 코드를 정말 많이 바꿔야 했음 (객체 - 테이블 맵핑 작업..)

JPA는 옵션하나 끄고 켜고로 튜닝이 가능하다.

실제로 애플리케이션 개발할때 전부 지연로딩으로 쫙 짜놨다가 실제로 최적화 할때 즉시 로딩이 필요한 부분을 찾아서 적용한다.

---

결론 : ORM은 객체와 RDB 두 기둥위에 있는 기술이다.

JPA만 잘 안다고 해서 잘 할 수 있는 것도 아니고, RDB만 알아도 객체지향적 설계를 모르면 결국 유지보수성이 떨어진다. 이 둘 사이의 밸런스를 정말 잘 맞춰야한다.

객체 애플리케이션은 중간에 바뀔 수 도있지만, 관계형 데이터베이스에 저장될 데이터는 훨씬 오래 살아남기 때문에, JPA를 공부하더라도 관계형 데이터베이스에 대한 공부는 꾸준히 공부 해야 한다.

그래서 이 ORM은 객체와 관계형 데이터베이스 두가지를 정말 잘 아는 상태에서 써야 한다.