[SQL] 스토리지 엔진

데이터베이스 스토리지 엔진

데이터베이스 스토리지 엔진(Storage Engine)은 DBMS가 물리적으로 데이터를 저장·관리·조회·수정하는 핵심 모듈임.
쉽게 말해, “어떻게 디스크(또는 기타 저장매체)에 데이터를 기록하고, 트랜잭션을 처리하며, 인덱스·동시성·로그 등을 관리하는가?”를 결정하는 역할을 맡음.
대표적으로 MySQL은 다양한 스토리지 엔진(InnoDB, MyISAM, Memory, etc.)을 플러그인 형태로 제공해, 사용자가 요구 사항에 따라 선택·조합할 수 있음.
하지만 Oracle, PostgreSQL, SQL Server 등은 (대체로) 내부적으로 단일 통합 엔진을 사용하며, 내부 아키텍처 수준에서 스토리지 엔진을 구성함.

 

스토리지 엔진의 주요 기능

1. 데이터 파일 구조 & 페이지 관리

데이터를 페이지(블록) 단위로 관리하는 것이 일반적임(크기는 DBMS마다 4KB ~ 16KB 등).

테이블 또는 인덱스에 접근할 때, 해당 페이지를 메모리(버퍼 캐시)에 로딩해 읽고, 수정(Dirty Page)이 일어나면 일정 시점에 다시 디스크에 기록(Flush)함.

 

2. 인덱스 관리

B+트리, Hash, R-Tree, 전문 검색(Fulltext) 등 다양한 인덱스 구조를 지원할 수 있음.

가장 보편적인 인덱스 구조는 B+트리로, 범위 검색, 정렬, 특정 키 조회에 뛰어난 성능을 제공함.

 

3. 트랜잭션 & 동시성 제어

ACID(원자성, 일관성, 격리성, 지속성) 보장을 위해 트랜잭션 로그(REDO, UNDO), 잠금(Lock) 또는 MVCC 등을 구현함.

MVCC(Multi-Version Concurrency Control)를 활용하면 읽기 작업과 쓰기 작업이 최대한 충돌 없이 동작하도록 유도함.

 

4. Write-Ahead Logging(WAL)

트랜잭션을 커밋할 때, 수정된 페이지를 직접 디스크에 쓰기 전에 로그(REDO/WAL)에 먼저 기록해 두는 기법임.

장애가 발생하더라도 로그를 재적용(REDO)하면 최근 커밋 상태로 복구가 가능해짐.

 

5. 복구(Recovery)

장애 이후 DB 재시작 시, 스토리지 엔진은 로그(REDO/UNDO)를 사용해 마지막 커밋 시점까지 데이터를 일관되게 복원함.

 

6. 물리적/논리적 스토리지 조직

테이블스페이스(Tablespace), 세그먼트(Segment), 익스텐트(Extent), 블록(페이지) 구조로 계층화해 데이터를 조직함.

대규모 테이블이나 인덱스가 확장될 때, 일정 단위(Extent)로 물리 파일 공간을 할당함.

 

MySQL의 플러그인 스토리지 엔진 아키텍처 : MySQL 서버 계층 vs 스토리지 엔진 계층

MySQL은 크게 SQL 레이어(Optimizer, Parser, Cache, etc.)와 스토리지 엔진 레이어로 나눌 수 있음.

 

1. SQL 레이어

쿼리를 파싱하고 최적화(옵티마이저), 실행 계획 수립, 쿼리 캐시(8.0 이전) 등을 수행함.

 

2. 스토리지 엔진

실제로 데이터를 읽고 쓰는 작업을 담당하며, 테이블/인덱스 구조 및 내부 포맷, 트랜잭션 관리, B+트리 구성 등 세부 로직을 구현함.

 

MySQL의 플러그인 스토리지 엔진 아키텍처 : 대표 스토리지 엔진

1. InnoDB

MySQL 기본(디폴트) 엔진이자, ACID 트랜잭션과 외래키를 지원.

MVCC 기반의 동시성 제어, Write-Ahead Logging, 잠금(Row-level Lock) 등을 제공해 신뢰도 높은 트랜잭션 처리 가능.

대부분의 프로덕션 환경에서 권장되는 표준 엔진.

 

2. MyISAM

MySQL 초기(5.5 이전) 디폴트 엔진.

단순 구조 덕분에 읽기 성능은 빠를 수 있으나, 트랜잭션 미지원, 테이블 수준 잠금으로 동시성에 약점이 있음.

