잡학다식 개발일지

DB Lock 이란?

📌 DB Lock은 여러 트랜잭션이 동시에 같은 자원에 접근할 때 데이터 무결성(정합성)을 보장하기 위해 사용되는 메커니즘

• 쉽게 말해, 어떤 사용자가 데이터를 사용하고 있는 동안에는 다른 사용자가 그 데이터를 동시에 수정하면 안 되기 때문에, ‘잠금’을 걸어서 충돌(Conflict)을 방지
• 여러 사용자가 동시에 DB를 사용하는 경우 같은 데이터를 동시에 수정하려고 시도하는 경우 충돌 제어 및 데이터의 일관성을 보장하기 위해 사용한다.

언제 Lock을 사용하는가?

• 동시에 읽기/쓰기가 빈번하게 일어나는 중요한 테이블에 대해, 데이터 무결성을 엄격히 보장해야 할 때.
• 은행 이체, 재고 관리, 주문 처리와 같이 동시에 발생하면 안 되는 시나리오를 제어할 때.

• 불필요한 락은 성능 저하를 유발할 수 있으므로, 적절한 수준에서 사용하는 것이 중요
• DeadLock발생 여부를 꼭 확인해야함!

Lock의 생명주기

1 트랜잭션 시작!

• DB와의 트랜잭션을 시작
• 아직 특정 자원에 대한 락이 획득된 상태는 🙅

2 Lock 획득!

1. 쿼리 요청
2. Lock 체크
3. 대기 혹은 Lock 획득

3 트랜잭션 종료!

1. 트랜잭션 Commit 혹은 RollBack
2. 락 해제

Lock 종류

1. 낙관적 락 (충돌이 발생하지 않을 것이라고 가정)

• 데이터베이스의 락을 사용하는 것이 아닌 application 레벨에서 버전 관리
• 특정 작업을 수행하기 전에 별도의 락(lock)을 걸지 않고, 작업 완료 시점에서 데이터의 변경 여부를 확인하여 충돌 여부를 판단 (@Version 활용)
• 데이터 충돌이 거의 없을것이라고 가정한 경우 사용
  • LockModeType.OPTIMISTIC로 적용
• 충돌 시 ObjectOptimisticLockingFailureException 발생

2. 비관적 락 (충돌이 자주 발생할 것이라고 가정)

2.1 공유락(Shared Lock, S Lock)

• 여러 트랜잭션이 동시에 데이터를 읽기할 수 있지만, 쓰기 하려면 공유락을 해제하고 배타락으로 변경
• 다른 트랜잭션이 쓰기하려 하면 대기 상태
  • LockModeType.PESSIMISTIC_READ로 적용

2.2 배타락(Exclusive Lock, X Lock)

• 오직 한 트랜잭션만 해당 데이터를 읽거나 쓸 수 있음
• 다른 트랜잭션이 접근하려 하면 대기 상태
  • LockModeType.PESSIMISTIC_WRITE로 적용

3. 분산 락

• 여러 인스턴스나 분산 환경에서 락을 설정
• 데이터베이스에 직접 Lock을 걸지 않고, 외부에서 권한을 받아 처리
• Redis, **Zookeeper 등... 을 활용하여 적용**

낙관적 락 (Optimistic Lock)

1. 낙관적 락이란?

• 데이터의 충돌이 드물다고 가정하고, 충돌이 발생했을 때만 문제를 해결하는 방식.
• 일반적으로 버전 번호(version)를 활용하여 데이터를 갱신할 때 충돌을 감지.

2. 특징

1. 비교적 낮은 충돌 가능성 전제:
   • 동시에 데이터를 갱신하는 상황이 드물거나, 충돌 가능성이 낮은 환경에서 효과적.
2. 병렬성 보장:
   • 별도의 잠금(lock) 없이 데이터를 읽고, 이후 업데이트 시점에서만 충돌 여부를 확인.
3. 성능 우선:
   • 자원을 차단하지 않기 때문에, 읽기 작업과 병렬 처리에서 높은 성능을 보임.

3. 작동 방식

1. 데이터 조회:
   • 데이터와 함께 버전 번호를 가져옴.
2. 수정 및 업데이트 요청:
   • 데이터를 수정한 후, 저장 요청 시 버전 번호를 포함.
3. 버전 검증:
   • 데이터베이스에서 현재 데이터의 버전 번호와 요청에 포함된 버전 번호를 비교.
4. 성공/실패 여부:
   • 동일하면 업데이트 성공 → 버전 번호 증가.
   • 다르면 충돌 발생으로 간주하고 예외 처리.

4. 예제

4.1 데이터베이스 테이블 예제

CREATE TABLE example_table (
    id BIGINT PRIMARY KEY,
    data VARCHAR(255),
    version INT NOT NULL
);

4.2 JPA와 낙관적 락

import jakarta.persistence.*;

@Entity
public class ExampleEntity {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String data;

    @Version // 버전 관리용 필드
    private Integer version;

    // getters and setters
}

4.3 낙관적 락 업데이트 코드

import org.springframework.stereotype.Service;

import jakarta.persistence.EntityManager;
import jakarta.persistence.OptimisticLockException;

@Service
public class ExampleService {

    private final EntityManager entityManager;

    public ExampleService(EntityManager entityManager) {
        this.entityManager = entityManager;
    }

    public void updateData(Long id, String newData) {
        try {
            ExampleEntity entity = entityManager.find(ExampleEntity.class, id);
            entity.setData(newData);
            entityManager.merge(entity);
        } catch (OptimisticLockException e) {
            System.out.println("낙관적 락 충돌 발생!");
            // 충돌 처리 로직 추가
        }
    }
}

5. 장단점

6. 낙관적 락 vs 비관적 락

7. 사용 사례

1. 읽기 작업이 많은 환경:
   • 예: 상품 상세 페이지의 재고 확인.
2. 충돌 가능성이 낮은 환경:
   • 예: 사용자 개인 설정 업데이트.
3. 트랜잭션이 짧은 작업:
   • 예: 간단한 상태 변경 작업.

8. 학습하면 좋은 추가 주제

1. JPA의 @Version 어노테이션 활용:
   • 실무에서의 구체적 활용 방법과 사례.
2. 비관적 락(Pessimistic Lock):
   • 낙관적 락과 비교되는 개념 학습.
3. 분산 시스템에서의 락 구현:
   • Redis나 Zookeeper를 활용한 분산 락 구현.
4. 데드락과 충돌 처리 전략:
   • 충돌 및 데드락 방지를 위한 설계 패턴.

비관적 락 (Pessimistic Lock)

1. 비관적 락이란?

• 데이터 충돌이 자주 발생할 것으로 예상되는 환경에서, 데이터를 수정하거나 읽기 전에 잠금을 걸어 충돌을 방지하는 방법.
• 트랜잭션 동안 다른 트랜잭션이 데이터에 접근하지 못하도록 차단.
• 주로 데이터베이스에서 제공하는 락 메커니즘(예: SELECT ... FOR UPDATE)을 사용.

2. 특징

1. 잠금을 통해 충돌 방지:
   • 데이터 수정 전 잠금을 걸어 다른 트랜잭션의 접근을 차단.
2. 강력한 일관성 보장:
   • 동시에 같은 데이터를 수정하려는 작업 간 충돌을 완전히 방지.
3. 성능 비용 증가:
   • 트랜잭션이 오래 지속되면 잠금으로 인해 다른 트랜잭션이 대기 상태가 됨.

3. 작동 방식

1. 데이터 조회 시 잠금:
   • 데이터를 읽으면서 **배타적 잠금(Exclusive Lock)**을 설정.
2. 잠금 해제:
   • 트랜잭션이 종료될 때 잠금 해제.
3. 다른 트랜잭션 처리:
   • 잠금이 해제될 때까지 다른 트랜잭션은 대기 상태.

4. 비관적 락 구현 방법

4.1 데이터베이스에서 직접 사용

• SQL 예제:

-- 데이터 수정 전 잠금 설정
SELECT * FROM example_table
WHERE id = 1
FOR UPDATE;

4.2 JPA에서 비관적 락

• JPA 예제:

import jakarta.persistence.LockModeType;
import jakarta.persistence.EntityManager;

public ExampleEntity findByIdWithLock(Long id, EntityManager entityManager) {
    return entityManager.find(ExampleEntity.class, id, LockModeType.PESSIMISTIC_WRITE);
}

• Spring Data JPA 사용:

@Repository
public interface ExampleRepository extends JpaRepository<ExampleEntity, Long> {

    @Lock(LockModeType.PESSIMISTIC_WRITE)
    @Query("SELECT e FROM ExampleEntity e WHERE e.id = :id")
    ExampleEntity findByIdWithLock(@Param("id") Long id);
}

4.3 LockModeType 종류

5. 장단점

6. 낙관적 락 vs 비관적 락 비교

7. 사용 사례

1. 은행 시스템:
   • 계좌 잔액 수정처럼 데이터의 정확성이 중요한 작업.
2. 재고 관리:
   • 재고 수량을 줄이거나 늘릴 때 다른 트랜잭션이 동일 데이터를 수정하지 못하도록 차단.
3. 예약 시스템:
   • 좌석 예약, 호텔 방 예약 등에서 동일 리소스를 중복 예약하지 않도록 잠금.

8. 학습하면 좋은 추가 주제

1. 트랜잭션 격리 수준:
   • READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE의 차이.
2. 데드락 방지 전략:
   • 트랜잭션 순서 지정, 타임아웃 설정 등.
3. 낙관적 락과 비관적 락의 적절한 사용 전략:
   • 각 락의 장단점을 고려한 실무 적용 사례 분석.
4. 분산 환경에서의 락 관리:
   • Redis, ZooKeeper 등 분산 락 시스템 학습.

분산 락 (Distributed Lock)

1. 분산 락이란?

• 분산 시스템 환경에서 공유 자원에 대한 동시 접근을 제어하기 위해 사용하는 락 메커니즘.
• 동시에 여러 노드(서버)가 공유 자원에 접근하려는 상황에서 데이터의 무결성과 일관성을 보장.

2. 특징

1. 멀티 노드 환경:
   • 여러 노드가 동일한 자원에 접근 가능.
   • 분산 락을 통해 자원을 독점적으로 사용할 노드를 제어.
2. 데이터 일관성 보장:
   • 데이터의 충돌 방지 및 무결성 유지.
3. 중앙 관리:
   • 락 상태를 중앙에서 관리하거나 분산 환경에서 합의 프로토콜을 사용.

3. 동작 원리

1. 락 생성:
   • 특정 자원에 대해 락 생성 요청.
   • 락이 성공하면 해당 노드는 자원을 독점적으로 사용 가능.
2. 락 유지:
   • 락을 일정 시간 동안 유지.
   • 필요 시 갱신(Renewal) 가능.
3. 락 해제:
   • 자원 사용이 끝나면 락을 해제.
   • 타임아웃으로 자동 해제될 수도 있음.

4. 분산 락 구현 방식

4.1 데이터베이스 기반

• 방법: 데이터베이스 테이블에 락 상태를 저장.
• SQL 예제:

-- 락 생성
INSERT INTO distributed_lock (resource, lock_time) VALUES ('RESOURCE_ID', NOW());

-- 락 확인
SELECT * FROM distributed_lock WHERE resource = 'RESOURCE_ID';

-- 락 해제
DELETE FROM distributed_lock WHERE resource = 'RESOURCE_ID';

• 장점:
  • 별도 도구 없이 쉽게 구현 가능.
  • 트랜잭션과 연동하여 락 관리.
• 단점:
  • 성능 저하(데이터베이스 부하 증가).
  • 대규모 시스템에서는 비효율적.

4.2 Redis 기반

• 방법: Redis의 SETNX 명령어를 사용하여 락 생성.
• 예제:

# 락 생성
SET resource:lock "LOCKED" NX PX 10000

# 락 확인
GET resource:lock

# 락 해제
DEL resource:lock

• 장점:
  • 빠른 속도.
  • TTL(Time-To-Live) 설정으로 자동 해제 가능.
• 단점:
  • 단일 노드 Redis 사용 시 SPOF(Single Point of Failure) 발생 가능.
  • 클러스터 환경에서는 Redlock 알고리즘 필요.

4.3 ZooKeeper 기반

• 방법: 분산 락의 상태를 ZNode에 저장하여 관리.
• 예제:

# ZNode 생성 (락 획득)
create /locks/resource

# 락 해제
delete /locks/resource

• 장점:
  • 강력한 일관성 보장.
  • 분산 환경에 최적화.
• 단점:
  • 설정 및 관리 복잡.
  • ZooKeeper 설치 필요.

5. Redlock 알고리즘 (Redis 기반 분산 락)

• Redis 클러스터 환경에서 락의 일관성을 보장하는 알고리즘.

1. 여러 Redis 노드에 동일한 키로 락 생성 요청.
2. 과반수 이상의 노드에서 락 성공 시 락 획득.
3. TTL을 설정하여 자동으로 락이 해제되도록 설정.
4. 락 해제 시 모든 노드에서 락 해제.

6. 장단점

7. 분산 락 사용 사례

1. 동시에 한 번만 실행해야 하는 작업:
   • 예: 배치 처리, 데이터 마이그레이션.
2. 중복 실행 방지:
   • 예: 주문 처리, 결제 처리.
3. 리소스 공유:
   • 예: 파일 업로드/다운로드, 재고 관리.

8. 학습하면 좋은 추가 주제

1. 락 컨텐츠 관리 전략:
   • TTL 설정, 자동 해제 로직 구현.
2. ZooKeeper와 Redis의 비교:
   • 각 기술의 장단점 및 사용 사례 분석.
3. 분산 시스템에서의 일관성 모델:
   • 강한 일관성, 최종적 일관성(Final Consistency) 개념 이해.
4. Redlock 알고리즘 심화:
   • 클러스터 환경에서의 락 일관성 보장 방법.

격리 수준

트랜잭션 격리 수준 (Transaction Isolation Levels)

1. 트랜잭션 격리 수준이란?

• 트랜잭션 간의 상호작용에서 발생할 수 있는 데이터 충돌 문제를 방지하기 위해 데이터베이스가 제공하는 동시성 제어 메커니즘.
• 각 격리 수준은 데이터 일관성과 동시성 성능 간의 트레이드오프를 제공.

2. 주요 격리 수준과 특징

3. 주요 개념

1. Dirty Read:
   • 다른 트랜잭션이 아직 커밋되지 않은 변경 사항을 읽는 것.
   • 예시: A 트랜잭션이 데이터를 수정하고 커밋하지 않은 상태에서 B 트랜잭션이 수정된 데이터를 읽음.
2. Non-Repeatable Read:
   • 한 트랜잭션에서 같은 데이터를 두 번 읽었을 때, 값이 달라지는 현상.
   • 원인: 다른 트랜잭션에서 데이터를 수정하고 커밋한 경우.
3. Phantom Read:
   • 한 트랜잭션에서 동일한 조건으로 데이터를 조회했을 때, 새로운 데이터가 추가되거나 삭제되는 현상.
   • 원인: 다른 트랜잭션에서 데이터를 추가/삭제한 경우.

4. 격리 수준별 예제

4.1 READ UNCOMMITTED

-- A 트랜잭션
START TRANSACTION;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;

-- B 트랜잭션
START TRANSACTION;
SELECT balance FROM accounts WHERE id = 1; -- Dirty Read 발생

4.2 READ COMMITTED

-- A 트랜잭션
START TRANSACTION;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;

-- B 트랜잭션
START TRANSACTION;
SELECT balance FROM accounts WHERE id = 1; -- 커밋되지 않았으므로 읽을 수 없음

4.3 REPEATABLE READ

-- A 트랜잭션
START TRANSACTION;
SELECT balance FROM accounts WHERE id = 1; -- 1000
UPDATE accounts SET balance = balance - 100 WHERE id = 1;

-- B 트랜잭션
START TRANSACTION;
SELECT balance FROM accounts WHERE id = 1; -- A 트랜잭션의 변경 사항 보이지 않음

4.4 SERIALIZABLE

-- A 트랜잭션
START TRANSACTION;
SELECT balance FROM accounts WHERE id = 1;

-- B 트랜잭션
START TRANSACTION;
SELECT balance FROM accounts WHERE id = 1; -- 대기 상태 (A 트랜잭션 종료 후 실행)

5. 장단점 요약

6. 사용 사례

1. READ UNCOMMITTED:
   • 로그 데이터 분석, 캐시 처리 등 데이터 일관성이 덜 중요한 경우.
2. READ COMMITTED:
   • 일반적인 OLTP 시스템에서 기본 격리 수준으로 적합.
3. REPEATABLE READ:
   • 은행 시스템, 재고 관리 등 데이터 수정이 빈번한 환경.
4. SERIALIZABLE:
   • 강력한 일관성이 필요한 환경. 예: 금융 거래 시스템, 예약 시스템.

7. 학습하면 좋은 추가 주제

1. 트랜잭션 관리:
   • Spring에서의 트랜잭션 관리 (@Transactional)와 격리 수준 설정.
