꾸준함

[Hibernate/JPA] 캐싱

1. 데이터베이스 캐싱 1.1 캐싱의 계층 구조캐싱은 데이터베이스 성능 최적화의 핵심DB → OS → 애플리케이션 → (ORM) → 2차 캐시 → 1차 캐시 등 여러 계층에 걸쳐 존재디스크 접근을 최소화하고, DB/OS/애플리케이션 메모리에서 최대한 데이터를 제공하는 것이 핵심 1.2 캐시 동기화 전략 가. Cache-aside애플리케이션이 캐시에서 먼저 데이터를 찾고, 없으면 DB에서 조회 후 캐시에 넣음쓰기는 데이터베이스와 캐시를 모두 갱신해야 함 (동기화 주의 필요) 나. Read-through캐시에 데이터가 없을 때, 캐시 시스템이 DB에서 자동으로 데이터 조회 및 캐시 삽입애플리케이션에서는 항상 캐시만 조회 다. Write-through쓰기 작업이 캐시와 DB에 동시에 적용됨캐시 일관성 유..

서론 실제 금융/암호화폐/전자지갑 서비스에서 동시성 결함이나 트랜잭션 제어 미비로 인해 막대한 금액의 해킹 피해가 발생할 수 있으므로 보안과 데이터 무결성은 중요한 개념i.g. FlexCoin, Poloniex 해킹 사례여러 건의 출금을 거의 동시에 요청 → 음수 잔고 허용, 데이터베이스에 잘못된 레코드가 삽입되었고 이로 인해 시스템 무결성이 깨지고 공격자는 훨씬 더 많은 금액을 탈취함 트랜잭션 보장은 매우 중요한 개념구글 Spanner 등 신세대 DBMS조차 "트랜잭션을 포기하는 것보다, 필요할 때 성능 병목을 해결하는 것이 현명하다"라고 명시MongoDB 등도 결국 ACID 보장 기능을 추가 (4.0+ 버전부터 적용) 1. ACID와 트랜잭션 동시성 제어모든 DB 작업은 트랜잭션 내에서 진행됨Auto..

1. JDBC Statement Fetch Size 1.1 Statement Fetch Size란?JDBC Statement의 ResultSet은 DB 커서로, 한 번에 "몇 개의 행(row)"을 클라이언트로 가져올지 결정하는 값이 fetch sizestatement.setFetchSize(n)와 같이 설정하면n 개씩 데이터 fetch 하고네트워크 round-trip 횟수와 메모리 사용량에 직접적 영향을 끼침 1.2 DBMS별 기본 fetch size와 특징 가. Oracledefault fetch size: 1010g, 11g 드라이버는 최대 사이즈로 버퍼 미리 할당 (VARCHAR2(4000) 컬럼은 4000바이트)12c부터는 실제 데이터 크기만큼만 할당 (메모리 효율 ↑)Statement 캐싱 사용..

1. JDBC 배치 업데이트와 Hibernate 배치 1.1 JDBC 배치 업데이트(Batch Update) 기본 개념JDBC 2.0부터 여러 개의 INSERT, UPDATE, DELETE statement를 하나의 DB 요청으로 묶어 실행 가능addBatch()로 여러 statement를 쌓고executeBatch()로 한 번에 실행 JDBC 배치 업데이트를 실행함으로써 얻을 수 있는 이점은 다음과 같음데이터베이스 왕복 (Round Trip) 횟수 감소트랜잭션 응답 시간 대폭 단축대량 처리 (수천~수만 건)에서 필수적 성능 최적화 1.2 Statement vs PreparedStatement 배치Statement 배치는 각 SQL이 완전히 다른 정적 SQL일 때 실행드라이버/DB마다 지원 및 동작 방식..

1. Statement 생애주기와 실행 계획 1.1 Statement와 PreparedStatement의 실행 단계Statement는 SQL을 문자열로 직접 실행하며 매번 파싱과 실행 계획 수립 필요PreparedStatement는 다음과 같이 동작함SQL을 미리 컴파일바인드 변수로 파라미터화여러 번 실행 시 실행 계획을 재사용하여 성능 향상서버 측 Prepare/Execute로 동작 실행 단계Parsing: SQL 문법/구문 오류 체크, 내부 파싱 트리 생성Optimizer: SQL의 실행 계획 (Execution Plan)을 생성하며 인덱스 선택, 조인 순서/알고리즘, 통계 기반 비용 산정Executor: 실제 실행 계획에 따라 DB에서 데이터 읽고 결과 생성PreparedStatement는 실행 ..