최근에는 거의 쓰이지 않는 추세.

 

3. Memory(Heap)

테이블 데이터를 메모리(RAM)에 저장.

재시작 시 데이터가 휘발되므로 임시 결과나 세션 임시 저장용으로 쓰일 수 있음.

 

4. CSV, Archive, Federated, NDB Cluster 등

각각 특수 목적(로깅, 외부 DB 접속, 클러스터 분산 저장)으로 사용.

대부분 프로덕션에서 핵심 테이블 용도로 사용하기엔 제한적이거나 보조적 의미가 큼.

 

InnoDB 스토리지 엔진의 내부 구조 (대표 예시)

1. InnoDB 버퍼 풀(Buffer Pool)

디스크 I/O를 줄이기 위해, 데이터를 페이지 단위로 메모리에 캐싱해둠.

수정된 페이지(Dirty Page)는 일정 시점에 쓰레드를 통해 디스크로 기록(Flush).

LRU(Least Recently Used) 등 교체 알고리즘으로 자주 사용되는 페이지를 최대한 메모리에 유지.

 

2. 테이블스페이스 구조

InnoDB는 기본적으로 공유 테이블스페이스(ibdata1)와 각 테이블별 독립 테이블스페이스(ibd 파일) 방식을 제공.

기본 설정은 각 테이블마다 .ibd 파일로 분리되어 관리하는 일괄 테이블스페이스 모드가 일반화(innodb_file_per_table=ON).

 

3. Redo 로그, Undo 로그

Redo 로그: 변경 내용을 재적용하기 위한 로그. ib_logfile* 등으로 저장되며, 장애 발생 시 “커밋된 상태”를 복원.

Undo 로그: 트랜잭션 롤백 및 MVCC(과거 버전을 통해 일관성 조회) 구현에 필요. Undo 정보는 언두 세그먼트(Undo Segment) 형태로 관리됨.

 

4. MVCC(다중 버전 동시성 제어)

InnoDB는 UPDATE/DELETE 시점에 Undo 로그에 이전 데이터를 보관하여, 다른 트랜잭션이 해당 시점의 스냅샷을 읽을 수 있게 함.

이를 통해 읽기 락(Read Lock)을 최소화하고, 높은 동시성(Concurrency)을 제공.

 

5. Doublewrite 버퍼

페이지 Flush 시 데이터를 안전하게 기록하기 위한 메커니즘.

일단 Doublewrite 버퍼 영역(공유 테이블스페이스 내)에 두 번 쓰고, 나중에 최종 위치에 적용하여 디스크 손상(Partial Write)을 방지.

 

Oracle, PostgreSQL 등의 스토리지 엔진 개요 : Oracle

오라클 아키텍처에서는, DB 자체가 단일 통합 엔진 형태를 취함.

SGA(System Global Area): 버퍼 캐시, 로그 버퍼 등을 포함한 메모리 구조.

데이터 파일은 블록 단위(보통 8KB)로 저장되며, Redo 로그, Undo(또는 Rollback) 세그먼트를 통해 트랜잭션 복구 및 MVCC를 구현함.

다양한 고급 기능(파티셔닝, RAC, ASM 등)을 엔진 레벨에서 지원.

 

Oracle, PostgreSQL 등의 스토리지 엔진 개요 : PostgreSQL

PostgreSQL 또한 단일 엔진 모델이며, 내부적으로 MVCC를 구현해 테이블 페이지에 각각의 row 버전을 보관함.

변경 시 새로운 튜플 버전을 페이지에 기록하고, “dead tuple”이 쌓이면 VACUUM 작업을 통해 정리.

WAL(Write-Ahead Logging) 파일(“pg_wal”)을 사용해 장애 복구를 보장함.

 

트랜잭션 처리와 동시성 제어 메커니즘

1. 락(Lock) 모델

Row-level lock: 특정 로우 단위로만 잠금을 설정해 동시성을 높임(InnoDB, Oracle, PostgreSQL).

Table-level lock: 구형 MyISAM 엔진처럼 테이블 전체를 잠그면 동시성은 떨어지나 구조가 단순.

 

2. MVCC(Multi-Version Concurrency Control)

스토리지 엔진에서 과거 버전의 데이터를 별도로 보관해, 읽기 트랜잭션이 쓰기 트랜잭션과 충돌 없이 진행할 수 있도록 함.