2. 트랜잭션과 락:
   • 비관적 락과 낙관적 락의 적용 방식.
3. MVCC (Multi-Version Concurrency Control):
   • MySQL, PostgreSQL에서 사용되는 동시성 제어 방식.
4. 데드락 방지 전략:
   • 순서 지정, 타임아웃 설정 등을 통한 데드락 방지.

QueryDSL(Query Domain-Specific Language)

📌 SQL, JPQL 같은 쿼리를 Java 코드로 작성할 수 있게 해주는 타입 안전한 ORM 기반 쿼리 빌더

• SQL을 Java 코드로 작성하면서, 가독성과 유지보수성을 대폭 개선할 수 있는 도구
• SQL-like 문법을 활용하여 가독성과 유지보수성을 향상시킵니다.

2. QueryDSL의 필요성

1. 문법 오류 방지:
   • QueryDSL은 컴파일 타임에 문법 오류를 검출하여, 런타임 오류를 예방합니다.
2. 필드 이름 변경 문제 해결:
   • 엔티티 필드가 변경되더라도, 쿼리가 자동으로 동기화됩니다.
3. 동적 쿼리 작성 용이성:
   • 여러 조건을 유연하게 조합할 수 있는 동적 쿼리를 간단히 작성할 수 있습니다.
4. 복잡한 쿼리 지원:
   • 조인, 서브쿼리, 그룹핑, 집계 등 복잡한 SQL 쿼리도 쉽게 작성 가능합니다.

3. QueryDSL의 장단점

4. QueryDSL 사용 예시

4.1 기본 설정

• build.gradle.kts

dependencies {
    implementation("com.querydsl:querydsl-jpa:5.0.0")
    kapt("com.querydsl:querydsl-apt:5.0.0:jpa")
}

kapt {
    arguments {
        arg("querydsl.entityAccessors", "true")
    }
}

4.2 기본 코드 예시

• 동적 쿼리 작성 예

import com.querydsl.jpa.impl.JPAQueryFactory;
import com.querydsl.core.BooleanBuilder;

public List<User> findUsers(JPAQueryFactory queryFactory, Integer age, String name) {
    QUser user = QUser.user;

    BooleanBuilder builder = new BooleanBuilder();
    if (age != null) {
        builder.and(user.age.gt(age));
    }
    if (name != null) {
        builder.and(user.name.eq(name));
    }

    return queryFactory.selectFrom(user)
            .where(builder)
            .fetch();
}

4.3 복잡한 쿼리 예

• 조인과 그룹핑

QOrder order = QOrder.order;
QCustomer customer = QCustomer.customer;

List<Tuple> result = queryFactory
    .select(customer.name, order.totalAmount.sum())
    .from(order)
    .join(order.customer, customer)
    .groupBy(customer.name)
    .fetch();

5. QueryDSL 적용이 적합한 경우

1. 동적 쿼리가 많은 프로젝트:
   • 사용자 필터링, 복잡한 검색 기능 등이 포함된 시스템.
2. 대규모 애플리케이션:
   • 조인, 서브쿼리 등 복잡한 쿼리가 많은 환경.
3. 가독성과 유지보수가 중요한 팀:
   • SQL을 명시적으로 작성하지 않고, 코드에서 명확히 관리.

6. QueryDSL 적용이 부적합한 경우

1. 간단한 CRUD 중심 프로젝트:
   • 네이티브 SQL 또는 JPA 기본 기능으로 충분한 경우.
2. 네이티브 SQL 중심 환경:
   • SQL 문법을 직접 작성해야 하는 시스템.

7. QueryDSL의 대안

8. 학습하면 좋은 추가 주제

1. QueryDSL의 고급 기능:
   • 서브쿼리 작성, 복잡한 집계 함수 활용.
2. QueryDSL과 Spring Data JPA 통합:
   • QueryDSL PredicateExecutor 활용.
3. QueryDSL 성능 최적화:
   • 페이징 쿼리, 배치 처리 전략.
4. Q 클래스 생성 관리:
   • Q 클래스 자동 생성 도구(Maven, Gradle) 설정.

JDBC, JPA, JPQL, QueryDSL 비교

주요 선택 기준

• JDBC: SQL에 익숙하며, 데이터베이스에 최적화된 세부 작업이 필요한 경우.
• JPA: 객체 지향적으로 데이터를 처리하고, 데이터베이스 독립성을 중시하는 경우.
• JPQL: 객체 지향적 쿼리가 필요하지만, 단순한 정적 쿼리 위주로 사용할 때.
• QueryDSL: 동적 쿼리와 복잡한 조건 쿼리가 빈번히 요구되며, 가독성과 타입 안전성을 중시할 때.

JPA 간단 정리

@Entity
@Getter
@Setter
public class Member {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String name;

    @OneToMany(mappedBy = "member", fetch = FetchType.LAZY) // Lazy 로딩
    private List<Order> orders = new ArrayList<>();
}

@Entity
@Getter
@Setter
public class Order {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String product;

    @ManyToOne(fetch = FetchType.EAGER) // Eager 로딩
    @JoinColumn(name = "member_id")
    private Member member;
}

N + 1 문제란 무엇인가

1. N + 1 문제란?

• 정의:
  • 데이터베이스에서 부모-자식 관계 데이터를 가져올 때, 비효율적으로 많은 쿼리가 실행되는 문제.
  • 주로 지연 로딩(FetchType.LAZY)을 사용하는 상황에서 발생.
• N + 1의 의미:
  • 1: 부모 데이터를 조회하는 1개의 쿼리.
  • N: 부모마다 자식 데이터를 조회하기 위한 N개의 쿼리.

2. N + 1 문제 예시

상황 설명

• 데이터베이스에 부모 테이블(Parent)과 자식 테이블(Child)이 있고, 한 부모는 여러 자식을 가질 수 있음.
• 목표: 모든 부모와 관련된 자식 데이터를 조회.

테이블 구조

• Parent 테이블

• Child 테이블

1. 기본 쿼리 흐름

-- 부모 데이터를 조회 (1번 실행)
SELECT * FROM parent;

-- 부모 각각에 대해 자식 데이터를 조회 (N번 실행)
SELECT * FROM child WHERE parent_id = 1;
SELECT * FROM child WHERE parent_id = 2;

2. 실행 결과

• 부모가 100명이라면:
  • 1번 부모 조회 쿼리 실행.
  • 100번 자식 조회 쿼리 실행.
  • 총 101번의 쿼리 실행.

3. N + 1 문제 확인 방법

Spring Boot에서 SQL 로그 활성화

spring:
  jpa:
    properties:
      hibernate:
        show_sql: true     # 실행 쿼리 표시
        format_sql: true   # 쿼리 포맷팅

SQL 로그 예시

-- 부모 조회
SELECT * FROM parent;

-- 부모별 자식 데이터 조회
SELECT * FROM child WHERE parent_id = 1;
SELECT * FROM child WHERE parent_id = 2;

4. 왜 N + 1 문제가 문제인가?

즉시 로딩 & 지연 로딩

@Entity
public class Parent {
    @Id
    @GeneratedValue
    private Long id;

    private String name;

    @OneToMany(mappedBy = "parent", fetch = FetchType.EAGER) // 즉시 로딩 설정
    private List<Child> children;
}

@Entity
public class Child {
    @Id
    @GeneratedValue
    private Long id;

    private String name;

    @ManyToOne
    @JoinColumn(name = "parent_id")
    private Parent parent;
}

// 실행
List<Parent> parents = parentRepository.findAll(); // 부모와 자식을 함께 로드

SELECT p.*, c.*
FROM parent p
LEFT JOIN child c
ON p.id = c.parent_id; -- 부모와 자식 데이터를 한 번의 쿼리로 로드

@Entity
public class Parent {
    @Id
    @GeneratedValue
    private Long id;

    private String name;

    @OneToMany(mappedBy = "parent", fetch = FetchType.LAZY) // 지연 로딩 설정
    private List<Child> children;
}

@Entity
public class Child {
    @Id
    @GeneratedValue
    private Long id;

    private String name;

    @ManyToOne
    @JoinColumn(name = "parent_id")
    private Parent parent;
}

// 실행
List<Parent> parents = parentRepository.findAll(); // 부모만 로드
for (Parent parent : parents) {
    System.out.println(parent.getChildren()); // 자식 데이터를 사용할 때 쿼리 실행
}

N + 1 문제 해결 방법

5.1 FetchType.EAGER로 변경

해결 원리

• 부모 데이터를 불러올 시에 자식 데이터도 한번에 다 '즉시' 전부 불러옴, 기존의 지연 로딩의 경우 필요한 경우에 불러오기 때문에 데이터를 다시 요청해야하지만, 즉시 로딩의 경우 이미 데이터를 다 불러왔기에 더이상 불러올 필요가 없다.

@OneToMany(mappedBy = "parent", fetch = FetchType.LAZY)
private List<Child> children;

@OneToMany(mappedBy = "parent", fetch = FetchType.EAGER)
private List<Child> children;

적용 방법

• 기본적으로 Lazy로 설정된 관계를 EAGER로 변경.

@Entity
public class Parent {
    @Id
    @GeneratedValue
    private Long id;

    private String name;

    @OneToMany(mappedBy = "parent", fetch = FetchType.EAGER) // 즉시 로딩
    private List<Child> children;
}

실행 쿼리

-- 부모와 자식 데이터를 즉시 조회
SELECT p.*, c.* 
FROM parent p 
LEFT JOIN child c 
ON p.id = c.parent_id;

장점

• 쿼리 횟수가 감소하여 성능 개선.

단점

• 필요하지 않은 데이터까지 즉시 조회되어 메모리 사용량 증가.

5.2 Fetch Join 사용

해결 원리

• 애초에 연관된 일부의 데이터만 미리 설정해 즉시 한번에 불러옴

적용 방법

• JPQL에서 JOIN FETCH를 사용하여 연관 데이터를 함께 조회.

@Query("SELECT p FROM Parent p JOIN FETCH p.children")
List<Parent> findAllWithChildren();

실행 쿼리

SELECT p.*, c.* 
FROM parent p 
LEFT JOIN child c 
ON p.id = c.parent_id;

장점

• N + 1 문제 해결.
• 필요한 데이터만 효율적으로 조회.

5.3 @EntityGraph 사용

해결 원리

• JPA에서 Fetch Join과 유사한 방식으로 작동하여 N+1 문제를 해결
• 엔티티 간의 연관 관계를 명시적으로 지정해 즉시 로딩(Eager)을 적용.

적용 방법

• JPA의 **@EntityGraph**를 활용하여 연관 데이터를 Fetch Join 방식으로 조회.

@EntityGraph(attributePaths = {"children"})
@Query("SELECT p FROM Parent p")
List<Parent> findAllWithChildren();

장점

• Fetch Join과 동일한 효과를 제공.
• 코드 재사용성이 높음.

5.4 Batch Size 설정

해결 원리

• 지연 로딩(Lazy Loading)을 유지하면서 데이터를 묶어서 한 번에 조회하도록 최적화.
• JPQL을 재작성할 필요 없이 애노테이션으로 간단히 설정 가능.

적용 방법

• Lazy 로딩을 유지하면서 여러 건의 데이터를 한 번에 가져오도록 Batch Size 설정.

Spring 설정

spring:
  jpa:
    properties:
      hibernate:
        default_batch_fetch_size: 10

실행 쿼리

-- 부모 조회
SELECT * FROM parent;

-- 자식 데이터 조회 (10건씩 묶어서 실행)
SELECT * FROM child WHERE parent_id IN (1, 2, 3, ..., 10);

장점

• Lazy 로딩 유지.
• 데이터 조회 최적화.

6. 해결 방법 비교

N + 1 문제 해결 방법 비교 정리

각 방법에 대한 설명

1. FetchType.EAGER

• 설명:
  • 연관된 데이터를 즉시 로드.
  • 간단한 설정으로 사용 가능.
• 적합한 상황:
  • 연관 데이터가 많지 않고, 자주 참조되는 경우.
• 한계:
  • 항상 데이터를 로드하므로 불필요한 성능 저하 가능.

2. Fetch Join

• 설명:
  • JPQL의 JOIN FETCH를 사용해 연관 데이터를 함께 조회.
  • 쿼리 실행 횟수를 최소화.
• 적합한 상황:
  • 관계가 단순하고, 대량 데이터가 아닌 경우.
• 한계:
  • 복잡한 관계에서는 쿼리 성능이 저하될 수 있음.

3. EntityGraph

• 설명:
  • JPA의 @EntityGraph를 사용해 Fetch Join을 간편하게 적용.
  • 쿼리 동작 방식을 코드와 분리하여 재사용성을 높임.
• 적합한 상황:
  • 관계가 단순하고, 코드 재사용성을 높이고 싶은 경우.
• 한계:
  • 복잡한 데이터 관계에서는 성능 저하 가능.

4. Batch Size

• 설명:
  • Lazy 로딩 유지하면서 연관 데이터를 묶어서 한 번에 조회.
  • 전역 설정 또는 개별 설정 가능.
• 적합한 상황:
  • 대량 데이터 조회 시 Lazy 로딩 유지가 필요한 경우.
• 한계:
  • IN 절의 비효율성과 예측 불가능한 쿼리 발생 가능.

결론

• FetchType.EAGER: 간단한 관계에서 데이터가 항상 필요할 경우 적합.
• Fetch Join: 즉시 로드가 필요하고 관계가 간단한 경우.
• EntityGraph: Fetch Join과 유사하지만 재사용성을 고려할 때 유용.
• Batch Size: Lazy 로딩을 유지하면서 대량 데이터를 효율적으로 처리하고 싶을 때.

7. 결론

• 상황에 맞는 해결 방법을 선택:
  • 데이터가 많지 않은 경우: FetchType.EAGER.
  • 특정 쿼리 최적화: Fetch Join or @EntityGraph.
  • 대량의 Lazy 로딩 데이터 최적화: Batch Size.

QueryDSL

QueryDSL 소개

• Entity의 매핑 정보를 활용하여 쿼리를 객체 또는 함수로 작성.
• 주요 구성:
  • Q클래스: Entity의 쿼리 전용 클래스.
  • JPAQueryFactory: Q클래스를 사용하여 쿼리를 생성 및 실행.

QueryDSL 적용 방법

1. JPAQueryFactory Bean 등록:
2. @Configuration public class JPAConfiguration { @PersistenceContext private EntityManager entityManager; @Bean public JPAQueryFactory jpaQueryFactory() { return new JPAQueryFactory(entityManager); } }
3. 쿼리 작성:
4. @Autowired private JPAQueryFactory queryFactory; public List<User> selectUserByUsernameAndPassword(String username, String password) { QUser user = QUser.user; return queryFactory.selectFrom(user) .where(user.username.eq(username) .and(user.password.eq(password))) .fetch(); }

예제: 멘션된 쓰레드 조회

• 조건: 내가 멘션된 쓰레드, 정렬 기준은 멘션된 시간 기준 내림차순.
• 출력: 채널명, 작성자 정보, 본문, 이모지 정보, 댓글 정보 등.

public List<ThreadDetails> findMentionedThreads(Long userId) {
    QThread thread = QThread.thread;
    QMention mention = QMention.mention;

    return queryFactory
        .select(
            Projections.bean(ThreadDetails.class,
                thread.channel.name.as("channelName"),
                thread.user.username.as("authorName"),
                thread.user.profileImageUrl.as("authorProfileImage"),
                thread.message.as("message"),
                thread.emotions.any().body.as("emotions"),
                thread.comments.any().message.as("commentMessages")
            ))
        .from(thread)
        .join(thread.mentions, mention)
        .where(mention.user.id.eq(userId))
        .orderBy(mention.createdAt.desc())
        .fetch();
}

Auditing

Auditing 소개

• 엔티티 생성 및 수정 시 자동으로 작성자와 시간을 기록.

적용 방법

1. @EnableJpaAuditing 추가:
2. @EnableJpaAuditing(auditorAwareRef = "userAuditorAware") @SpringBootApplication public class Application {}
3. 공통 Base 클래스 작성:
4. @MappedSuperclass @EntityListeners(AuditingEntityListener.class) public class BaseTimeEntity { @CreatedDate private LocalDateTime createdAt; @LastModifiedDate private LocalDateTime modifiedAt; @CreatedBy @ManyToOne private User createdBy; @LastModifiedBy @ManyToOne private User modifiedBy; }
5. AuditorAware 구현:
6. @Service public class UserAuditorAware implements AuditorAware<User> { @Override public Optional<User> getCurrentAuditor() { Authentication authentication = SecurityContextHolder.getContext().getAuthentication(); if (authentication == null || !authentication.isAuthenticated()) return Optional.empty(); return Optional.of(((UserDetailsImpl) authentication.getPrincipal()).getUser()); } }

Dynamic Insert/Update

Dynamic Insert

• @DynamicInsert:
  • Insert 쿼리에서 null 값을 제외한 필드만 포함.

@DynamicInsert
public class User {
    private String username;
    private String password;
}

적용 전:

insert into users (username, password, id) values (?, ?, ?)

적용 후:

insert into users (username, id) values (?, ?)

