[JPA] JPA를 사용하는 이유

JPA를 사용하는 이유

현 상황

• 지금 시대는 객체를 관계형 DataBase에 저장한다.
• 관계형 DB는 SQL을 필수로 사용해야한다.
• 하지만 비슷한 Query가 수도없이 반복된다.

만약 이미 만들어져 있는 서버에 DTO를 수정해야한다면?

개발한 프로그램의 규모가 크면 클수록 방대한 양의 수정이 필요하게 된다.

객체 vs 관계

언어는 객체지향을 사용한다.(상속,다형성,정보은닉 ...)

데이터는 관계형 DB에 저장한다.

-> 패러다임의 불일치

관계형 DB에는 상속관계가 존재하지 않는다(있는 DB도 있긴 하지만 보통 없다.)

프로그램을 설계하고 객체구조를 만들어 놓으면 그 데이터들을 저장하기 위해 객체를 분해해서 관계형으로 다시 설계가 필요하다. 또한 저장된 데이터를 꺼내 쓰기 위해 중간에 Mapping작업이 필요하다.

-> 이러한 이유 때문에 상속관계를 잘 이용하지 않게된다.

연관관계

• 객체는 참조를 사용한다.
• DB테이블은 외래 키를 사용한다.

객체는 단방향으로만 조회할 수 있지만 DB는 양방향으로 조회할 수 있다.

이를 위해 객체를 테이블에 맞추어 설계한다. ex) table의 FK를 객체에 저장.

여러 이유에 의해 객체답게 모델링 할수록 매핑 작업만 늘어난다.

객체를 자바 컬렉션에 저장 하듯이 DB에 저장할 수는 없을까?

JPA

• Java Persistence API
• 자바 진영의 ORM 기술 표준

ORM?

• Object-relational mapping(객체 관계 매핑)
• 객체는 객체대로 설계
• 관계형 DB는 관계형 DB대로 설계
• ORM 프레임워크가 중간에서 매핑
• 대중적인 언어에는 대부분 ORM 기술이 존재한다.

JPA의 역할

• SELECT SQL 생성
• JDBC API 사용
• ResultSet 매핑
• 패러다임 불일치를 알아서 해결

=> Query를 거의 알아서 다 짜준다.

그래서 JPA를 왜 사용해야 하는지?

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

생산성 - JPA와 CRUD

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

유지보수

• 기존 : 필드 변경시 모든 SQL을 수정해야함.
• JPA : 필드만 추가하면 됨. SQL은 JPA가 처리.

성능

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

1차 캐시와 동일성 보장

• 같은 트랜잭션 안에서는 같은 엔티티를 반환 - 약간의 조회 성능 향상

  동일한 쿼리를 날리면 첫 결과는 DB에서 가져오지만 이후에는 캐시에서 가져옴

• DB Isolation Level이 Read Commit이어도 애플리케이션에서 Repeatable Read 보장

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

1. INSERT

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

2. UPDATE

• UPDATE, DELETE로 인한 로우(ROW) 락 시간 최소화
• 트랜잭션 커밋 시 UPDATE, DELETE SQL을 수행하고 바로 커밋

지연 로딩과 즉시 로딩

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

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

• 따라서 객체와 SQL 모두 매우 잘 다뤄야 한다.
• 자동으로 알아서 해준다고 해서 쉽게보고 넘어가면 안된다.
• JPA를 사용해서 어떤 로직을 수행시키면 내부적으로 어떤 쿼리가 날아가는지 다 알 수 있어야한다.

참고 자료 : TAcademy youtube