1. 영속성 컨텍스트 (Persistence Context) 1.1 영속성 컨텍스트란?Persistence Context는 JPA(EntityManager), Hibernate(Session)에서 엔티티 상태와 변경사항을 관리하는 1차 캐시 역할 수행엔티티를 조회하면 해당 엔티티는 영속성 컨텍스트에 등록되어 엔티티 식별자를 키로 하는 Map에 저장됨같은 트랜잭션 내에서 동일 엔티티를 여러 번 조회해도, 영속성 컨텍스트에서 캐싱된 객체를 반환데이터베이스를 조회하지 않고 캐시를 조회하기 때문에 빠름 1.2 EntityManager와 SessionJPA의 EntityManager와 Hibernate의 Session은 영속성 컨텍스트의 API 역할을 하며, 기능적으로 거의 동일Hibernate 5.2부터는 Se..

1. JPA 상속 정리 1.1 JPA에서 상속이 중요한 이유상속은 도메인 모델에서 공통 속성과 비즈니스 로직을 추상 클래스 또는 인터페이스로 표현할 수 있게 해 줌엔티티 계층 구조를 통해 중복 코드와 설계 복잡도를 줄이고, 전략 패턴(Strategy Pattern), 방문자 패턴(Visitor Pattern) 등 행동 패턴 구현에 적합함데이터 구조(속성)의 재사용보다, 메서드의 다양화에 더 적합함데이터 재사용에는 컴포지션 패턴이 더 나음 1.2 상속과 전략 패턴 실전 예시구독자 발송 시스템을 예로 들면 다음과 같음Subscriber(부모): firstName, lastName, createdOn 등 공통 속성EmailSubscriber, SmsSubscriber(자식): 각자 email, phoneNu..

1. 관계형 데이터베이스의 테이블 관계와 JPA 매핑관계형 데이터베이스에는 대표적으로 일대다 (One-to-Many), 일대일 (One-to-One) 그리고 다대다 (Many-to-Many) 세 가지 테이블 관계가 존재함이러한 관계는 외래 키를 통해 정의되며, JPA와 Hibernate에서는 객체지향 모델의 단방향·양방향 관계에 맞춰 다양한 매핑 방법을 제공함 일대다 관계단방향: 자식(@ManyToOne), 부모(@OneToMany) 또는 부모의 @ElementCollection양방향: 자식(@ManyToOne), 부모(@OneToMany(mappedBy = ...)) 일대일 관계단방향: 자식(@OneToOne)양방향: 자식(@OneToOne), 부모(@OneToOne(mappedBy = ...)) 다대..

1. 데이터베이스 Primary Key의 종류와 설계 원칙자연 키 (Natural Key): 주민등록번호, ISBN, 차량 식별 번호 등 자연스럽게 정의된 고유값장점: 비즈니스적으로 의미가 있어 직관적단점: 일반적으로 길이가 길어 인덱스·외래키·저장 공간이 비효율적이고, 변경 가능성도 존재 대체 키 (Surrogate Key): 시스템적으로 부여하는 IDENTITY, SEQUENCE, UUID 등장점: 크기가 작고(숫자), 인덱스·외래키·조인·클러스터드 인덱스 등에서 성능상 유리UUID는 128 비트라 역시 공간 비효율, 일반적으로는 숫자형 auto-increment/sequence가 선호됨 공간 효율성: PK가 클수록 모든 보조 인덱스와 외래키에도 그 크기만큼 부담PK가 작을수록 데이터베이스 IO, 인..

1. JPA/Hibernate의 타입 매핑 구조JPA와 Hibernate는 Java 객체를 관계형 데이터베이스에 영속화할 때 다양한 타입 매핑 방식을 제공하며 대표적으로 다음 세 가지 범주가 있음기본 타입(Basic Types): Integer, Long, String, Float, Enum 등과 같이 데이터베이스의 단일 컬럼에 매핑되는 타입임베디드 타입(Embeddable Types): 여러 컬럼을 하나의 Java 컴포넌트로 그룹화해 매핑할 수 있음 i.g. 주소( Address)와 같은 객체가 여러 컬럼을 가질 때 사용엔티티 타입(Entity Types): 데이터베이스의 테이블과 직접적으로 매핑되는, 각각의 식별자 (Primary Key)를 가지는 객체 2. 컬럼 타입의 컴팩트함이 중요한 이유데이터베..