Dynamic Update

• @DynamicUpdate:
  • Update 쿼리에서 변경된 값만 포함.

@DynamicUpdate
public class User {
    private String username;
    private String password;
}

적용 전:

update users set username=?, password=? where id=?

적용 후:

update users set username=? where id=?

요약

테이블 객체 다루는법

[1] Cascade (영속성 전이)

Cascade 옵션 상세 설명

예제: 게시글과 첨부파일 관계

@Entity
public class Post {

    @Id
    @GeneratedValue
    private Long id;

    private String title;

    @OneToMany(mappedBy = "post", cascade = CascadeType.ALL, orphanRemoval = true)
    private List<File> files = new ArrayList<>();

    public void addFile(File file) {
        files.add(file);
        file.setPost(this);
    }

    public void removeFile(File file) {
        files.remove(file);
        file.setPost(null);
    }
}

@Entity
public class File {

    @Id
    @GeneratedValue
    private Long id;

    private String fileName;

    @ManyToOne
    @JoinColumn(name = "post_id")
    private Post post;
}

주요 사용 시나리오

1. 게시글 삭제 시 첨부파일도 삭제:
   • CascadeType.REMOVE를 사용해 부모 엔티티(Post) 삭제 시 자식 엔티티(File)도 삭제.
2. 게시글 저장 시 첨부파일도 저장:
   • CascadeType.PERSIST를 사용해 Post 저장 시 File도 저장.
3. 연관된 엔티티가 독립적으로 관리되지 않도록 제한:
   • 동일 라이프사이클 보장.

주의사항

1. Cascade의 과도한 사용 금지:
   • 모든 연관관계에 설정 시 데이터 무결성 문제 발생 가능.
2. ALL 사용 신중:
   • 모든 상태 전이를 강제하므로, 필요하지 않은 전이가 포함될 수 있음.
3. 단방향 설정 추천:
   • 불필요한 양방향 전이는 복잡도를 높이고 성능을 저하시킬 수 있음.

[2] orphanRemoval (고아 객체 제거) 

주요 사용 시나리오

1. 부모-자식 관계에서 고아 객체 처리:
   • 부모 엔티티에서 자식 엔티티를 리스트에서 제거하면, 매핑 정보가 없는 자식(고아 객체)을 자동으로 삭제.
   • 예: 게시글에서 첨부파일 제거 시, DB에서도 해당 첨부파일 삭제.
2. 자식의 라이프사이클 부모에 종속:
   • Cascade.ALL과 함께 사용하여 자식 엔티티가 부모의 라이프사이클에 완전히 종속되도록 설정.
   • 자식 엔티티의 생명주기를 부모 엔티티에서만 관리 가능.

예제 코드

1. 고아 객체 제거 설정

@Entity
public class Parent {

    @Id
    @GeneratedValue
    private Long id;

    @OneToMany(mappedBy = "parent", cascade = CascadeType.ALL, orphanRemoval = true)
    private List<Child> childList = new ArrayList<>();

    public void addChild(Child child) {
        childList.add(child);
        child.setParent(this);
    }

    public void removeChild(Child child) {
        childList.remove(child);
        child.setParent(null);
    }
}

@Entity
public class Child {

    @Id
    @GeneratedValue
    private Long id;

    @ManyToOne
    @JoinColumn(name = "parent_id")
    private Parent parent;
}

2. 사용 예제

Parent parent = em.find(Parent.class, parentId);
Child child = parent.getChildList().get(0);

// 자식 엔티티를 리스트에서 제거하면 자동으로 삭제됨
parent.removeChild(child);
em.flush(); // delete 쿼리 실행

장점 및 주의사항

[3] Fetch (조회 시점) 

FetchType 옵션 비교

추천 설정 및 사용 예제

기본 설정

• 대부분의 연관관계는 **LAZY**로 설정:
  • 불필요한 데이터 로드를 방지.
  • 필요 시 명시적으로 fetch join을 통해 데이터 조회.

항상 함께 쓰이는 관계

• EAGER 설정:
  • 예: @OneToOne에서 프로필과 사용자 관계처럼 항상 함께 조회되어야 하는 경우.

실제 사용 예제

1. FetchType 설정 예제

@Entity
public class User {

    @Id
    @GeneratedValue
    private Long id;

    @OneToOne(fetch = FetchType.EAGER)
    private Profile profile; // 즉시 로딩

    @OneToMany(mappedBy = "user", fetch = FetchType.LAZY)
    private List<Post> posts; // 지연 로딩
}

2. Fetch Join을 활용한 즉시 로딩

// 기본적으로 FetchType.LAZY 설정
@Entity
public class Post {

    @Id
    @GeneratedValue
    private Long id;

    @OneToMany(mappedBy = "post", fetch = FetchType.LAZY)
    private List<Comment> comments;
}

// Fetch Join으로 LAZY 관계 즉시 로딩
String query = "SELECT p FROM Post p JOIN FETCH p.comments WHERE p.id = :id";
TypedQuery<Post> typedQuery = em.createQuery(query, Post.class);
typedQuery.setParameter("id", postId);
Post post = typedQuery.getSingleResult();

주의사항

1. N+1 문제:
   • EAGER 설정 시, 연관된 자식 엔티티를 매번 추가로 조회해 성능 문제가 발생할 수 있음.
   • 해결책: fetch join 활용.
2. 불필요한 로딩 방지:
   • 필요하지 않은 데이터를 EAGER로 설정하지 않도록 주의.
3. 실무 권장 사항:
   • 대부분 LAZY 설정 후, 필요 시 명시적으로 fetch join 사용.
   • **EAGER**는 정말 항상 함께 조회되는 관계에만 설정.

테이블 객체로 자동 쿼리 생성하기

SprintData Common 의 CRUDRepository + PagingAndSortingRepository 이 쿼리기능을 제공

[1] JPA Repository 쿼리 기능 

주요 내용

기존 Repository

• 설정: @Repository 애노테이션을 붙여 사용.
• 기능:
  • Raw JPA 기반의 CRUD 구현.
  • 직접 EntityManager 사용 필요.
  • DB별 예외 처리를 수동으로 구현.

JpaRepository

• 설정: JpaRepository<Entity, ID>를 상속.
• 기능:
  • CRUD, 페이징, 정렬 기능 내장.
  • Spring Data JPA에 의해 구현체(SimpleJpaRepository)가 자동으로 생성 및 등록.
  • 더 적은 코드로 복잡한 기능 구현 가능.

코드 비교: 기존 Repository vs JpaRepository

기존 Repository

@Repository
public class UserRepository {

    @PersistenceContext
    private EntityManager entityManager;

    public User insertUser(User user) {
        entityManager.persist(user);
        return user;
    }

    public User selectUser(Long id) {
        return entityManager.find(User.class, id);
    }
}

JpaRepository로 변경

public interface UserRepository extends JpaRepository<User, Long> {
}

JpaRepository의 주요 제공 기능

1. CRUD 기능:
   • save(): 엔티티 저장/수정.
   • findById(): 기본 키로 엔티티 조회.
   • delete(): 엔티티 삭제.
2. 페이징 및 정렬:
   • findAll(Pageable pageable): 페이징 조회.
   • findAll(Sort sort): 정렬된 목록 조회.
3. 커스텀 쿼리 작성:
   • 메서드 이름 기반 쿼리 생성 (findByName).
   • JPQL 또는 네이티브 쿼리 작성 가능 (@Query).

Spring Data JPA의 장점

1. 자동 빈 등록:
   • @EnableJpaRepositories를 통해 자동으로 Repository 구현체 등록.
2. 간결한 코드:
   • 구현체 없이 인터페이스만으로 복잡한 기능 제공.
3. 일관된 예외 처리:
   • 데이터 접근 계층의 일관된 예외 체계.

결론

• 기존 @Repository 방식은 코드가 길고 직접 EntityManager를 사용해야 하지만,
• JpaRepository를 사용하면 CRUD, 페이징, 정렬 등 다양한 기능을 더 간단하게 구현 가능.

[2] JpaRepository 쿼리 사용 방법 

실습 예제 및 설명

기본 쿼리

List<User> findByNameAndPassword(String name, String password); // 조건식
List<User> findByNameIgnoreCase(String name);                  // 대소문자 무시
List<Person> findByNameOrderByAgeDesc(String name);            // 정렬

페이징 처리

Pageable firstPage = PageRequest.of(0, 3);  // 첫 페이지, 페이지 크기 3
Pageable sortedByName = PageRequest.of(1, 5, Sort.by("name")); // 두 번째 페이지, 정렬 추가

Page<User> pageResult = userRepository.findByName("John", firstPage);

• Page: 페이징 정보와 전체 데이터 수를 포함.
• Slice: 다음 페이지 여부만 확인 가능.

정렬 처리

// 정렬만 수행
List<Product> productsSortedByName = productRepository.findAll(Sort.by("name").ascending());

// 페이징과 정렬 함께
Pageable sortedByPriceAndName = PageRequest.of(0, 5, Sort.by("price").descending().and(Sort.by("name")));
Page<Product> pageResult = productRepository.findAll(sortedByPriceAndName);

스트림 사용

try (Stream<User> userStream = userRepository.readAllByNameNotNull()) {
    userStream.forEach(user -> System.out.println(user.getName()));
}

• 스트림 사용 후 자원 해제를 위해 try-with-resources 권장.

주요 특징 및 추천 활용

1. 기본 설정:
   • 메서드 이름만으로도 대부분의 쿼리 구현 가능.
   • 명확하고 간결한 코드 작성 가능.
2. 페이징과 정렬:
   • 페이징 시 Page와 Slice 선택적으로 사용.
   • 복합 정렬 시 **Sort**를 활용.
3. 스트림:
   • 대량 데이터 처리 시 유용.

[3] JpaRepository 효율적으로 사용하는 방법 

상세 설명 및 추천 활용

1. Optional 제거하기

• 문제: Optional 처리로 인해 코드가 복잡해질 수 있음.
• 해결: 기본 메서드를 활용하여 orElseThrow()로 예외를 처리.
• 추천 시나리오:
  • 엔티티가 반드시 존재해야 하는 경우.

2. 메서드명 간소화하기

• 문제: 긴 메서드명으로 인해 가독성이 떨어질 수 있음.
• 해결: 복잡한 메서드를 기본 메서드로 감싸서 간결한 이름 제공.
• 추천 시나리오:
  • 복잡한 조건이 포함된 쿼리 메서드.

3. 비즈니스 로직 통합

• 문제: 데이터베이스 작업과 비즈니스 로직이 분리되지 않으면 중복 코드 발생.
• 해결: 기본 메서드로 데이터 처리 및 로직 결합.
• 주의사항:
  • Repository는 데이터 접근 계층에 집중하고, 비즈니스 로직은 서비스 계층에서 처리하는 것이 일반적.
  • 간단한 작업에 한해 Repository에서 처리.

예제 코드

1. Optional 제거

public interface UserRepository extends JpaRepository<User, Long> {

    default User findUserById(Long id) {
        return findById(id).orElseThrow(() -> 
            new DataNotFoundException("User not found with id: " + id));
    }
}

2. 메서드명 간소화

public interface ProductRepository extends JpaRepository<Product, Long> {

    // 긴 메서드 이름
    List<Product> findAllByCategoryAndPriceGreaterThanEqualAndPriceLessThanEqualOrderByPriceAsc(String category, BigDecimal minPrice, BigDecimal maxPrice);

    // 간단한 메서드 이름
    default List<Product> findProductsByCategoryAndPriceRange(String category, BigDecimal minPrice, BigDecimal maxPrice) {
        return findAllByCategoryAndPriceGreaterThanEqualAndPriceLessThanEqualOrderByPriceAsc(category, minPrice, maxPrice);
    }
}

3. 비즈니스 로직 통합

public interface UserRepository extends JpaRepository<User, Long> {

    default void updateUserContact(Long userId, String newContact) {
        findById(userId).ifPresent(user -> {
            user.setContact(newContact);
            save(user);
        });
    }
}

추천 사용 전략

1. Optional 제거:
   • findById() 반환값을 비즈니스 로직에서 간결하게 처리.
2. 메서드명 간소화:
   • 복잡한 조건이 포함된 메서드를 간단하고 읽기 쉽게 변환.
3. 비즈니스 로직 통합:
   • 간단한 작업에 한해 Repository에서 직접 처리. 복잡한 로직은 서비스 계층에 분리.

테이블 객체로 페이지 조회하기

[1] JpaRepository 페이징 및 정렬 

페이징 처리 프로세스

1. PageRequest 생성:
   • PageRequest.of(page, size)로 페이지 번호와 크기를 설정.
   • 정렬이 필요한 경우 추가적으로 Sort를 전달.
2. 메서드 호출:
   • Pageable 객체를 JpaRepository 메서드에 전달.
   • 반환값은 Page<T>, Slice<T>, 또는 List<T>로 설정 가능.
3. 응답 처리:
   • Page<T> 또는 Slice<T> 객체에서 메타정보와 데이터를 추출하여 비즈니스 로직 처리.

주요 클래스 및 메서드

Pageable 생성

• 기본 생성:

  Pageable pageable = PageRequest.of(0, 10); // 페이지 번호: 0, 페이지 크기: 10
  

• 정렬 추가:

  Pageable pageable = PageRequest.of(0, 10, Sort.by("name").ascending());
  

Pageable 주요 메서드

메서드 설명

Page 응답 예제

{
  "content": [
    { "id": 1, "username": "User1", "address": "Korea", "age": 25 },
    { "id": 2, "username": "User2", "address": "USA", "age": 30 }
  ],
  "pageable": {
    "pageNumber": 0,
    "pageSize": 2,
    "sort": { "sorted": false, "unsorted": true }
  },
  "totalPages": 10,
  "totalElements": 20,
  "first": true,
  "last": false
}

페이징 반환 타입 비교

반환 타입 설명 장점 단점

정렬 처리

컬럼 값 기준 정렬

Sort sort = Sort.by("name").ascending();
Pageable pageable = PageRequest.of(0, 10, sort);
Page<User> page = userRepository.findAll(pageable);

다중 정렬

Sort sort = Sort.by("name").ascending().and(Sort.by("age").descending());
Pageable pageable = PageRequest.of(0, 10, sort);
Page<User> page = userRepository.findAll(pageable);

Alias를 기준으로 정렬

@Query("SELECT u.user_name AS userName FROM User u WHERE u.address = :address")
List<User> findByAddress(@Param("address") String address, Sort sort);

// 호출 시
List<User> users = userRepository.findByAddress("Korea", Sort.by("userName").ascending());

SQL 함수 기반 정렬

List<User> users = userRepository.findByUsername(
    "user", JpaSort.unsafe("LENGTH(password)").descending());

실습 코드

페이징 처리

Pageable pageable = PageRequest.of(1, 5, Sort.by("name").descending());
Page<User> page = userRepository.findByAddress("Korea", pageable);

List<User> users = page.getContent();
long totalElements = page.getTotalElements();
int totalPages = page.getTotalPages();

Slice 처리

Pageable pageable = PageRequest.of(1, 5, Sort.by("name").ascending());
Slice<User> slice = userRepository.findByAddress("Korea", pageable);

List<User> users = slice.getContent();
boolean hasNext = slice.hasNext();

추천 사용 전략

1. Page와 Slice:
   • 게시판: Page<T>를 사용하여 전체 정보 제공.
   • "더보기" 기능: Slice<T>로 성능 최적화.
2. 정렬:
   • 간단한 정렬: Sort 사용.
   • 복잡한 정렬: SQL 함수와 Alias 활용.
3. 최적화:
   • 카운트 쿼리 비용이 큰 경우 Slice 또는 List로 대체.

MyBatis

MyBatis 의 동작

• SqlSession Factory Builder (1), (2), (3)
  • MyBatis 설정 파일을 읽어와서
  • 설정정보 기반으로 SqlSession Factory 를 생성하는 빌더 객체
• MyBatis Config File (2)
  • 매핑해줄 객체가 들어있는 패키지 경로와
  • Mapping File 목록을 지정해주는 설정 파일

<!-- /resources/mybatis-config.xml -->
<!DOCTYPE configuration
        PUBLIC "-//mybatis.org//DTD Config 3.0//EN"
        "http://mybatis.org/dtd/mybatis-3-config.dtd">
<configuration>
    <typeAliases>
        <package name="com.thesun4sky.querymapper.domain"/>
    </typeAliases>
    <mappers>
        <mapper resource="mapper/UserMapper.xml"/>
    </mappers>
</configuration>

• SqlSession Factory (3), (5), (6)
  • 설정에 맞게 SqlSession 을 생성하여 들고있는 객체
• SqlSession (6), (7), (9), (10)
  • Mapping File 에서 쿼리를 조회해서 쿼리를 수행하고 응답을 받아올 수 있는 세션 객체
• Mapper Interface (8), (9)
  • DB 에서 조회하는 객체와 Java 프로그램의 객체간에 인터페이스를 정의하는 객체
  • 방법1. Dao 클래스 정의
    • SqlSession 를 직접적으로 사용하는 방법
    • SqlSession 멤버 변수로 사용하며 쿼리파일 수행 요청

