[문제] RDBMS에서 데이터베이스 성능 최적화를 위한 인덱스 설계 원칙(B-Tree, 복합 인덱스, 커버링 인덱스, 파티셔닝)을 설명하고, 쿼리 실행 계획(Execution Plan) 분석 방법을 서술하시오. 또한 OLTP와 OLAP 환경의 차이점과 각각에 적합한 데이터 모델링 전략(3NF vs Star Schema)을 논하시오.
1. 인덱스 설계 원칙
| 인덱스 유형 | 특성 | 적합 용도 |
|---|---|---|
| B-Tree 인덱스 | 균형 이진 트리 구조. 범위 검색·정렬에 최적. 대부분 기본 인덱스 유형 | 등가 검색, 범위 검색, ORDER BY |
| 복합(Composite) 인덱스 | 여러 컬럼을 조합. 첫 번째 컬럼 선택도 중요 (카디널리티 높은 컬럼 앞에 배치) | WHERE 조건이 여러 컬럼일 때 |
| 커버링(Covering) 인덱스 | SELECT 컬럼을 모두 인덱스에 포함. 테이블 액세스 없이 인덱스만으로 쿼리 처리 | 자주 실행되는 SELECT 쿼리 최적화 |
| 파티셔닝 | 테이블을 Range·List·Hash로 분할. 파티션 프루닝으로 전체 스캔 회피 | 대용량 시계열 데이터, 날짜 기반 조회 |
인덱스 설계 원칙: ① 선택도 높은 컬럼 우선 ② WHERE·JOIN·ORDER BY 기준 컬럼 ③ DML 빈도 높은 테이블은 인덱스 최소화 (쓰기 성능 영향)
2. 쿼리 실행 계획 분석
EXPLAIN ANALYZE (PostgreSQL) 또는 EXPLAIN (MySQL)으로 실행 계획을 확인한다.
| 주요 확인 항목 | 의미·해석 |
|---|---|
| Full Table Scan | 인덱스 미사용. WHERE 조건에 맞는 인덱스 생성 검토 |
| Index Scan vs Index Only Scan | Index Only Scan이 더 효율적. 커버링 인덱스로 전환 |
| Nested Loop vs Hash Join | 소규모 결과셋: Nested Loop, 대규모: Hash Join이 유리 |
| Row 추정치 | 통계 정보 오래됨 시 rows 추정 오류 → ANALYZE/VACUUM 실행 |
3. OLTP vs OLAP — 데이터 모델링 전략
| 구분 | OLTP | OLAP |
|---|---|---|
| 목적 | 트랜잭션 처리 (주문·결제·업데이트) | 분석·집계 쿼리 (매출 분석, 트렌드) |
| 데이터 모델 | 3NF (정규화) — 중복 최소화, 쓰기 최적화 | Star Schema / Snowflake Schema — 읽기 최적화 |
| 쿼리 특성 | 단순·짧은 트랜잭션, 수 ms 응답 | 복잡한 GROUP BY·집계, 수 분 이상 |
| 저장소 | Row-Oriented (MySQL, PostgreSQL) | Column-Oriented (Redshift, BigQuery, ClickHouse) |
| Star Schema | — | 중앙 Fact Table + 주변 Dimension Table. JOIN 최소화, 집계 고속 |
[ 결론 ]
RDBMS 성능 최적화는 선택도 높은 인덱스 설계, 커버링 인덱스로 테이블 액세스 최소화, 파티셔닝으로 스캔 범위 축소가 핵심이다. OLTP는 3NF 정규화와 Row-Store, OLAP는 Star Schema와 Column-Store로 각 워크로드에 최적화된 모델링을 선택해야 한다.