Undo 로그, Tuple Versioning 등 다양한 구현 방식이 있지만, 핵심 아이디어는 “읽기 요청에게는 스냅샷 제공, 쓰기는 새로운 버전 생성”임.

 

3. Log Sequence Number(LSN)

Redo 로그에 기록되는 시점을 식별하기 위한 번호.

스토리지 엔진은 LSN을 통해 “어디까지 로그를 재적용해야 하는지, 어느 시점까지 데이터 파일이 반영되었는지” 등을 관리.

 

스토리지 엔진 선택 고려 사항 (MySQL)

1. 트랜잭션 필요 여부

트랜잭션, 외래 키, MVCC 등이 필요하다면 InnoDB 사용이 사실상 표준.

단순 읽기 위주 & 스키마가 빈번히 바뀌지 않는 특수 상황이라면 MyISAM을 쓸 수도 있지만 권장되지 않음.

 

2. 성능 특성

대량의 임시 데이터 처리가 필요한 경우, 메모리 엔진(HEAP)을 사용할 수 있지만 영속성은 없음.

로그성(Write-Once, Read-rarely) 데이터는 Archive 엔진 등으로 압축·저장할 수도 있음.

 

3. 데이터 무결성 & 외래 키 제약

InnoDB만이 외래 키(Foreign Key)를 지원하므로, 참조 무결성(Referential Integrity)이 필요한 RDBMS 설계에는 필수.

 

4. 고급 기능 지원

파티셔닝, 온라인 DDL, 복제(Replication) 최적화, 장애 복구 툴, 쿼리 캐시 등 엔진별 지원 기능이 다름.

예를 들어, InnoDB는 ALTER TABLE 시 일부 온라인 DDL을 지원, MyISAM은 테이블 잠금에 의해 DDL 중단이 쉬움.

 

최신 동향: Row vs Column Store, NewSQL 등

1. 컬럼 스토어(Columnar Storage)

대규모 분석(OLAP) 워크로드에서 열(컬럼) 단위로 데이터를 저장·압축·처리해 집계에 유리.

MySQL/MariaDB의 ColumnStore, PostgreSQL의 Citus/Timescale, Oracle의 In-Memory Column Store 등이 예시.

 

2. NewSQL

전통적인 RDBMS와 NoSQL의 장점을 결합하려는 시도.

고성능, 분산 스토리지 엔진 기반으로 ACID를 유지하면서도 수평 확장을 노리는 DBMS (예: CockroachDB, Google Spanner 등).

 

3. 엔터프라이즈/클라우드 솔루션

AWS Aurora(MySQL/PostgreSQL 호환), Google Cloud Spanner, Azure SQL Database 등은 클라우드 네이티브 아키텍처로 자동 확장·백업·복구를 지원.

내부 스토리지 엔진은 분산 파일 시스템이나 오브젝트 스토리지와 연계해 “Shared Storage, Shared CPU” 모델을 사용.

 

요약 및 결론

스토리지 엔진은 데이터베이스가 디스크·파일시스템 레벨에서 데이터를 어떻게 저장, 검색, 변경, 복구하는지를 결정하는 핵심임.

 

1. 페이지 구조, 인덱스 방식(B+트리 등), 트랜잭션 처리(WAL, Redo, Undo), 동시성(MVCC, Lock), 복구 알고리즘 등이 스토리지 엔진마다 다를 수 있음.

2. MySQL은 플러그인 형태로 여러 엔진을 제공하나, InnoDB가 사실상의 표준으로 자리 잡았음.(ACID 보장, MVCC, 외래 키 등)

3. Oracle, PostgreSQL, SQL Server 등은 단일 통합 스토리지 엔진을 사용하지만, 내부적으로 유사한 개념(버퍼 캐시, Redo/Undo, MVCC, LSN 등)으로 구현되어 있음.

4. 최근에는 분산·클라우드 환경 및 OLAP/실시간 분석 요구에 맞게 컬럼 스토어, NewSQL 등 다양한 엔진이 발전하고 있음.

 

따라서 스토리지 엔진을 깊이 이해하면, 트랜잭션 장애 복구, 인덱스 효율, 동시성 문제, 디스크 I/O 병목 등을 미리 예측하고, SQL 튜닝이나 DB 설계에서 더 적절한 의사 결정을 내릴 수 있음.

결국 데이터베이스 성능과 안정성의 상당 부분은 스토리지 엔진의 내부 구조와 운영 메커니즘에 달려 있다고 해도 과언이 아님.