// UserDao.java
import org.apache.ibatis.session.SqlSession;
import org.springframework.stereotype.Component;

import com.thesun4sky.querymapper.domain.User;

@Component
public class UserDao {

  // SqlSession 멤버 변수로 사용하며 쿼리파일 수행 요청
  private final SqlSession sqlSession;

  public UserDao(SqlSession sqlSession) {
    this.sqlSession = sqlSession;
  }

  public User selectUserById(long id) {
    return this.sqlSession.selectOne("selectUserById", id);
  }

}

• 장점
  • 쿼리문 실행 전에 넣어줄 매개변수와 쿼리 결과값의 변형을 정의할 수 있다.
  • Namespace를 내 마음대로 둘 수 있다.
  • .xml 파일의 쿼리문 id와 mapper 메소드명을 일치시킬 필요가 없다.
• 단점
  • Sqlsession 객체를 주입받아야 하며, 쿼리문 실행 시 항상 호출해야 한다.
  • 쿼리문 호출 시 sqlsession에 .xml 파일의 namespce와 쿼리문 id를 매개변수로 넘겨야한다.
• 방법2. Mapper Interface 정의
  • SqlSession 를 간접적으로 사용하는 방법
  • ibatis 에서 구현해주는 org.apache.ibatis.annotations.Mapper 어노테이션을 사용하면 sqlSession 를 사용하여 자동으로 호출해줌

// UserMapper.java
@Mapper
public interface UserMapper {

  User selectUserById(@Param("id") Long id);

}

• 장점
  • 메소드의 내부 구현이 불필요하다.
  • Sqlsession 객체 주입이 불펼요하다.
  • .xml 파일의 쿼리문 id와 mapper 메소드 명이 일치한다.
• 단점
  • .xml의 Namespace가 실제 Mapper.java 위치를 가르켜야 한다.
  • 메소드 내부 정의가 불가능하다.
• Mapping File (10)
  • SqlSession 가 실행하는 쿼리가 담긴 파일
  • 정의된 인터페이스에 기반해서 수행할 쿼리를 담아두고
  • 쿼리 수행결과를 어떤 인터페이스 매핑할지 정의해놓은 파일

<!-- UserMapper.xml -->
<!DOCTYPE mapper
        PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN"
        "http://mybatis.org/dtd/mybatis-3-mapper.dtd">
<mapper namespace="com.thesun4sky.querymapper.mapper.UserMapper">
    <select id="selectUserById" resultType="User">
        select id, name from users where id = #{id}
    </select>
</mapper>

쿼리 코드 만들기 (JpaRepository)

QueryMapper 의 DB의존성 및 중복 쿼리 문제로 ORM 이 탄생했다.

• ORM 은 DB의 주도권을 뺏어왔다고 표현해도 과언이 아닙니다.
• ORM 은 DAO 또는 Mapper 를 통해서 조작하는것이 아니라 테이블을 아예 하나의 객체(Object)와 대응시켜 버립니다.
• 말이 쉽지…. 객체지향(Object) 을 관계형 데이터베이스(Relation) 에 매핑(Mapping) 한다는건 정말 많은 난관이 있습니다.

ORM 문제점

ORM 해결책

• 영속성 컨텍스트와 쓰기 지연

예제 코드의 흐름

ORM 을 사용하는 가장 쉬운 방법 : JpaRepository

💁‍♂️ Repository vs JpaRepository

• 기존 Repository
  • @Repository 을 클래스에 붙인다.
  • @Component 어노테이션을 포함하고 있어서 앱 실행시 생성 후 Bean으로 등록된다.
  • 앞서배운 Repository 기본 기능만 가진 구현체가 생성된다. (DB별 예외처리 등)
• 새로운 JpaRepository
  • JpaRepository<Entity,ID> 인터페이스를 인터페이스에 extends 붙인다.
    • @NoRepositoryBean 된 ****상위 인터페이스들의 기능을 포함한 구현체가 프로그래밍된다. (@NoRepositoryBean = 빈생성 막음 →상속받으면 생성돼서 사용가능)
      • JpaRepository (마스터 셰프): 데이터 액세스를 위한 핵심 기능의 종합적인 요리책(기능) 을 제공합니다.
      • @NoRepositoryBean 인터페이스 (셰프): 각 인터페이스는 특정 데이터 액세스 방법을 제공하는 전문적인 기술 또는 레시피를 나타냅니다.
      • JpaRepository 상속: 마스터 셰프의 요리책과 셰프의 전문성을 얻습니다.
    • SpringDataJpa 에 의해 엔티티의 CRUD, 페이징, 정렬 기능 메소드들을 가진 빈이 등록된다. (상위 인터페이스들의 기능) 

• Repository 와 JpaRepository 를 통해 얼마나 간단하게 구현하게 될지 미리 확인해볼까요?
  • Repository 샘플
    • EntityManager 멤버변수를 직접적으로 사용

// UserRepository.java
@Repository
public class UserRepository {

  @PersistenceContext
  EntityManager entityManager;

  public User insertUser(User user) {
    entityManager.persist(user);
    return user;
  }

  public User selectUser(Long id) {
    return entityManager.find(User.class, id);
  }
}

• JpaRepository 샘플
  • EntityManager 멤버변수를 간접적으로 사용

// UserRepository.java
public interface UserRepository extends JpaRepository<User, Long> {
  // 기본 메서드는 자동으로 만들어짐
}

테이블 객체 이해하기

도메인 모델과 테이블 설계

더보기

 

도메인 관계 요약 표

도메인	관계 설명	관계 유형
User	- 채널과 양방향 관계.- 다른 도메인과 단방향 관계.	- User ↔ Channel (양방향).
Channel	- 유저와 다대다 관계.- 대화가 이루어지는 채널.	- Channel ↔ User (다대다).
Thread	- 채널 내 대화 쓰레드.- 댓글(Comment), 이모지(Emotion), 멘션(Mention)과 관계.	- Thread ↔ Comment (일대다).- Thread ↔ Emotion (다대다).- Thread ↔ Mention (다대다).
Comment	- 쓰레드 내 댓글.- 쓰레드와 다대일 관계.- 이모지(Emotion), 멘션(Mention)과 관계.	- Comment ↔ Thread (다대일).- Comment ↔ Emotion (다대다).- Comment ↔ Mention (다대다).
Emotion	- 쓰레드, 댓글 내 이모지.- 쓰레드와 댓글 각각과 다대다 관계.	- Emotion ↔ Thread (다대다).- Emotion ↔ Comment (다대다).
Mention	- 쓰레드, 댓글 내 멘션.- 쓰레드와 댓글 각각과 다대다 관계.	- Mention ↔ Thread (다대다).- Mention ↔ Comment (다대다).

---

관계 예시

1. User ↔ Channel:
   • 한 명의 유저는 여러 채널에 참여할 수 있고, 한 채널은 여러 유저를 가질 수 있음 (다대다).
2. Thread ↔ Comment:
   • 한 쓰레드는 여러 댓글을 가질 수 있지만, 댓글은 하나의 쓰레드에만 속함 (다대일).
3. Thread ↔ Emotion / Comment ↔ Emotion:
   • 여러 이모지가 하나의 쓰레드 또는 댓글에 추가될 수 있고, 하나의 이모지는 여러 쓰레드나 댓글에 사용될 수 있음 (다대다).
4. Thread ↔ Mention / Comment ↔ Mention:
   • 여러 멘션이 하나의 쓰레드 또는 댓글에 포함될 수 있고, 멘션은 여러 쓰레드나 댓글에서 참조될 수 있음 (다대다).

이 구조는 소셜 미디어나 채팅 애플리케이션에서 자주 볼 수 있는 관계를 모델링합니다.

 

Raw JPA 테이블 타입 매핑 기능 

JPA Anotation 특징 및 활용 요약

예제 코드

@Entity
@Table(name = "users")
public class User {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(name = "email", unique = true, nullable = false, length = 255)
    private String email;

    @Temporal(TemporalType.TIMESTAMP)
    private Date createdAt;

    @Transient
    private String tempData; // DB에 매핑되지 않음
}

Raw JPA 필드 타입 매핑 기능

주요 활용 및 예제

1. 기본 타입 매핑

@Entity
public class User {

    @Id
    @GeneratedValue
    private Long id;

    @Column(name = "email", length = 255, nullable = false)
    private String email;

    @Enumerated(EnumType.STRING) // Enum 값은 STRING으로 매핑
    private UserType userType;
}

2. Composite Value 타입 매핑

@Embeddable
public class Address {
    private String city;
    private String street;
}

@Entity
public class Member {

    @Id
    @GeneratedValue
    private Long id;

    @Embedded
    @AttributeOverrides({
        @AttributeOverride(name = "city", column = @Column(name = "home_city")),
        @AttributeOverride(name = "street", column = @Column(name = "home_street"))
    })
    private Address homeAddress;

    @Embedded
    @AttributeOverrides({
        @AttributeOverride(name = "city", column = @Column(name = "company_city")),
        @AttributeOverride(name = "street", column = @Column(name = "company_street"))
    })
    private Address companyAddress;
}

생성되는 테이블:

CREATE TABLE MEMBER (
  MEMBER_ID BIGINT NOT NULL AUTO_INCREMENT,
  NAME VARCHAR(255) NOT NULL,
  home_city VARCHAR(255) NOT NULL,
  home_street VARCHAR(255) NOT NULL,
  company_city VARCHAR(255) NOT NULL,
  company_street VARCHAR(255) NOT NULL,
  PRIMARY KEY (MEMBER_ID)
);

3. Collection Value 타입 매핑

@Entity
public class Product {

    @Id
    @GeneratedValue
    private Long id;

    @ElementCollection
    @CollectionTable(name = "product_tags", joinColumns = @JoinColumn(name = "product_id"))
    @Column(name = "tag")
    private List<String> tags = new ArrayList<>();
}

생성되는 테이블:

CREATE TABLE product_tags (
  product_id BIGINT NOT NULL,
  tag VARCHAR(255),
  PRIMARY KEY (product_id, tag)
);

특징 및 활용 요약

• 기본 타입: 일반적인 데이터 저장에 사용되며, 설정 옵션으로 제약조건 지정.
• Composite Value 타입: 코드의 응집도를 높이고 복합 데이터를 쉽게 관리.
• Collection Value 타입: 여러 값 관리에 유용하지만, 대규모 데이터에서는 다대일 연관관계를 선호.

테이블 객체 만들기

User Entity 만들어보기

• id, username, password 를 가지는 User Entity 를 만들어 봅니다.

// User.java
// lombok
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@ToString

// jpa
@Entity
@Table(name = "users")
public class User {

  /**
   * 컬럼 - 연관관계 컬럼을 제외한 컬럼을 정의합니다.
   */
  @Id
  @GeneratedValue(strategy = GenerationType.IDENTITY)
  @Column(name = "id")
  private Long id;

  private String username;

  private String password;

  /**
   * 생성자 - 약속된 형태로만 생성가능하도록 합니다.
   */
  @Builder
  public User(String username, String password) {
    this.username = username;
    this.password = password;
  }

  /**
   * 연관관계 - Foreign Key 값을 따로 컬럼으로 정의하지 않고 연관 관계로 정의합니다.
   */
  @OneToMany
  @Exclude
  private Set<UserChannel> userChannel;

  /**
   * 연관관계 편의 메소드 - 반대쪽에는 연관관계 편의 메소드가 없도록 주의합니다.
   */

  /**
   * 서비스 메소드 - 외부에서 엔티티를 수정할 메소드를 정의합니다. (단일 책임을 가지도록 주의합니다.)
   */
  public void updateUserName(String username) {
    this.username = username;
  }

  public void updatePassword(String password) {
    this.password = password;
  }
}

기타 추천 플러그인

Key PromoterX

• 단축키 알림

Presentation Assistant

• 알림 이쁘게 보여주기

테이블 객체끼리 관계만들기

Raw JPA 연관관계 매핑 기능 요약 표

주요 연관관계 예제

1. @OneToOne 단방향 매핑

@Entity
public class Member {
    @Id
    @GeneratedValue
    private Long id;

    @OneToOne
    @JoinColumn(name = "locker_id")
    private Locker locker;
}

@Entity
public class Locker {
    @Id
    @GeneratedValue
    private Long id;
}

2. @OneToMany와 @ManyToOne 양방향 매핑

@Entity
public class Parent {
    @Id
    @GeneratedValue
    private Long id;

    @OneToMany(mappedBy = "parent")
    private List<Child> childList;
}

@Entity
public class Child {
    @Id
    @GeneratedValue
    private Long id;

    @ManyToOne
    @JoinColumn(name = "parent_id")
    private Parent parent;
}

3. @ManyToMany 매핑

@Entity
public class Parent {
    @Id
    @GeneratedValue
    private Long id;

    @ManyToMany(mappedBy = "parents")
    private List<Child> childs;
}

@Entity
public class Child {
    @Id
    @GeneratedValue
    private Long id;

    @ManyToMany
    @JoinTable(
        name = "parent_child",
        joinColumns = @JoinColumn(name = "parent_id"),
        inverseJoinColumns = @JoinColumn(name = "child_id")
    )
    private List<Parent> parents;
}

실무 권장 사항

1. @ManyToMany 지양: 중간 매핑 테이블을 직접 정의하여 관리.
2. fetch 기본값 조정: 대부분의 관계를 LAZY로 설정.
3. 단방향 vs 양방향: 필요에 따라 양방향 관계를 신중히 설정.

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

📌 

 🐳 

 🐳 

 🐳 

소제목 

🧩 부모 타입 변수 = 자식 타입 객체; 는 자동으로 부모 타입으로 변환이 일어납니다.

소제목 

🎵 클래스가 설계도라면 추상 클래스는 미완성된 설계도입니다.

1. 데이터베이스 드라이버의 역할 및 종류

2. 데이터베이스 드라이버 동작 방식

더보기

[1]. Spring Boot 의 JDBC 라이브러리

• Spring Boot와 JDBC: Spring Boot는 데이터베이스 연결을 쉽게 구성할 수 있도록 다양한 JDBC 드라이버를 지원합니다. 이를 통해 개발자는 복잡한 설정 없이 데이터베이스와의 연결을 쉽게 구성할 수 있습니다.
• **spring-boot-starter-jdbc**는 Spring Boot 프로젝트에서 JDBC를 통해 데이터베이스와 상호작용하기 위해 사용되는 스타터 패키지입니다.
  • 이 스타터 패키지는 데이터베이스 작업을 수행하는 데 필요한 주요 의존성과 자동 구성 기능을 제공합니다. 데이터베이스와의 연결을 쉽고 빠르게 구성할 수 있도록 도와주는 브릿지 역할을 합니다.
  • 주요 포함 내용
    1. JDBC API 지원: JDBC API를 통해 SQL 데이터베이스에 접근하고 작업을 수행할 수 있습니다.
    2. DataSource 구성: 데이터 소스 연결을 위한 기본적인 설정을 자동으로 구성합니다. 이는 데이터베이스 연결을 관리하는 데 필수적인 요소입니다.
    3. JdbcTemplate: **JdbcTemplate**은 Spring의 핵심 클래스 중 하나로, JDBC 작업의 많은 번거로움을 줄여 줍니다. SQL 쿼리 실행, 결과 세트 처리, 예외 처리 등을 단순화합니다.
  • 주요 장점 내용
    1. 간소화된 데이터베이스 연결: DataSource 설정과 JdbcTemplate 사용을 통해 복잡한 JDBC 코드를 간소화할 수 있습니다.
    2. 자동 구성: Spring Boot의 자동 구성 기능은 개발자가 데이터베이스 연결에 필요한 대부분의 구성을 자동으로 처리할 수 있도록 합니다.
    3. 효율적인 예외 처리: Spring의 **DataAccessException**을 통해 JDBC에서 발생하는 예외를 Spring의 일관된 예외 체계로 변환합니다.

[2]. JDBC

• JDBC 드라이버란?: JDBC(Java Database Connectivity)는 자바 애플리케이션에서 데이터베이스에 접근할 수 있도록 하는 API입니다. JDBC 드라이버는 이 API를 구현하여, 자바 애플리케이션과 특정 데이터베이스 간의 연결을 가능하게 합니다.
• JDBC 드라이버 타입: JDBC 드라이버는 네 가지 유형(Type 1, 2, 3, 4)이 있으며, 각각의 특징과 사용 환경에 따라 선택할 수 있습니다. Type 4 드라이버(순수 자바 드라이버)가 가장 일반적으로 사용됩니다.
• 문장 그대로 Java 앱과 DB 를 연결시켜주기 위해 만들어진 기술입니다.
• 그렇기 때문에 JPA 도 이 기술을 사용하여 구현되어 있습니다. ✅
• JDBC Driver 는 여러타입의 DB 와 연결할 수 있는 기능을 제공합니다.

• JDBC 실습
  • DriverManager 를 통해서 Connection(연결) 을 생성하여 쿼리를 요청할 수 있는 상태를 만들어주고
  • Statement(상태) 를 생성하여 쿼리를 요청하고
  • ResultSet(결과셋) 을 생성해 쿼리 결과를 받아옵니다.

