[SPRING]자바 ORM 표준 JPA 프로그래밍 섹션1 (JPA 소개)

💡SQL 중심적인 개발의 문제점

1. 반복적인 CRUD 쿼리 작성 및 수정
   • 지속적으로 CRUD 쿼리를 작성하고 수정하는 반복적인 작업이 필요하다.
2. 자바 객체와 SQL 간의 변환
   • 자바 객체를 SQL 문으로 변환하고, SQL 결과를 다시 자바 객체로 매핑하는 과정이 반복된다.

💻  패러다임의 불일치

• 객체와 관계형 데이터베이스의 차이
  • 상속
  • 연관관계
  • 데이터 타입
  • 데이터 식별 방법

1. 상속

• 객체: 객체는 상속 구조를 명확하게 가지고 있다.
• 관계형 데이터베이스: 관계형 데이터베이스는 슈퍼타입 - 서브타입 관계를 사용하여 상속과 유사한 구조를 모델링 하지만, 진정한 상속 관계는 아니다.

문제 발생

• Album 객체 저장: Album 객체를 저장하려면, Album과 상위 클래스인 Item으로 분해하여 두 개의 INSERT 문을 작성해야 한다.
• Album 객체 조회: Album 객체를 조회하려면, Item과 Album 테이블을 조인하는 SQL을 작성하고, 각각의 객체를 생성해야 한다. 이는 Movie와 Book 객체에 대해서도 마찬가지이다.

JPA를 이용하여 문제 해결

• 저장: JPA는 하위 타입을 저장할 때 상위 및 하위 타입에 해당하는 INSERT 문을 실행하여 데이터를 적절히 분할 저장한다.

• 조회: 조회 시에는 필요한 테이블을 조인하여 데이터를 가져온다.

2. 연관관계

• 객체: 객체는 참조를 사용해서 다른 객체와 관계를 맺는다.
• 테이블: 테이블은 외래 키를 사용해서 다른 테이블과 관계를 맺는다.

문제 발생

• 테이블 중심 모델링: 테이블은 외래 키 컬럼을 사용하여 관계를 맺지만, 이로 인해 객체 간 참조가 없어 member.getTeam()을 통한 객체 그래프 탐색이 불가능하다.

    class Member {
        String id; //MEMBER_ID 컬럼 사용
        Long teamId; //TEAM_ID FK 컬럼 사용 //**
        String username;//USERNAME 컬럼 사용
    }
    class Team {
        Long id; //TEAM_ID PK 사용
        String name; //NAME 컬럼 사용
    }

• 객체지향 모델링: 객체 참조를 통한 모델링은 탐색이 가능하나, 객체를 저장하기 위한 SQL 변환 작업이 복잡해진다. 데이터베이스에 INSERT 하기 위해선 member.getTeam().getId()를 해야한다.

    class Member {
        String id; //MEMBER_ID 컬럼 사용
        Team team; //참조로 연관관계를 맺는다. //**
        String username;//USERNAME 컬럼 사용
    }
    Team getTeam() { return team;
    }
    class Team {
        Long id; //TEAM_ID PK 사용
        String name; //NAME 컬럼 사용
    }

JPA를 이용하여 문제 해결

• JPA는 객체 간의 참조를 외래 키로 변환하여 SQL 작성을 자동화하고, 조회 시 외래 키를 객체 참조로 자동 변환하여 처리한다.

3. 객체 그래프 탐색

• 객체는 자유롭게 객체 그래프를 탐색할 수 있어야 한다.
• 객체에서 소속된 팀을 조회하려면 참조를 사용해 연관된 팀을 찾는다.

문제 발생

• SQL을 직접 다룰 경우, 처음 실행한 SQL에 따라 탐색할 수 있는 객체 그래프의 범위가 제한된다. 예를 들어, Member와 Team만 조인한 SQL에서는 member.getTeam()은 가능하지만, 다른 객체 탐색은 불가능하다.

SELECT M.*, T.* 
   FROM MEMBER M
   JOIN TEAM T ON M.TEAM_ID = T.TEAM_ID
   
   
member.getTeam(); //OK 
member.getOrder(); //null

• 모든 객체를 미리 로딩할 수 없으므로, 상황에 따라 동일한 회원 조회 메서드를 여러벌 생성해야 한다. --> 케이스가 한두개가 아님 --> 진정한 의미의 계층 분할이 어려워짐

JPA를 이용하여 문제 해결

• JPA는 실제 객체 사용 시점까지 데이터베이스 조회를 미루는 지연 로딩 기능을 제공하여 필요할 때 추가적인 데이터 조회가 가능하게 한다.

4. 비교

• 데이터베이스: 각 로우(row)는 기본 키 값으로 구분된다.
• 객체: 객체는 주소 값(동일성 ==)과 내부 값(동등성 equals())으로 비교할 수 있다.

문제 발생

• 같은 키의 Member 객체를 여러 번 조회하면, 각 조회마다 다른 객체 인스턴스가 생성되어 비교 시 문제가 발생할 수 있다.

String memberId = "100";
Member member1 = memberDAO.getMember(memberId);
Member member2 = memberDAO.getMember(memberId);

member1 == member2; //다르다.

JPA를 이용하여 문제 해결

• JPA는 같은 트랜잭션 내에서 동일한 엔티티에 대한 조회 시 같은 객체 인스턴스를 반환함을 보장한다. 이로써 객체 비교의 일관성을 유지할 수 있다.

💡JPA의 성능 최적화 기능

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

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

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

같은 멤버를 조회하게 되면 처음에는 SQL 쿼리가 나가게 되고, 그 다음으로는 JPA가 SQL을 날리지 않고 JPA가 들고 있는 메모리 상에서 들고 와서 반환을 해준다. 즉, SQL은 한 번만 실행이 된다.

 

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

INSERT

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

 

 UPDATE

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

 

3. 지연 로딩(Lazy Loading)

• 지연 로딩: 객체가 실제 사용될 때 로딩된다. (ex. 멤버를 조회할 때 팀은 잘 조회를 안하는 경우 일단 멤버만 먼저 조회하고, 팀이 실제 사용될 때 조회)
• 즉시 로딩: JOIN SQL로 한번에 연관된 객체까지 미리 조회 (ex. 멤버랑 팀은 거의 무조건 같이 쓰는 경우 멤버를 조회하는 순간 팀도 같이 조회)

 

JPA 개발할 때는 보통 지연로딩으로 쫙 세팅을 해놓다가, 나중에 성능을 보고 하나의 쿼리로 하는 게 좋을 것 같다하면 거기만 즉시로딩으로 설정해줘서 최적화를 한다.