3편 - SQLD 1과목 2장 : 데이터 모델과 성능
제2장. 데이터 모델과 성능
2.1 성능 데이터 모델링의 개요
2.1.1 성능 데이터 모델링이란?
데이터베이스 성능 향상을 목적으로 설계 단계의 데이터 모델에 대해 성능과 관련된 사항이 데이터 모델링에 반영될 수 있도록 하는 것이다.
2.1.2 성능 데이터 모델링 수행 시점
가능한 한 설계 초기 단계에 수행해야 한다. 나중에 성능 문제를 발견하면 해결 비용이 기하급수적으로 증가한다.
2.1.3 성능 데이터 모델링 수행 절차
1. 데이터 모델링을 할 때 정규화를 정확하게 수행
2. 데이터베이스 용량 산정
3. 데이터베이스에 발생되는 트랜잭션의 유형 파악
4. 용량과 트랜잭션의 유형에 따라 반정규화 수행
5. 이력 모델의 조정, PK/FK 조정, 슈퍼타입/서브타입 조정 수행
6. 성능 관점에서 데이터 모델 검증
2.2 정규화와 성능
2.2.1 정규화란?
정규화란 데이터의 일관성, 최소한의 데이터 중복, 최대한의 데이터 유연성을 위한 방법이며, 데이터를 분해하는 과정이다.
핵심 포인트: 정규화를 하면 일반적으로 입력/수정/삭제 성능이 향상되고, 조회 성능은 경우에 따라 향상되기도, 저하되기도 한다.
2.2.2 정규화 단계
(1) 제1정규형 (1NF)
한 속성에 여러 개의 값(다가 속성/반복 그룹)이 들어가지 않도록 한다.
위반 사례:
| 사원번호 | 이름 | 전화번호 |
|---|---|---|
| 001 | 홍길동 | 010-1234-5678, 02-111-2222 |
정규화 후:
| 사원번호 | 이름 |
|---|---|
| 001 | 홍길동 |
| 사원번호 | 전화유형 | 전화번호 |
|---|---|---|
| 001 | 휴대폰 | 010-1234-5678 |
| 001 | 집 | 02-111-2222 |
(2) 제2정규형 (2NF)
PK가 복합키일 때, PK의 일부에만 종속되는 속성(부분 함수 종속)을 제거한다.
위반 사례:
| 주문번호(PK) | 상품번호(PK) | 수량 | 상품명 | 단가 |
|---|---|---|---|---|
| O001 | P001 | 5 | 노트북 | 100만 |
여기서 상품명, 단가는 상품번호에만 종속 → 부분 함수 종속
정규화 후:
주문상세: (주문번호(PK), 상품번호(PK), 수량) 상품: (상품번호(PK), 상품명, 단가)
(3) 제3정규형 (3NF)
PK가 아닌 일반 속성 간의 종속 관계(이행 함수 종속)를 제거한다.
위반 사례:
| 사원번호(PK) | 이름 | 부서코드 | 부서명 |
|---|---|---|---|
| 001 | 홍길동 | D01 | 영업부 |
여기서 부서명은 부서코드에 종속 → 이행 함수 종속 (사원번호 → 부서코드 → 부서명)
정규화 후:
사원: (사원번호(PK), 이름, 부서코드(FK)) 부서: (부서코드(PK), 부서명)
2.2.3 정규화와 성능의 관계
| 구분 | 정규화의 영향 |
|---|---|
| 입력(INSERT) | 향상: 한 테이블에만 입력하면 됨 |
| 수정(UPDATE) | 향상: 중복이 없으므로 한 곳만 수정 |
| 삭제(DELETE) | 향상: 삭제 이상 현상 방지 |
| 조회(SELECT) | 상황에 따라 다름: JOIN이 늘어나면 저하, 데이터 양이 줄어들면 향상 |
2.3 반정규화와 성능
2.3.1 반정규화란?
반정규화(De-normalization)란 정규화된 엔터티, 속성, 관계에 대해 시스템의 성능 향상과 개발(Development)·운영(Maintenance)의 단순화를 위해 중복, 통합, 분리 등을 수행하는 데이터 모델링의 기법이다.
주의: 반정규화를 과도하게 하면 데이터 무결성에 문제가 생길 수 있다.
2.3.2 반정규화의 대상 판단
| 대상 | 설명 |
|---|---|
| 자주 사용되는 테이블 | 접근 빈도가 높은 테이블 |
| 대량의 범위 처리 | 대량의 데이터 범위를 자주 처리하는 경우 |
| 성능 상 이슈가 있는 테이블 | 통계성 프로세스에 의해 사용되는 테이블 |
| 테이블에 지나치게 조인이 많은 경우 | JOIN 성능 저하 |
2.3.3 반정규화의 기법
(1) 테이블 반정규화
| 기법 | 설명 |
|---|---|
| 테이블 병합 | 1:1 관계 또는 1:M 관계의 테이블을 하나로 합침 |
| 테이블 분할 | 수직 분할: 칼럼 기준 분리 / 수평 분할: 행 기준 분리 |
| 테이블 추가 | 중복 테이블, 통계 테이블, 이력 테이블, 부분 테이블 추가 |
(2) 칼럼 반정규화
| 기법 | 설명 |
|---|---|
| 중복 칼럼 추가 | 조인을 줄이기 위해 다른 테이블의 칼럼을 중복 저장 |
| 파생 칼럼 추가 | 계산 결과를 미리 저장 (합계, 평균 등) |
| 이력 테이블에 기능 칼럼 추가 | 최신 값 여부 등을 나타내는 칼럼 추가 |
(3) 관계 반정규화
중복 관계 추가: 이미 관계가 존재하지만 성능 향상을 위해 추가적인 관계를 설정
2.4 대량 데이터에 따른 성능
2.4.1 대량 데이터 발생에 따른 테이블 분할
(1) 수직 분할 (Vertical Partitioning)
칼럼 단위로 테이블을 분리한다.
적용 상황:
- 칼럼이 매우 많은 테이블
- 자주 사용되는 칼럼과 그렇지 않은 칼럼이 명확히 구분될 때
- LOB(Large Object) 칼럼이 있을 때
(2) 수평 분할 (Horizontal Partitioning)
행 단위로 테이블을 분리한다.
적용 상황:
- 데이터 건수가 수백만~수천만 건 이상
- 특정 조건(날짜, 지역 등)으로 조회 패턴이 명확할 때
파티셔닝 종류:
| 종류 | 설명 | 예시 |
|---|---|---|
| Range | 범위 기준 분할 | 월별, 연도별 |
| List | 특정 값 기준 분할 | 지역별, 상품코드별 |
| Hash | 해시 함수 기준 분할 | 고르게 분산 |
| Composite | 복합 분할 | Range + Hash |
2.5 데이터베이스 구조와 성능
2.5.1 슈퍼타입/서브타입 모델
슈퍼타입은 공통 속성을, 서브타입은 각 유형별 고유 속성을 관리하는 모델이다.
[직원] (슈퍼타입)
/ \
[정규직] [계약직] (서브타입)
물리 모델 변환 3가지 방법:
| 방법 | 설명 | 적합한 경우 |
|---|---|---|
| OneToOne (개별 테이블) | 슈퍼+서브 각각 별도 테이블 | 서브타입별 처리가 많을 때 |
| PlusType (슈퍼+서브 테이블) | 슈퍼타입 하나 + 서브타입 각각 | 공통+개별 처리 모두 필요할 때 |
| SingleType (통합 테이블) | 하나의 테이블로 통합 | 전체 통합 조회가 많을 때 |
2.5.2 인덱스 특성을 고려한 PK/FK 설계
PK 순서는 인덱스의 정렬 순서를 결정하므로 매우 중요하다.
-- PK가 (지역코드, 날짜, 일련번호)인 경우 -- 좋은 조회 (인덱스 선두 칼럼 활용): SELECT * FROM 매출 WHERE 지역코드 = 'A01' AND 날짜 = '20240101'; -- 나쁜 조회 (인덱스 선두 칼럼 누락): SELECT * FROM 매출 WHERE 날짜 = '20240101'; -- 지역코드 없이 날짜만 조회
핵심: PK의 첫 번째 칼럼이 WHERE 조건에서 가장 많이 사용되는 칼럼이어야 한다.
2.5.3 FK 제약조건과 인덱스
외래키에는 반드시 인덱스를 생성해야 한다. 그렇지 않으면 부모 테이블 변경 시 자식 테이블에 Full Table Scan이 발생할 수 있다.
2.6 분산 데이터베이스와 성능
2.6.1 분산 데이터베이스의 투명성
| 투명성 | 설명 |
|---|---|
| 분할 투명성 | 하나의 논리적 관계가 여러 단편으로 분할되어 각 사본이 여러 사이트에 저장됨을 인식할 필요 없음 |
| 위치 투명성 | 데이터의 저장 장소를 알 필요 없음 |
| 지역사상 투명성 | 각 지역 시스템 이름과 무관하게 데이터를 사용 가능 |
| 중복 투명성 | 데이터가 여러 곳에 중복되어 있더라도 하나의 데이터만 존재하는 것처럼 사용 |
| 병행 투명성 | 다수 트랜잭션이 동시에 실행되어도 결과에 영향 없음 |
| 장애 투명성 | 장애가 발생해도 트랜잭션이 정확하게 처리됨 |