[3]. JDBC Template (QueryMapper)

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

JDBC Template (RowMapper)

• SQL Mapper 첫번째 주자로 JDBCTemplate 에 RowMapper 탄생
  • 쿼리 수행 결과와 객채 필드 매핑
  • RowMapper 로 응답필드 매핑코드 재사용
  • Connection, Statement, ResultSet 반복적 처리 대신 해줌
  • 😵‍💫 But, 결과값을 객체 인스턴스에 매핑하는데 여전히 많은 코드가 필요함

3. JDBC 주요 객체 및 역할

4. JDBC Template 주요 특징

5. JDBC Template vs. SQL Mapper vs. ORM

6. PreparedStatement vs Statement

RDBMS (Relational Database Management System)

📌 데이터를 테이블 형식으로 저장, 관리, 검색하는 시스템을 의미합니다.

• 관계형 데이터베이스(RDB)는 데이터가 **행(Row)과 열(Column)**로 구성된 테이블(Table) 형태로 저장되며, 데이터 간 관계를 정의할 수 있습니다.

RDBMS의 주요 특징

1. 테이블 기반 구조
   • 데이터는 테이블(Table) 형태로 저장되며, 각 테이블은 행(Row)과 열(Column)로 구성.
   • 열: 데이터의 속성(예: 이름, 나이).
   • 행: 데이터의 실제 값(레코드).
2. 관계(Relationship)
   • 테이블 간 관계를 설정하여 데이터를 연결.
   • 예: 외래 키(Foreign Key)를 사용해 두 테이블 간 참조 관계를 설정.
3. SQL 지원
   • 데이터를 정의, 조작, 검색하기 위해 **SQL(Structured Query Language)**을 사용.
   • 예: SELECT, INSERT, UPDATE, DELETE.
4. 정규화(Normalization)
   • 데이터 중복을 줄이고, 데이터 무결성을 유지하기 위해 테이블을 나누는 프로세스.
5. 데이터 무결성 및 일관성
   • 트랜잭션(ACID 특성)을 통해 데이터의 무결성과 일관성을 보장.
   • ACID:
     • Atomicity(원자성): 트랜잭션은 완전히 수행되거나 전혀 수행되지 않음.
     • Consistency(일관성): 트랜잭션 수행 후 데이터는 항상 일관된 상태를 유지.
     • Isolation(격리성): 트랜잭션은 독립적으로 수행되어야 함.
     • Durability(지속성): 트랜잭션이 완료되면 데이터는 영구적으로 저장.
6. 데이터 검색 및 조작
   • 복잡한 조건과 다양한 방식으로 데이터를 검색(Join, Subquery 등).
7. 동시성 제어
   • 다수의 사용자와 애플리케이션이 동시에 데이터베이스에 접근할 수 있도록 지원.

RDBMS의 주요 구성 요소

RDBMS의 주요 사용 사례

1. ERP/CRM 시스템
   • 기업 내 리소스 관리 및 고객 관리 시스템의 데이터 저장소.
2. 전자상거래
   • 상품, 사용자, 주문 데이터를 관리.
3. 금융 시스템
   • 계좌, 거래 내역, 결제 데이터 관리.
4. 소셜 네트워크
   • 사용자 정보, 친구 관계, 게시물 데이터 관리.

대표적인 RDBMS 소프트웨어

RDBMS의 장단점

RDBMS와 NoSQL의 비교

쉽게 이해하기

• RDBMS는 데이터를 "엑셀 표처럼" 테이블에 저장하고, 테이블 간 관계를 설정하여 데이터를 체계적으로 관리하는 시스템입니다.
• 예를 들어:
  • 사용자 테이블: 사용자 이름, 이메일, ID.
  • 주문 테이블: 주문 ID, 사용자 ID, 상품.
  • 사용자 ID를 통해 두 테이블 간 관계를 설정.

추가로 알아야 할 점

• JPA와 RDBMS: JPA는 RDBMS의 데이터를 객체지향적으로 다루기 위한 기술입니다. RDBMS를 잘 이해하면 JPA 사용이 훨씬 수월해집니다.
• 트랜잭션 이해: RDBMS의 핵심은 트랜잭션과 무결성입니다. 이를 이해하면 애플리케이션 설계에 큰 도움이 됩니다.

[심층적인 구조]

더보기

데이터베이스 시스템(DBMS)의 구조 설명

위 이미지는 데이터베이스 시스템(DBMS)의 전체적인 구조를 나타낸 것입니다. 데이터베이스 시스템은 사용자 인터페이스, DBMS(데이터베이스 관리 시스템), 데이터베이스라는 3개의 주요 계층으로 구성됩니다. 각각의 구성 요소와 동작 방식은 다음과 같습니다.

---

1. 사용자 계층 (Interface Layer)

• 사용자: 데이터베이스를 직접 사용하거나, 애플리케이션을 통해 간접적으로 접근하는 주체입니다.
  • 응용 프로그램 화면: 일반 사용자들이 데이터베이스와 상호작용하기 위해 사용하는 UI.
  • 응용 프로그램 개발: 응용 프로그램 개발자가 SQL이나 프로그래밍 언어를 사용해 데이터베이스와 연동하는 로직을 작성.
  • SQL 사용자: SQL을 통해 데이터를 직접 질의하거나 수정하는 사용자.
  • DBA (Database Administrator): 데이터베이스 관리자로, 데이터베이스의 설계, 최적화, 권한 부여 등을 담당.

---

2. DBMS 계층 (Database Management System Layer)

이 계층은 데이터베이스의 데이터를 저장, 질의, 관리, 최적화하는 모든 기능을 담당합니다. 주로 아래의 요소들로 구성됩니다:

1) 컴파일러

• Embedded DML: 응용 프로그램 코드에 포함된 SQL 명령을 처리합니다.
• DML 컴파일러: 데이터 조작 언어(Data Manipulation Language)를 컴파일하여 실행.
  • 예: SELECT, INSERT, UPDATE, DELETE 명령어.
• DDL 컴파일러: 데이터 정의 언어(Data Definition Language)를 해석하여 데이터베이스 구조를 생성 및 변경.
  • 예: CREATE TABLE, ALTER TABLE.

2) 질의 처리기 (Query Processor)

• SQL 질의를 실행하기 위한 주요 컴포넌트:
  • SQL Interface: SQL 명령어를 입력받는 인터페이스.
  • Parser: SQL 명령어를 해석하여 쿼리 트리(Query Tree)로 변환.
  • Optimizer: 최적의 실행 계획을 수립하여 쿼리를 효율적으로 처리.
  • Caches & Buffers: 자주 사용하는 데이터를 캐시와 버퍼에 저장하여 성능 향상.

3) 트랜잭션 관리자 (Transaction Manager)

• 데이터의 무결성과 일관성을 보장하기 위해 ACID 특성을 관리:
  • 원자성, 일관성, 고립성, 지속성.

4) 파일 관리자 및 버퍼 관리자

• 파일 관리자: 데이터 파일과 데이터베이스 파일 시스템 간의 인터페이스.
• 버퍼 관리자: 디스크 I/O를 최소화하고 메모리를 효율적으로 사용.

---

3. 데이터 계층 (Database Layer)

• 데이터베이스 계층은 데이터를 물리적으로 저장하고 관리하는 부분입니다.
  • 데이터 파일: 실제 데이터를 저장하는 파일.
  • 인덱스: 데이터를 빠르게 검색할 수 있도록 도와주는 구조.
  • 데이터 통계: 데이터 분포에 대한 정보를 저장, 쿼리 최적화에 사용.
  • 데이터 사전: 데이터베이스 메타데이터를 저장. 테이블, 열, 데이터 유형 등에 대한 정보를 포함.

---

전체적인 동작 흐름

1. 사용자 입력
   • 사용자가 SQL 질의를 실행하거나, 응용 프로그램을 통해 데이터베이스와 상호작용합니다.
2. 질의 처리
   • SQL 질의는 SQL Interface를 통해 입력되고, Parser와 Optimizer를 거쳐 실행 계획이 생성됩니다.
3. 실행
   • 실행 계획에 따라 트랜잭션 관리자와 파일 관리자가 협력하여 데이터를 검색, 수정, 저장합니다.
4. 데이터 입출력
   • 요청된 데이터는 데이터베이스 계층에서 검색되어 캐시/버퍼를 통해 사용자에게 반환됩니다.

---

특징 및 장점

1. 모듈화
   • 각 계층은 독립적으로 동작하면서도 서로 협력하여 효율적인 데이터 관리 가능.
2. 효율적인 데이터 처리
   • 쿼리 최적화, 캐싱, 트랜잭션 관리 등을 통해 성능을 극대화.
3. 데이터 무결성 보장
   • 트랜잭션 관리와 데이터 사전을 통해 데이터의 무결성과 일관성 유지.
4. 확장성
   • 다양한 사용자 요구를 충족하며, 대규모 데이터와 동시 사용자 환경에서도 안정적인 성능 제공.

---

쉽게 이해하기

이 구조는 사용자가 간단한 SQL 명령을 입력하면,
DBMS 내부에서 이를 해석, 최적화, 실행하고, 실제 데이터베이스에서 결과를 반환하는 일련의 과정을 보여주는 설계입니다.

궁금한 점이 있거나 더 설명이 필요한 부분이 있다면 말씀해주세요! 😊

객체 지향 프로그래밍(OOP)과 관계형 데이터베이스(RDB)의 패러다임 불일치

JPA의 등장 이유

• 객체 지향 프로그래밍(OOP)과 관계형 데이터베이스(RDB)는 서로 다른 방식으로 데이터를 표현합니다. 이로 인해 개발자는 객체와 데이터베이스 간의 불일치를 해결하기 위해 많은 작업을 해야 하며, 이 문제를 해결하기 위해 JPA(Java Persistence API)가 등장했습니다. 다음은 주요 내용을 정리한 것입니다.

1. 객체와 관계형 데이터베이스의 구조적 차이

• 객체 지향 모델:
  클래스(설계도)를 기반으로 객체를 생성하며, 속성(필드)과 동작(메서드)을 포함.
• 관계형 모델:
  데이터를 테이블 형식으로 저장하며, 열(컬럼)과 행(로우)으로 구성.

이 두 모델의 표현 방식 차이로 인해, 데이터를 저장하거나 조회할 때 매핑 작업이 필수적입니다.

2. 반복되는 CRUD 작업

• 객체를 데이터베이스에 저장(Create), 조회(Read), 수정(Update), 삭제(Delete)하기 위해 개발자는 항상 SQL 쿼리를 직접 작성해야 합니다.
• 이로 인해 코드 중복이 발생하고, 유지보수가 어려워집니다.

3. 상속과 연관관계 매핑의 어려움

• 상속:
  객체 지향 언어는 상속을 지원하지만, 관계형 데이터베이스는 이를 직접적으로 지원하지 않습니다. 따라서 별도의 매핑 작업이 필요합니다.
• 연관관계:
  객체는 참조를 통해 관계를 표현하지만, 데이터베이스는 **외래 키(Foreign Key)**와 **조인(JOIN)**을 통해 관계를 나타냅니다.

이 차이로 인해 객체 간의 관계를 데이터베이스에 저장하거나 조회하는 과정이 복잡해질 수 있습니다.

4. 객체 비교의 문제

• 동일한 데이터를 조회하더라도 다른 객체 인스턴스로 다뤄질 수 있습니다.
• 이로 인해 객체를 비교할 때 의도한 결과를 얻지 못할 가능성이 있습니다.

JPA의 등장

이러한 패러다임 불일치 문제를 해결하기 위해 JPA가 도입되었습니다.
JPA는 다음과 같은 방식으로 문제를 해소합니다:

• 객체를 자바 컬렉션(LIST, MAP등)처럼 다룰 수 있게 해줌.
• 객체와 데이터베이스 간의 매핑 작업을 자동화하여 개발자의 부담을 줄임.

JPA의 장점:

• 개발 생산성 향상
• 코드 중복 감소
• 유지보수성 강화

JDBC(Java Database Connectivity)

📌 JDBC(Java Database Connectivity*는 Java에서 데이터베이스와 상호작용하기 위한 표준 API입니다. 이를 통해 SQL 명령을 실행하고 데이터베이스와 연결하여 데이터를 조회하거나 변경할 수 있습니다.

• JDBC는 다양한 DBMS(MySQL, PostgreSQL, Oracle 등)와 연동하기 위한 기반 기술입니다.

JDBC의 주요 특징

1. 표준화된 데이터베이스 액세스 API:
   • Java와 데이터베이스 간의 통신을 위한 표준 인터페이스를 제공합니다.
   • DBMS에 의존적이지 않으며, 다양한 데이터베이스 드라이버를 통해 활용 가능합니다.
2. SQL 실행:
   • 데이터베이스에서 CRUD 작업(Create, Read, Update, Delete)을 수행할 수 있습니다.
3. DB 드라이버 기반 동작:
   • 각 DBMS에 맞는 JDBC 드라이버를 통해 데이터베이스와 상호작용합니다.
4. 저수준 API:
   • 데이터베이스 연결, SQL 실행, 자원 관리 등 모든 과정을 개발자가 직접 제어해야 합니다.
5. 광범위한 지원:
   • 모든 주요 데이터베이스(MySQL, Oracle, PostgreSQL 등)와 연동 가능합니다.

JDBC의 주요 구성 요소

[Statement]

Statement stmt = connection.createStatement();

JDBC의 동작 순서

1. JDBC 드라이버 로드:
   • Java에서 데이터베이스에 접근하기 위해 해당 DBMS의 JDBC 드라이버를 로드합니다.

   Class.forName("com.mysql.cj.jdbc.Driver");
   

2. 데이터베이스 연결:
   • DriverManager.getConnection() 메서드를 통해 데이터베이스와 연결합니다.

   Connection connection = DriverManager.getConnection(
       "jdbc:mysql://localhost:3306/testdb", "username", "password");
   

3. SQL 실행:
   • Statement, PreparedStatement, 또는 CallableStatement 객체를 생성하여 SQL을 실행합니다.

   Statement stmt = connection.createStatement();
   ResultSet rs = stmt.executeQuery("SELECT * FROM users");
   

4. 결과 처리:
   • ResultSet을 통해 SQL 실행 결과를 처리합니다.

   while (rs.next()) {
       System.out.println("ID: " + rs.getInt("id"));
       System.out.println("Name: " + rs.getString("name"));
   }
   

5. 자원 해제:
   • 데이터베이스 연결 및 모든 자원을 닫아야 합니다.

   rs.close();
   stmt.close();
   connection.close();
   

JDBC 주요 메서드

JDBC의 장점과 단점

장점

1. 데이터베이스 독립성:
   • Java 표준 인터페이스를 사용하므로 다양한 DBMS와 연동 가능.
2. 유연성:
   • SQL을 자유롭게 작성하고, DBMS 고유의 기능도 사용할 수 있음.
3. 직접 제어:
   • SQL과 데이터베이스 작업을 세부적으로 제어할 수 있음.

단점

1. 반복 코드:
   • 연결, 자원 관리, 예외 처리 등 반복적인 코드가 많음.
2. SQL Injection 위험:
   • Statement 사용 시 동적 SQL에서 보안 취약점이 발생할 수 있음.
3. 복잡한 자원 관리:
   • Connection, Statement, ResultSet 등을 명시적으로 닫아야 함.
4. 생산성 부족:
   • CRUD 같은 간단한 작업도 많은 코드가 필요함.

결론

• JDBC는 Java와 데이터베이스 간의 기본적인 통신을 가능하게 하는 표준 API입니다.
• 저수준 API로 유연하지만, 반복적인 코드와 자원 관리의 복잡성 때문에 실제 프로젝트에서는 JDBC Template, MyBatis, JPA/Hibernate 같은 고수준 프레임워크가 선호됩니다.
• 하지만 고수준 프레임워크의 대표격인 JPA도 JDBC를 바탕으로 움직이며, JPA가 해결 못하는 경우 JDBC가 사용되기도 합니다.
• 하지만, SQL 직접 제어가 필요한 경우나 간단한 데이터베이스 작업에서는 여전히 JDBC가 유용하게 사용됩니다

JPA(Java Persistence API)

📌 자바 애플리케이션에서 관계형 데이터베이스(RDB)를 다루기 위한 표준 인터페이스입니다.

• JPA는 자바 객체와 관계형 데이터베이스 간의 **매핑(ORM: Object-Relational Mapping)**을 제공하여, 개발자가 SQL 중심이 아닌 객체 중심으로 데이터를 처리할 수 있도록 돕습니다.

JPA의 주요 특징

1. ORM (Object-Relational Mapping) 기술
   • 자바 객체와 데이터베이스 테이블을 매핑.
   • 객체 필드는 테이블 컬럼에, 객체 간의 관계는 외래 키(FK)에 매핑.
2. SQL 추상화
   • 데이터베이스와의 상호작용을 위한 SQL을 직접 작성하지 않아도 됨.
   • 개발자는 자바 코드로 데이터를 조작하며, JPA가 필요한 SQL을 자동 생성.
3. POJO 기반 개발
   • JPA 엔티티 클래스는 Plain Old Java Object(POJO)로 작성.
   • 특정 라이브러리에 종속되지 않으며, 일반적인 자바 클래스를 사용할 수 있음.
   • 더보기

     POJO란?

     특별한 규칙이나 라이브러리 의존 없이 작성된 순수한 자바 객체를 의미합니다.
     즉, 자바의 기본 문법으로 작성된 간단한 객체로, 특정 프레임워크나 기술에 종속되지 않습니다.

     ---

     POJO의 특징

     1. 순수한 자바 객체
        • 자바 문법으로 작성된 일반적인 클래스.
        • 상속받아야 하거나 특정 인터페이스를 구현해야 하는 제약이 없음.
     2. 독립적
        • 특정 프레임워크나 라이브러리에 의존하지 않음.
        • 예를 들어, EJB(Enterprise JavaBeans)와 같은 복잡한 환경과 반대되는 개념.
     3. 간결하고 직관적
        • 클래스의 속성(필드)과 이를 조작하기 위한 메서드(getter, setter 등)만 포함.

     ---

     POJO의 예시

     POJO 클래스

     public class User {
         private String name;
         private int age;
     
         // 기본 생성자
         public User() {}
     
         // 매개변수 있는 생성자
         public User(String name, int age) {
             this.name = name;
             this.age = age;
         }
     
         // Getter와 Setter
         public String getName() {
             return name;
         }
     
         public void setName(String name) {
             this.name = name;
         }
     
         public int getAge() {
             return age;
         }
     
         public void setAge(int age) {
             this.age = age;
         }
     }
     

     사용

     public class Main {
         public static void main(String[] args) {
             User user = new User("Alice", 25);
             System.out.println(user.getName()); // Alice
             user.setAge(26);
             System.out.println(user.getAge());  // 26
         }
     }
     

     ---

     POJO가 중요한 이유

     1. 단순성
        • 복잡한 규약 없이도 자바 기본 문법으로 개발 가능.
     2. 테스트 용이성
        • 외부 의존성이 없으므로 단위 테스트(Unit Test)를 쉽게 작성할 수 있음.
     3. 프레임워크 독립성
        • 특정 프레임워크에 종속되지 않기 때문에 코드가 재사용 가능하고 이식성이 높음.
     4. JPA와의 연관성
        • JPA의 엔티티(Entity)는 POJO로 작성되므로, 객체 지향적인 코드를 유지할 수 있음.
        • 예: JPA의 @Entity 클래스는 POJO의 형태를 따름.

     ---

     POJO와 다른 개념의 비교

     POJO	JavaBean
     단순한 자바 객체	POJO의 일종으로, 특정 규약을 따름
     규칙 없음	기본 생성자, Getter/Setter 필수
     특정 프레임워크 의존 없음	JavaBean 표준 스펙 준수

     ---

     결론

     POJO는 자바 프로그래밍의 기본적인 단순 객체로, 복잡한 제약 없이 작성되어 코드의 가독성과 유지보수성을 높여줍니다. JPA, 스프링과 같은 프레임워크에서 핵심적으로 사용되는 객체 형태입니다. 

4. DBMS 독립성
   • JPA는 DBMS에 종속되지 않으며, 설정에 따라 MySQL, PostgreSQL, Oracle 등 다양한 데이터베이스에서 작동.
5. 캐싱 지원
   • 1차 캐시(영속성 컨텍스트)와 2차 캐시를 통해 성능을 최적화.

JPA의 동작 원리

1. 엔티티(Entity)
   • 데이터베이스 테이블에 매핑되는 자바 클래스.
   • 예: @Entity 어노테이션을 사용하여 매핑.
2. 영속성 컨텍스트(Persistence Context)
   • 엔티티 객체를 관리하는 JPA의 내부 메커니즘.
   • 데이터베이스와의 연결을 관리하며, 엔티티를 캐싱해 성능을 최적화.
3. EntityManager
   • 엔티티의 생성, 조회, 수정, 삭제 작업을 담당하는 JPA의 핵심 인터페이스.
   • JPA를 통해 데이터베이스 작업을 처리하는 주요 도구.

JPA의 주요 동작

JPA를 사용하는 이유

1. 객체 중심 개발
   • SQL 중심 개발에서 객체 중심 개발로 전환 가능.
   • 데이터베이스 작업 시 객체 지향 패러다임을 유지.
2. 생산성 향상
   • CRUD 작업에 필요한 SQL을 직접 작성하지 않아도 됨.
   • 코드의 중복 제거, 유지보수 용이.
3. DBMS 독립성
   • 데이터베이스 종류에 관계없이 동일한 코드로 동작 가능.
4. 성능 최적화
   • 1차 캐시, 지연 로딩(Lazy Loading), 벌크 작업 최적화 등 다양한 성능 향상 기법 제공.
5. 트랜잭션 관리
   • JPA는 트랜잭션 경계 내에서 데이터 일관성과 무결성을 보장.

JPA 주요 어노테이션

JPA vs Hibernate

• JPA: 자바에서 ORM을 위한 표준 인터페이스.
• Hibernate: JPA의 구현체 중 하나로, 추가적인 기능을 제공.

JPA 사용 예시

1. 엔티티 클래스

@Entity
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(nullable = false)
    private String name;

    private int age;

    // Getters and Setters
}

2. 데이터 저장

EntityManager em = entityManagerFactory.createEntityManager();
em.getTransaction().begin();

User user = new User();
user.setName("John");
user.setAge(30);

em.persist(user); // 데이터 저장
em.getTransaction().commit();

3. 데이터 조회

User user = em.find(User.class, 1L); // ID가 1인 사용자 조회
System.out.println(user.getName());

JPA의 장단점

장점

1. 객체 지향 패러다임과 데이터베이스 간의 불일치 해결.
2. SQL 작성 없이 객체 중심으로 데이터 처리.
3. 데이터베이스 변경 시 코드 변경 최소화.
4. 트랜잭션, 캐싱, 성능 최적화 기능 내장.

단점

1. 학습 곡선이 있음 (초기 학습 난이도).
2. 복잡한 쿼리는 JPQL로 처리해야 하며, SQL보다 직관성이 떨어질 수 있음.
3. 대규모 프로젝트에서는 잘못된 설정으로 성능 저하 가능.

결론

JPA는 자바 애플리케이션에서 관계형 데이터베이스를 효율적으로 다루기 위한 표준화된 솔루션입니다. 객체 중심 개발을 가능하게 하며, 생산성과 유지보수성을 크게 향상시킬 수 있습니다.

트랜잭션

 🐳 데이터베이스에서 작업의 논리적인 단위를 의미합니다. 트랜잭션은 하나의 작업 단위를 구성하며, 이 단위가 완전히 성공하거나 실패해야 데이터의 무결성을 보장합니다.

트랜잭션의 동작 예시

1) 은행 송금 시스템

• 계좌 A에서 100원을 인출하고, 계좌 B에 100원을 입금하는 작업:

BEGIN TRANSACTION
1. 계좌 A에서 100원 출금
2. 계좌 B에 100원 입금
IF 모든 작업 성공:
    COMMIT
ELSE:
    ROLLBACK

• 두 작업(출금과 입금)은 하나의 트랜잭션으로 처리되며, 둘 중 하나라도 실패하면 롤백되어 데이터 무결성을 유지합니다.

트랜잭션의 특징 (ACID 속성)

1. 원자성 (Atomicity):
   • 트랜잭션 내의 모든 작업이 모두 성공하거나 모두 실패해야 합니다.
   • 일부 작업만 실행되고 나머지가 실패하면, 전체 작업을 취소(롤백)하여 데이터 일관성을 유지합니다.
2. 일관성 (Consistency):
   • 트랜잭션이 성공적으로 완료되면, 데이터베이스가 항상 일관성 있는 상태로 유지됩니다.
   • 예: 은행 송금 시, 한 계좌에서 돈을 빼면 다른 계좌에 같은 금액이 추가되어야 함.
3. 고립성 (Isolation):
   • 여러 트랜잭션이 동시에 실행될 경우, 각 트랜잭션은 서로 독립적으로 실행되어야 합니다.
   • 한 트랜잭션의 중간 결과가 다른 트랜잭션에 노출되지 않음.
4. 지속성 (Durability):
   • 트랜잭션이 커밋된 후에는 영구적으로 데이터베이스에 반영되어야 합니다.
   • 서버가 중단되거나 시스템 장애가 발생해도 데이터는 손실되지 않습니다.

트랜잭션의 상태

1. 활성 (Active):
   • 트랜잭션이 시작되고 작업이 진행 중인 상태.
2. 부분 완료 (Partially Committed):
   • 트랜잭션의 마지막 명령이 실행되었지만, 아직 커밋되지 않은 상태.
3. 완료 (Committed):
   • 트랜잭션이 성공적으로 완료되어 데이터베이스에 반영된 상태.
4. 실패 (Failed):
   • 트랜잭션이 오류로 인해 중단된 상태.
5. 철회 (Aborted):
   • 트랜잭션이 실패하거나 취소되어 롤백된 상태.

트랜잭션의 처리 과정

1. 트랜잭션 시작:
   • 트랜잭션을 시작하여 작업 단위를 정의.
2. 작업 실행:
   • 트랜잭션 내에서 여러 데이터베이스 작업(쿼리, 삽입, 업데이트, 삭제 등)을 실행.
3. 커밋 또는 롤백:
   • 모든 작업이 성공하면 커밋하여 데이터베이스에 변경 사항을 반영.
   • 작업 중 오류가 발생하면 롤백하여 변경 사항을 취소.

Spring에서의 트랜잭션 관리

Spring은 프록시 기반 AOP를 사용하여 트랜잭션 관리를 제공합니다. Spring의 트랜잭션 관리 기능은 선언적 방식과 프로그래밍 방식으로 사용 가능합니다.

1. 선언적 트랜잭션 관리

Spring에서는 @Transactional 어노테이션을 사용하여 선언적으로 트랜잭션을 관리할 수 있습니다.

@Service
public class UserService {

    @Transactional
    public void createUser(User user) {
        userRepository.save(user);
        emailService.sendWelcomeEmail(user); // 예외 발생 시 전체 롤백
    }
}

• @Transactional이 붙은 메서드는 트랜잭션이 시작되고, 예외 발생 시 롤백됩니다.
• 커밋은 메서드 실행이 성공적으로 종료되면 수행됩니다.

2. 프로그래밍 방식 트랜잭션 관리

프로그래밍 방식으로 PlatformTransactionManager를 사용하여 트랜잭션을 직접 관리할 수 있습니다.

@Service
public class UserService {

    @Autowired
    private PlatformTransactionManager transactionManager;

    public void createUser(User user) {
        TransactionStatus status = transactionManager.getTransaction(new DefaultTransactionDefinition());

        try {
            userRepository.save(user);
            emailService.sendWelcomeEmail(user);
            transactionManager.commit(status); // 성공 시 커밋
        } catch (Exception e) {
            transactionManager.rollback(status); // 실패 시 롤백
        }
    }
}

트랜잭션 전파 수준 (Propagation)

트랜잭션 전파(Propagation)는 트랜잭션이 다른 메서드 호출 시 어떻게 동작할지 정의합니다.

트랜잭션 격리 수준 (Isolation)

트랜잭션 격리 수준은 동시에 실행되는 트랜잭션 간의 상호작용을 제어합니다.

트랜잭션 롤백 조건

Spring의 @Transactional은 기본적으로 런타임 예외가 발생할 때 롤백합니다.

롤백 예외 설정

@Transactional(rollbackFor = Exception.class)
public void process() {
    // Exception 발생 시 롤백
}

롤백 제외 설정

@Transactional(noRollbackFor = CustomException.class)
public void process() {
    // CustomException 발생 시 롤백하지 않음
}

트랜잭션의 장점

1. 데이터 무결성 보장:
   • 작업 도중 오류가 발생해도 데이터 손상 방지.
2. 동시성 제어:
   • 여러 사용자가 동시에 데이터베이스에 접근해도 데이터 충돌 방지.
3. 복잡한 작업 관리:
   • 여러 작업 단위를 하나의 트랜잭션으로 묶어 관리 가능.
4. 자동화된 관리:
   • Spring의 트랜잭션 관리를 통해 선언적으로 간단하게 설정 가능.

정리

**트랜잭션(Transaction)**은 하나의 논리적인 작업 단위를 정의하며, 데이터베이스의 무결성과 일관성을 보장합니다. Spring은 선언적 트랜잭션(@Transactional)을 제공하여 개발자가 쉽게 트랜잭션을 관리할 수 있도록 돕습니다.

핵심 개념:

1. ACID 속성: 원자성, 일관성, 고립성, 지속성.
2. Spring의 지원: 선언적(@Transactional), 프로그래밍 방식.
3. 전파와 격리 수준: 트랜잭션의 실행 방식을 제어.

트랜잭션 전파

 🐳  하나의 트랜잭션이 다른 트랜잭션 내에서 어떻게 동작할지를 결정하는 규칙으로 여러 개의 트랜잭션이 포함된 시스템에서 특정 작업이 다른 작업에 어떻게 영향을 미칠지를 정의한다.

• 현재 클래스의 트랜잭션과 다른 클래스의 트랜잭션을 교통정리 한다.

• 트랜잭션이 여러 계층 또는 메서드에서 어떻게 처리될지 정의한다.(@Transactional)
• propagation 속성을 통해 트랜잭션의 동작 방식을 제어할 수 있다.
• 다양한 비즈니스 요구 사항에 맞춰 복잡한 트랜잭션 흐름을 유연하게 설계할 수 있도록 돕는다.
• 데이터 무결성과 비지니스 로직의 안정성을 보장할 수 있다.

• 코드 예시
  • REQUIRED(Default) 사용

@Service
@RequiredArgsConstructor
public class MemberService {
    
    private final PointPolicy pointPolicy;

    @Transactional
    public void signUp(Member member) {
        // 회원 등록
        memberRepository.save(member);

        // 포인트 지급
        pointPolicy.addPoints(member.getId(), 100);
    }
}

@Component
public class PointPolicy {
    public void addPoints(Long memberId, int points) {
        // 포인트 지급 로직
        pointRepository.save(new Point(memberId, points));
    }
}

• signUp() 메서드에 @Transactional 을 통해 트랜잭션 설정
• 하위 addPoints() 메서드에 트랜잭션이 전파된다.
• 하위 메서드가 실패하면 롤백된다.
  • 포인트 지급 로직에서 문제가 발생해도 회원 등록은 롤백된다.
• 트랜잭션 동작

• 트랜잭션 전파 종류
  • propagation 속성
    1. REQUIRED(Default)
       • 기존 트랜잭션이 있다면 기존 트랜잭션을 사용한다.
       • 기존 트랜잭션이 없다면 트랜잭션을 새로 생성한다.
    2. REQUIRES_NEW
       • 항상 새로운 트랜잭션을 시작하고, 기존의 트랜잭션은 보류한다.
       • 두 트랜잭션은 독립적으로 동작한다.
    3. SUPPORTS
       • 기존 트랜잭션이 있으면 해당 트랜잭션을 사용한다.
       • 기존 트랜잭션이 없으면 트랜잭션 없이 실행한다.
    4. NOT_SUPPORTED
       • 기존 트랜잭션이 있어도 트랜잭션을 중단하고 트랜잭션 없이 실행된다.
    5. MANDATORY
       • 기존 트랜잭션이 반드시 있어야한다.
       • 트랜잭션이 없으면 실행하지 않고 예외를 발생시킨다.
    6. NEVER
       • 트랜잭션 없이 실행되어야 한다.
       • 트랜잭션이 있으면 예외를 발생시킨다.
    7. NESTED
       • 현재 트랜잭션 내에서 중첩 트랜잭션을 생성한다.
       • 중첩 트랜잭션은 독립적으로 롤백할 수 있다.
       • 기존 트랜잭션이 Commit되면 중첩 트랜잭션도 Commit 된다.

• REQUIRES_NEW
  • 회원 가입과 동시에 회원에게 포인트를 지급해야 하는 경우

@Service
@RequiredArgsConstructor
public class MemberService {

    private final PointPolicy pointPolicy;

    @Transactional
    public void signUp(Member member) {
        // 회원 등록
        memberRepository.save(member);

        // 포인트 지급
        pointPolicy.addPoints(member.getId(), 100);
    }
}

@Component
public class PointPolicy {

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void addPoints(Long memberId, int points) {
        // 포인트 지급 로직
        pointRepository.save(new Point(memberId, points));
    }
    
}

• 요구사항 : 포인트 지급에 **실패**해도 회원가입은 완료되어야 한다.
• REQUIRES_NEW 설정(독립적인 트랜잭션 유지)
  • 포인트 지급 로직에서 문제가 발생해도 회원 등록은 롤백되지 않는다.
• 트랜잭션 동작

DB Lock

https://kyunghun0515.tistory.com/161

Spring Boot와 JPA

https://kyunghun0515.tistory.com/107

[아래의 내용은 Spring과 DB의 상호작용에 대한 내용입니다.]

매핑(Mappin)

📌 객체(Object)와 데이터베이스 테이블(Table)을 연결하는 과정을 의미합니다. 매핑은 객체지향 프로그래밍 언어와 관계형 데이터베이스 간의 불일치를 해결하고, 데이터를 저장하거나 조회할 때 이를 자동화하는 데 도움을 줍니다.

주요 매핑 유형

1. 엔티티와 테이블 매핑

• 객체를 데이터베이스 테이블과 매핑합니다.
• @Entity와 @Table 애너테이션 사용.
• 예시: 
• @Entity @Table(name = "users") public class User { @Id private Long id; private String name; }

2. 필드와 컬럼 매핑

• 객체의 필드를 데이터베이스의 컬럼과 매핑합니다.
• @Column 애너테이션 사용.
• 예시:

  @Column(name = "user_name", nullable = false, length = 100)
  private String name;
  

3. 기본 키 매핑

• 엔티티의 식별자를 데이터베이스의 기본 키와 매핑합니다.
• @Id와 @GeneratedValue 사용.
• 예시:

  @Id
  @GeneratedValue(strategy = GenerationType.IDENTITY)
  private Long id;
  

4. 연관관계 매핑

• 객체 간의 관계를 데이터베이스의 외래 키로 매핑합니다.
• @OneToOne, @OneToMany, @ManyToOne, @ManyToMany 애너테이션 사용.
• 예시:

  @OneToMany(mappedBy = "user")
  private List<Order> orders;
  

5. 임베디드 매핑

• 재사용 가능한 값 타입 객체를 다른 엔티티에 매핑.
• @Embeddable과 @Embedded 사용.
• 예시:

  @Embeddable
  public class Address {
      private String city;
      private String street;
  }
  
  @Entity
  public class User {
      @Embedded
      private Address address;
  }
  

매핑의 주요 목적

1. 객체-관계 변환: 객체의 필드와 테이블의 컬럼 간 변환 자동화.
2. 재사용성: 임베디드 객체를 통해 코드 재사용 가능.
3. 유지보수성: 객체 중심으로 설계하면 유지보수가 쉬워짐.
4. 생산성 향상: CRUD 작업 자동화.

매핑 사용 시 주의점

1. 필드와 컬럼 간 데이터 타입 일치 확인.
2. 복잡한 연관관계 설계 시 성능 고려.
3. 기본 키 전략 선택의 중요성.
4. 임베디드 타입 사용 시 중복 컬럼 방지.

연관관계 매핑

🐳 객체 간의 관계를 데이터베이스의 테이블 간의 외래 키 관계로 변환하는 과정을 의미합니다. 객체지향 언어에서는 객체 간 참조로 관계를 표현하지만, 관계형 데이터베이스에서는 외래 키를 사용하여 테이블 간 관계를 표현합니다.

1. 연관관계 매핑 종류

2. 연관관계 매핑 주요 어노테이션

3. 연관관계 매핑 상세

(1) @OneToOne (1:1 관계)

• 한 객체가 다른 객체와 1:1로 매핑.
• 외래 키를 어느 쪽에 설정할지 결정해야 함.
• @JoinColumn으로 외래 키를 명시적으로 지정.

예제

@Entity
public class User {

    @Id
    @GeneratedValue
    private Long id;

    private String name;

    @OneToOne
    @JoinColumn(name = "profile_id") // 외래 키 설정
    private Profile profile;
}

@Entity
public class Profile {

    @Id
    @GeneratedValue
    private Long id;

    private String bio;
}

(2) @ManyToOne (N:1 관계)

• 여러 객체가 하나의 객체를 참조.
• 관계형 데이터베이스에서 외래 키가 있는 테이블은 다(N) 쪽.

예제

@Entity
public class Order {

    @Id
    @GeneratedValue
    private Long id;

    private String product;

    @ManyToOne
    @JoinColumn(name = "user_id") // 외래 키 설정
    private User user;
}

(3) @OneToMany (1:N 관계)

• 한 객체가 여러 객체를 관리.
• 관계형 데이터베이스에서는 다(N) 쪽이 외래 키를 관리하므로, mappedBy로 외래 키 주인을 설정해야 함.

예제

@Entity
public class User {

    @Id
    @GeneratedValue
    private Long id;

    private String name;

    @OneToMany(mappedBy = "user") // 외래 키 관리 주인 설정
    private List<Order> orders = new ArrayList<>();
}

@Entity
public class Order {

    @Id
    @GeneratedValue
    private Long id;

    private String product;

    @ManyToOne
    @JoinColumn(name = "user_id") // 외래 키 설정
    private User user;
}

(4) @ManyToMany (N:M 관계)

• 다수의 객체가 다수의 객체와 연결.
• 관계형 데이터베이스에서는 중간 테이블을 통해 구현.
• JPA에서는 @JoinTable을 사용해 중간 테이블을 정의.

예제

@Entity
public class Student {

    @Id
    @GeneratedValue
    private Long id;

    private String name;

    @ManyToMany
    @JoinTable(
        name = "student_course",
        joinColumns = @JoinColumn(name = "student_id"),
        inverseJoinColumns = @JoinColumn(name = "course_id")
    )
    private List<Course> courses = new ArrayList<>();
}

@Entity
public class Course {

    @Id
    @GeneratedValue
    private Long id;

    private String name;

    @ManyToMany(mappedBy = "courses") // 관계의 주인이 아님
    private List<Student> students = new ArrayList<>();
}

4. mappedBy

• mappedBy는 연관 관계의 주인을 설정하는 데 사용.
• 주인: 외래 키를 관리하는 쪽.
• mappedBy 속성: 주인이 아닌 엔티티에서 주인을 지정.

예제

@Entity
public class User {

    @Id
    @GeneratedValue
    private Long id;

    private String name;

    @OneToMany(mappedBy = "user") // Order 엔티티의 user 필드가 주인임을 지정
    private List<Order> orders = new ArrayList<>();
}

@Entity
public class Order {

    @Id
    @GeneratedValue
    private Long id;

    private String product;

    @ManyToOne
    @JoinColumn(name = "user_id") // 외래 키 주인
    private User user;
}

5. Fetch 전략

• 연관 관계 매핑에서 데이터 조회 시점을 설정.
• FetchType.LAZY (지연 로딩):
  • 연관된 엔티티를 실제로 사용할 때 데이터베이스에서 로드.
  • 기본값: @OneToMany, @ManyToMany.
• FetchType.EAGER (즉시 로딩):
  • 연관된 엔티티를 즉시 로드 (JOIN 사용).
  • 기본값: @OneToOne, @ManyToOne.

6. 연관관계 매핑 시 주의사항

1. 단방향과 양방향 관계
   • 단방향 관계: 한 방향으로만 참조.
   • 양방향 관계: 양쪽 엔티티에서 서로 참조.
2. mappedBy 설정
   • 양방향 관계에서는 반드시 mappedBy를 통해 주인을 설정.
3. N+1 문제
   • 지연 로딩 사용 시, 연관된 데이터가 많아지면 불필요한 쿼리가 다수 발생(N+1 문제).
   • 해결 방법:
     • FETCH JOIN 사용.
     • 배치 페치 크기 조정 (hibernate.default_batch_fetch_size).
4. Cascade 설정
   • 부모 엔티티와 연관된 자식 엔티티를 함께 저장, 삭제 등 자동 관리.

7. 연관관계 매핑 요약

결론

JPA의 연관관계 매핑은 객체 지향적인 설계를 데이터베이스 관계형 모델에 반영할 수 있게 해줍니다. 매핑을 설정할 때는 **연관 관계의 방향성, 외래 키의 관리 주체, 성능 최적화(Fetch 전략)**를 고려하여 설계하는 것이 중요합니다.

추가적으로 궁금한 점이나 더 깊은 설명이 필요하면 언제든 말씀해주세요! 😊

상속관계 매핑

🐳 객체 지향 프로그래밍의 상속 구조를 관계형 데이터베이스 테이블에 매핑하는 방법입니다. 상속 구조를 데이터베이스에서 효율적으로 표현하기 위해 JPA는 3가지 상속 전략을 제공합니다.

1. 상속관계 매핑 전략

2. 주요 어노테이션

@Entity
@Inheritance(strategy = InheritanceType.SINGLE_TABLE) // 단일 테이블 전략
@DiscriminatorColumn(name = "dtype") // 구분 컬럼 이름 설정
public abstract class Item {

    @Id
    @GeneratedValue
    private Long id;

    private String name;
}

@Entity
@DiscriminatorValue("B") // dtype 값 설정
public class Book extends Item {

    private String author;
}

@Entity
@DiscriminatorValue("M") // dtype 값 설정
public class Movie extends Item {

    private String director;
}

@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(name = "item_type", discriminatorType = DiscriminatorType.STRING, length = 10)
public abstract class Item {
    @Id
    @GeneratedValue
    private Long id;

    private String name;
}

@Entity
@DiscriminatorValue("BookType") // dtype 값 설정
public class Book extends Item {

    private String author;
}

@Entity
@DiscriminatorValue("MovieType") // dtype 값 설정
public class Movie extends Item {

    private String director;
}

SELECT * FROM Item WHERE dtype = 'B';

3. 상속 매핑 전략 상세

(1) 단일 테이블 전략 (SINGLE_TABLE)

• 특징:
  • 부모 클래스와 자식 클래스의 데이터를 하나의 테이블에 저장.
  • 상속 구조에 대한 테이블이 하나뿐이므로 성능이 좋음.
  • 테이블 구조가 단순하지만, 많은 컬럼이 생길 수 있음(불필요한 NULL 컬럼 발생 가능).
• 구현 예제:

@Entity
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(name = "dtype") // 구분 컬럼
public abstract class Item {

    @Id
    @GeneratedValue
    private Long id;

    private String name;
}

@Entity
@DiscriminatorValue("Book") // dtype 값
public class Book extends Item {

    private String author;
}

@Entity
@DiscriminatorValue("Movie") // dtype 값
public class Movie extends Item {

    private String director;
}

• 생성된 테이블 구조:

(2) 조인 전략 (JOINED)

• 특징:
  • 부모 클래스와 자식 클래스 각각 별도의 테이블에 저장.
  • 조회 시 부모 테이블과 자식 테이블을 JOIN하여 데이터를 조회.
  • 데이터 정규화로 중복을 줄이고 구조가 깔끔, 하지만 조회 시 성능이 비교적 느릴 수 있음.
• 구현 예제:

@Entity
@Inheritance(strategy = InheritanceType.JOINED)
public abstract class Item {

    @Id
    @GeneratedValue
    private Long id;

    private String name;
}

@Entity
public class Book extends Item {

    private String author;
}

@Entity
public class Movie extends Item {

    private String director;
}

• 생성된 테이블 구조:
  • 부모 테이블 (Item):ID NAME

    1	Book 1
    2	Movie 1

  • 자식 테이블 (Book):ID AUTHOR

    1

    Author A

  • 자식 테이블 (Movie):ID DIRECTOR

    2	Director A

• 조회 SQL:

SELECT i.*, b.*
FROM Item i
LEFT JOIN Book b ON i.id = b.id
WHERE i.id = 1;

(3) 테이블별 클래스 전략 (TABLE_PER_CLASS)

• 특징:
  • 부모 클래스는 테이블을 생성하지 않고, 자식 클래스마다 독립적인 테이블을 생성.
  • 자식 클래스별로 테이블이 독립적이므로 JOIN이 필요 없음.
  • 중복된 컬럼이 많아질 수 있으며, 쿼리 성능이 떨어질 가능성이 있음.
• 구현 예제:

@Entity
@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
public abstract class Item {

    @Id
    @GeneratedValue
    private Long id;

    private String name;
}

@Entity
public class Book extends Item {

    private String author;
}

@Entity
public class Movie extends Item {

    private String director;
}

• 생성된 테이블 구조:
  • 자식 테이블 (Book):ID NAME AUTHOR

    1

    Book 1

    Author A

  • 자식 테이블 (Movie):ID NAME DIRECTOR

    2

    Movie 1

    Director A

4. 상속 매핑 전략 비교

5. 상속 매핑 선택 기준

1. 단일 테이블 전략:
   • 테이블 수를 줄이고 싶을 때.
   • 엔티티의 종류가 많지 않거나, NULL 컬럼이 크게 문제가 되지 않을 때.
2. 조인 전략:
   • 정규화된 데이터 모델을 선호하거나, 데이터 중복을 최소화해야 할 때.
   • 데이터베이스 성능이 JOIN 쿼리를 잘 처리할 수 있을 때.
3. 테이블별 클래스 전략:
   • 자식 엔티티 간에 완전히 독립적인 테이블이 필요할 때.
   • 조회 쿼리 성능이 중요한 경우 피하는 것이 좋음.

6. 상속 매핑 주의사항

1. 추상 클래스 사용:
   • 상위 클래스는 보통 추상 클래스로 선언하여 직접 사용하지 않도록 설계.

   @Entity
   public abstract class Item { }
   

2. Discriminator 컬럼:
   • 단일 테이블 전략과 조인 전략에서는 구분 컬럼을 통해 엔티티 구분.
3. 복잡한 상속 구조 피하기:
   • 지나치게 깊은 상속 구조는 설계와 유지보수를 어렵게 만듦.

7. 결론

JPA의 상속 매핑은 객체지향 설계와 관계형 데이터베이스 간의 불일치를 해결하는 데 매우 유용합니다. 프로젝트의 요구사항(성능, 데이터 중복, 정규화 등)에 따라 적절한 상속 전략을 선택해야 하며, 각 전략의 장단점을 고려하여 설계하는 것이 중요합니다.

궁금한 점이나 추가적인 설명이 필요하면 언제든 말씀해주세요! 😊

JPA에서 테이블과 객체 매핑

📌 **데이터베이스의 테이블(Table)**과 **Java 객체(Entity)**를 매핑하여 객체지향적으로 데이터베이스를 사용할 수 있도록 합니다. 이를 통해 SQL을 직접 작성하지 않아도, 엔티티 객체의 필드와 테이블 컬럼 간의 변환을 자동으로 처리할 수 있습니다.

1. 테이블과 객체 매핑 기본 개념

2. 기본 매핑 어노테이션

(1) @Entity

• 클래스가 JPA 엔티티임을 선언.
• 데이터베이스 테이블과 매핑되는 클래스.
• 필수 조건:
  • 기본 생성자 필요.
  • @Id로 기본 키를 설정.

import jakarta.persistence.*;

@Entity // 엔티티 선언
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY) // 기본 키 자동 생성
    private Long id;

    private String name; // 매핑 컬럼
    
    private String email; // 매핑 컬럼
}

(2) @Table

• 엔티티와 매핑되는 데이터베이스 테이블의 이름을 지정.
• 속성:
  • name: 매핑할 테이블 이름 (기본값은 클래스 이름).
  • schema: 테이블이 속한 스키마 이름.
  • catalog: 테이블이 속한 카탈로그 이름.
  • uniqueConstraints: 유니크 제약 조건 설정.

@Entity
@Table(name = "users", schema = "public")
public class User {
    @Id
    @GeneratedValue
    private Long id;

    @Column(nullable = false)
    private String name;
}

(3) @Column

• 엔티티 필드와 테이블 컬럼을 매핑.
• 속성:
  • name: 컬럼 이름 지정.
  • nullable: NULL 허용 여부.
  • unique: 유니크 제약 조건 설정.
  • length: 문자열 컬럼 길이 지정.
  • precision 및 scale: 숫자 타입의 정밀도와 소수점 자리수 지정.

@Column(name = "user_name", nullable = false, length = 100)
private String name;

@Column(name = "user_email", unique = true)
private String email;

(4) @Id

• 기본 키(Primary Key)로 사용할 필드를 설정.
• 반드시 한 개의 필드에 선언해야 함.

(5) @GeneratedValue

• 기본 키 값을 자동으로 생성.
• 전략(strategy):
  • GenerationType.IDENTITY: 데이터베이스의 자동 증가(AUTO_INCREMENT) 사용.
  • GenerationType.SEQUENCE: 데이터베이스 시퀀스를 사용해 기본 키 생성.
  • GenerationType.TABLE: 키 생성용 별도 테이블을 사용.
  • GenerationType.AUTO: 데이터베이스에 맞게 자동 선택.

@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;

3. 테이블과 객체 매핑 예시

(1) 단순 매핑

@Entity
@Table(name = "users")
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(name = "user_name", nullable = false, length = 50)
    private String name;

    @Column(name = "user_email", unique = true)
    private String email;

    // 기본 생성자
    public User() {}

    // Getters and Setters
}

(2) 연관 관계 매핑

@Entity
@Table(name = "orders")
public class Order {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @ManyToOne // N:1 관계
    @JoinColumn(name = "user_id") // 외래 키 매핑
    private User user;

    private String product;

    private int quantity;
}

4. @Table과 @Column 속성 정리

5. 자동 테이블 생성

JPA는 애플리케이션 실행 시 엔티티 클래스 기반으로 테이블을 자동 생성할 수 있습니다.
이를 위해 hibernate.hbm2ddl.auto 속성을 설정합니다.

설정 예시 (persistence.xml 또는 application.properties)

spring.jpa.hibernate.ddl-auto=update

6. 테이블 객체 매핑 장점

1. SQL 자동화
   • CRUD 작업을 자동으로 처리.
2. 객체 지향적 설계
   • 테이블 설계를 객체 모델로 표현 가능.
3. 데이터베이스 독립성
   • JPA 설정으로 다양한 데이터베이스를 지원.
4. 생산성 향상
   • 매핑 설정만으로 데이터 처리 간소화.

테이블 객체 다루는법

import jakarta.persistence.*;

@Entity
public class Parent {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String name;

    @OneToMany(mappedBy = "parent", cascade = CascadeType.ALL) // Cascade 설정
    private List<Child> children = new ArrayList<>();

    // Getter, Setter
}

Parent parent = new Parent();
parent.setName("Parent");

Child child1 = new Child();
child1.setName("Child 1");

Child child2 = new Child();
child2.setName("Child 2");

// 부모와 자식 관계 설정
parent.getChildren().add(child1);
parent.getChildren().add(child2);
child1.setParent(parent);
child2.setParent(parent);

// 부모를 저장하면 자식 엔티티도 자동으로 저장
entityManager.persist(parent);

@OneToMany(mappedBy = "parent", cascade = CascadeType.PERSIST)
private List<Child> children = new ArrayList<>();

@OneToMany(mappedBy = "parent", cascade = CascadeType.MERGE)
private List<Child> children = new ArrayList<>();

@OneToMany(mappedBy = "parent", cascade = CascadeType.REMOVE)
private List<Child> children = new ArrayList<>();

@OneToMany(mappedBy = "parent", cascade = CascadeType.ALL)
private List<Child> children = new ArrayList<>();

@Entity
public class Parent {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @OneToMany(mappedBy = "parent", cascade = CascadeType.ALL, orphanRemoval = true)
    private List<Child> children = new ArrayList<>();
}

@Entity
public class Child {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @ManyToOne
    @JoinColumn(name = "parent_id")
    private Parent parent;
}

Parent parent = entityManager.find(Parent.class, 1L);
entityManager.remove(parent); // 자식 엔티티도 함께 삭제

@Entity
public class Parent {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String name;

    @OneToMany(mappedBy = "parent", cascade = CascadeType.ALL, orphanRemoval = true)
    private List<Child> children = new ArrayList<>();

    // Helper method to manage bidirectional relationship
    public void addChild(Child child) {
        children.add(child);
        child.setParent(this);
    }

    public void removeChild(Child child) {
        children.remove(child);
        child.setParent(null);
    }
}

@Entity
public class Child {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String name;

    @ManyToOne
    @JoinColumn(name = "parent_id")
    private Parent parent;
}

// 부모 엔티티 생성
Parent parent = new Parent();
parent.setName("Parent");

// 자식 엔티티 생성 및 관계 설정
Child child1 = new Child();
child1.setName("Child 1");
Child child2 = new Child();
child2.setName("Child 2");

parent.addChild(child1);
parent.addChild(child2);

entityManager.persist(parent); // Parent와 Child가 모두 저장

// 부모 엔티티에서 자식 엔티티 제거
parent.removeChild(child1);

entityManager.flush(); // flush() 시점에 child1에 대한 DELETE SQL 실행

child1.setParent(null); // 부모 관계 해제
entityManager.flush();  // flush 시점에 DELETE SQL 실행

@ManyToOne(fetch = FetchType.EAGER)
@JoinColumn(name = "user_id")
private User user;

@OneToMany(mappedBy = "parent", fetch = FetchType.LAZY)
private List<Child> children;

@Entity
public class Order {
    @Id
    @GeneratedValue
    private Long id;

    @ManyToOne(fetch = FetchType.EAGER) // 즉시 로딩 설정
    @JoinColumn(name = "user_id")
    private User user;
}

SELECT o.*, u.* 
FROM orders o
LEFT JOIN users u ON o.user_id = u.id
WHERE o.id = 1;

@Entity
public class Order {
    @Id
    @GeneratedValue
    private Long id;

    @ManyToOne(fetch = FetchType.LAZY) // 지연 로딩 설정
    @JoinColumn(name = "user_id")
    private User user;
}

List<Order> orders = em.createQuery("SELECT o FROM Order o", Order.class).getResultList();
for (Order order : orders) {
    System.out.println(order.getUser().getName()); // 각 User를 조회할 때마다 쿼리 실행
}

Entity

[아래는 위 내용의 요약본입니다.]

Entity 표 요약

주요 어노테이션 요약

주요 관계 매핑 요약

Entity 생명주기

엔티티 생명주기 표 요약

상태 전환 흐름 예시

상태 전환 주요 코드 예시

1. 비영속 상태
   • User user = new User(); // 비영속 user.setName("John");
2. 영속 상태로 전환
   • em.persist(user); // 영속 상태
3. 준영속 상태로 전환
   • em.detach(user); // 준영속 상태
4. 삭제 상태로 전환
   • em.remove(user); // 삭제 상태 em.getTransaction().commit(); // 데이터베이스에서 제거

영속성 컨텍스트 (Persistence Context)

📌 JPA에서 엔티티(Entity)를 관리하는 일종의 메모리 공간으로, 애플리케이션과 데이터베이스 사이의 중간 계층 역할을 합니다. 엔티티 객체의 상태를 관리하고, 데이터베이스와 동기화하며, 데이터 변경 사항을 추적합니다.

1. 영속성 컨텍스트의 주요 개념

2. 영속성 컨텍스트의 주요 기능

(1) 1차 캐시

• 영속성 컨텍스트 내부에 엔티티 객체를 캐싱하여 관리.
• 동일한 식별자를 가진 엔티티를 여러 번 조회할 경우, 데이터베이스를 재조회하지 않고 1차 캐시에서 반환.

// 첫 번째 조회 -> 데이터베이스에서 조회 후 1차 캐시에 저장
User user1 = em.find(User.class, 1L);

// 두 번째 조회 -> 1차 캐시에서 반환 (SQL 실행되지 않음)
User user2 = em.find(User.class, 1L);

System.out.println(user1 == user2); // true

(2) 엔티티 동일성 보장

• 동일한 트랜잭션 내에서는 같은 식별자를 가진 엔티티 객체는 **동일성 (==)**을 보장.

User user1 = em.find(User.class, 1L);
User user2 = em.find(User.class, 1L);

System.out.println(user1 == user2); // true (동일 객체)

(3) 변경 감지 (Dirty Checking)

• 영속성 컨텍스트는 관리 중인 엔티티의 변경 사항을 감지하고, 트랜잭션 커밋 시 자동으로 데이터베이스에 반영.

User user = em.find(User.class, 1L); // 영속 상태
user.setName("Updated Name");       // 엔티티 수정 (Dirty Checking 발생)

em.getTransaction().commit();       // UPDATE 쿼리 실행

(4) 쓰기 지연 (Write-Behind)

• 엔티티 변경 작업(INSERT, UPDATE, DELETE)은 즉시 실행되지 않고, 쓰기 지연 저장소에 SQL이 누적된 후 트랜잭션 커밋 시점에 한꺼번에 실행.

User user = new User();
user.setName("John");

em.persist(user); // INSERT SQL이 즉시 실행되지 않고 쓰기 지연 저장소에 저장
em.getTransaction().commit(); // INSERT SQL 실행

(5) 지연 로딩 (Lazy Loading) 지원

• 연관된 엔티티를 필요할 때 로드하는 지연 로딩을 지원.

User user = em.find(User.class, 1L); // User만 조회
List<Order> orders = user.getOrders(); // 이 시점에 Order 조회 쿼리 실행

3. 엔티티 생명주기

4. 영속성 컨텍스트의 동작 방식

(1) 엔티티 저장

• 영속성 컨텍스트에 엔티티를 저장하고 관리.
• em.persist(entity) 호출 시 영속 상태로 전환.

(2) 엔티티 조회

• em.find() 호출 시, 영속성 컨텍스트의 1차 캐시에서 먼저 조회.
• 1차 캐시에 없으면 데이터베이스에서 조회 후 1차 캐시에 저장.

(3) 변경 내용 반영

• 영속 상태의 엔티티가 변경되면 변경 감지를 통해 자동으로 데이터베이스에 반영.

(4) 트랜잭션 커밋

• 쓰기 지연 저장소의 SQL을 한꺼번에 실행하고 트랜잭션을 종료.

5. 영속성 컨텍스트의 활용 예시

기본 사용 흐름

EntityManagerFactory emf = Persistence.createEntityManagerFactory("example-unit");
EntityManager em = emf.createEntityManager();

EntityTransaction transaction = em.getTransaction();
transaction.begin();

try {
    // 엔티티 저장 (비영속 → 영속)
    User user = new User();
    user.setName("John");
    em.persist(user);

    // 엔티티 조회 (1차 캐시 사용)
    User foundUser = em.find(User.class, user.getId());

    // 엔티티 수정 (Dirty Checking)
    foundUser.setName("Updated Name");

    // 트랜잭션 커밋 (쓰기 지연 SQL 실행)
    transaction.commit();
} catch (Exception e) {
    transaction.rollback();
} finally {
    em.close();
}
emf.close();

6. 영속성 컨텍스트의 장점

1. 1차 캐시로 성능 최적화
   • 동일 트랜잭션 내에서 중복 조회를 방지.
2. 변경 감지로 데이터 자동 반영
   • 코드의 단순화 및 일관성 유지.
3. 쓰기 지연으로 효율적 SQL 처리
   • 트랜잭션 커밋 시점에 한 번에 SQL 실행.
4. 데이터 일관성 보장
   • 동일성 보장(==)으로 엔티티 간의 데이터 충돌 방지.

7. 영속성 컨텍스트 사용 시 주의사항

(1) 메모리 사용량 증가

• 영속성 컨텍스트에 관리 중인 엔티티가 많아질 경우 메모리 사용량이 증가할 수 있음.
• 해결 방법:
  • em.clear() 또는 em.detach(entity)로 필요하지 않은 엔티티를 준영속 상태로 전환.

(2) LazyInitializationException

• 지연 로딩 사용 시, 트랜잭션이 종료된 상태에서 프록시 객체 접근 시 오류 발생.
• 해결 방법:
  • 트랜잭션 내에서 데이터를 모두 로드하거나, FETCH JOIN 사용.

(3) 쓰기 지연의 데이터 충돌

• 쓰기 지연으로 인해 트랜잭션 종료 시점에 SQL 실행 중 충돌 가능.
• 해결 방법:
  • 중요한 작업 시 명시적 flush() 호출.

8. 결론

영속성 컨텍스트는 JPA에서 핵심적인 역할을 하며, 데이터의 상태를 관리하고 성능 최적화를 지원합니다. 하지만, 이를 효율적으로 활용하기 위해 N+1 문제, Lazy Loading, 메모리 사용량 등 주의점을 고려해야 합니다. 설계와 구현 단계에서 영속성 컨텍스트의 동작을 명확히 이해하고 사용하는 것이 중요합니다.

1차 캐시

📌 엔티티를 영속성 컨텍스트에 저장할 때 생성되는 메모리 내 캐시이다. 엔티티는 먼저 1차 캐시에 저장되고 이후 같은 엔티티를 요청하면 DB를 조회하지 않고 1차 캐시에서 데이터를 반환하여 성능을 높일 수 있다.

더보기

• 영속성 컨텍스트의 1차 캐시에 저장된다.

// 비영속
Tutor tutor = new Tutor(1L, "wonuk", 100);

// 영속, 1차 캐시에 저장
em.persist(tutor);

• 영속된 Entity 조회

• Database가 아닌 1차 캐시에 저장된 Entity를 먼저 조회한다.

// 1차 캐시에서 조회
Tutor findTutor = em.find(Tutor.class, 1L);

public static void main(String[] args) {
    // EntityManagerFactory 생성
    EntityManagerFactory emf = Persistence.createEntityManagerFactory("test");
    // EntityManager 생성
    EntityManager em = emf.createEntityManager();
    // Transaction 생성
    EntityTransaction transaction = em.getTransaction();

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

    try {
        // 비영속
        Tutor tutor = new Tutor(1L, "wonuk", 100);

        // 영속
        System.out.println("persist 전");
        em.persist(tutor);
        System.out.println("persist 후");

        Tutor findTutor = em.find(Tutor.class, 1L);

        System.out.println("findTutor.getId() = " + findTutor.getId());
        System.out.println("findTutor.getName() = " + findTutor.getName());
        System.out.println("findTutor.getAge() = " + findTutor.getAge());

        // transaction이 commit되며 실제 SQL이 실행된다.
        transaction.commit();
    } catch (Exception e) {
        // 실패 -> 롤백
        e.printStackTrace();
        transaction.rollback();
    } finally {
        // 엔티티 매니저 연결 종료
        em.close();
    }
    emf.close();
}

z

실행결과

• 1차 캐시의 Entity를 조회한다.
  • 조회 SQL이 실행되지 않는다.
• 트랜잭션 Commit 시점에 INSERT SQL이 실행된다.

**트랜잭션(Transaction)**은 데이터베이스 작업에서 데이터의 일관성, 무결성을 보장하기 위해 논리적으로 묶여있는 작업 단위를 의미합니다.

 

데이터베이스에 저장된 데이터 조회

• 1차 캐시는 동일한 트랜잭션 안에서만 사용이 가능하다.
• 요청이 들어오고 트랜잭션이 종료되면 영속성 컨텍스트는 삭제된다.

동일성 보장

📌 동일한 트랜잭션 안에서 특정 엔티티를 여러 번 조회해도 항상 같은 객체 인스턴스를 반환한다. 영속성 컨텍스트는 1차 캐시를 사용하여 같은 엔티티를 중복 조회해도 동일한 객체를 참조하게 하여 일관성을 유지한다.

• 동일한 트랜잭션 내에서 조회된 Entity는 같은 인스턴스를 반환한다.
• DB에 저장된 데이터를 조회하여 1차 캐시에 저장한다.
• 1차 캐시에 저장된 데이터를 조회한다.

JPA의 동일성 보장 (Identity)

JPA에서 동일성(Identity)은 영속성 컨텍스트가 같은 엔티티 객체를 하나만 관리하여, 동일한 엔티티를 여러 번 조회해도 항상 같은 객체를 반환하는 특성을 의미합니다. 이를 통해 객체 간의 일관성과 효율적인 데이터 관리가 가능합니다.

주요 개념

동일성 보장의 동작 방식

1. 동일 엔티티를 조회할 때 동일 객체 반환
   • 같은 트랜잭션 안에서 같은 식별자(@Id)를 가진 엔티티를 조회하면 영속성 컨텍스트의 1차 캐시에 있는 동일 객체를 반환.

   User user1 = em.find(User.class, 1L); // 첫 번째 조회
   User user2 = em.find(User.class, 1L); // 두 번째 조회
   
   System.out.println(user1 == user2); // true (동일 객체)
   

2. 변경 감지(Dirty Checking)와의 연계
   • 동일 객체가 관리되므로 변경 사항은 영속성 컨텍스트를 통해 자동 감지되고 데이터베이스에 반영.

   user1.setName("Updated Name");
   // 트랜잭션 커밋 시, 변경 내용이 데이터베이스에 자동 반영.
   

3. 다른 트랜잭션에서는 동일성 보장 불가
   • 트랜잭션이 다르면 영속성 컨텍스트가 다르므로 동일 객체로 관리되지 않음.

   User user1 = em1.find(User.class, 1L); // 첫 번째 트랜잭션
   User user2 = em2.find(User.class, 1L); // 두 번째 트랜잭션
   
   System.out.println(user1 == user2); // false (다른 트랜잭션, 다른 객체)
   

동일성과 동등성 비교

동일성 보장의 장점

1. 데이터 일관성 유지
   • 동일 엔티티를 변경하면 모든 참조 객체가 동일하게 반영.
2. 성능 최적화
   • 동일 엔티티를 여러 번 조회해도 데이터베이스를 다시 조회하지 않고 1차 캐시 사용.
3. 관리의 편리성
   • 영속성 컨텍스트가 엔티티의 생명주기를 관리하여 복잡성을 줄임.

주의 사항 및 한계

1. 트랜잭션 범위 제한
   • 동일성 보장은 같은 영속성 컨텍스트 내에서만 유효.
2. Lazy Loading 주의
   • 프록시 객체를 사용할 경우 == 연산이 예상대로 동작하지 않을 수 있음.
3. 1차 캐시 메모리 관리
   • 1차 캐시가 크면 메모리 사용량 증가 및 성능 저하 가능.

결론

JPA의 동일성 보장은 객체 지향적 데이터 관리를 가능하게 하고, 데이터 일관성을 유지하며, 성능을 최적화하는 데 중요한 역할을 합니다. 그러나 트랜잭션과 영속성 컨텍스트 범위에 따라 보장이 달라지므로, 이를 이해하고 활용하는 것이 중요합니다. 😊

쓰기 지연