[SQL] 버퍼 캐시

버퍼 캐시

데이터베이스 버퍼 캐시(Buffer Cache)는 디스크 I/O를 최소화하고 전체 성능을 높이기 위해 최근 사용되었거나 자주 사용되는 데이터 페이지(블록)를 메모리에 보관하는 메커니즘임.

이를 통해 디스크 접근 횟수를 줄여 읽기/쓰기 작업을 빠르게 처리하며, 동시에 장애 복구, 동시성 제어와도 밀접하게 연동됨.

 

버퍼 캐시의 기본 개념

1. 디스크 블록을 메모리에 캐싱

데이터베이스 테이블, 인덱스 등은 물리적으로 디스크의 블록(또는 페이지) 단위로 저장됨.

애플리케이션이 데이터를 읽거나 수정할 때, DB 엔진은 해당 블록을 버퍼 캐시(메모리)로 가져온 뒤 작업을 수행함.

 

2. 왜 필요한가?

디스크 I/O는 메모리 접근보다 훨씬 느림.

버퍼 캐시에 미리 블록을 저장해 두면 재사용이 가능해, 반복되는 쿼리(또는 로우 액세스)에서 디스크를 다시 읽는 것을 피할 수 있음.

 

3. 캐시 크기와 효율

버퍼 캐시가 충분히 클수록 자주 사용되는 블록을 메모리에 오래 유지할 수 있어 성능이 개선됨.

반면 너무 크게 설정할 경우, 운영체제 레벨에서 메모리 부족이 발생하거나, 관리 오버헤드가 커질 수 있으므로 균형 설정이 중요함.

 

버퍼 캐시 구조와 동작 : 블록 단위 관리

RDBMS 대부분은 4KB ~ 16KB 사이의 고정 크기 페이지(블록) 단위로 데이터를 관리함.

Oracle은 보통 8KB, InnoDB의 기본 페이지는 16KB 등임.

버퍼 캐시는 이런 블록을 담을 수 있는 슬롯(Slot)들로 구성되며, 각 슬롯에 어느 테이블/인덱스의 어느 블록이 적재되어 있는지 메타데이터를 유지함.

 

버퍼 캐시 구조와 동작 : LRU 등 교체 알고리즘

LRU, LRUK, Clock, 또는 2Q, 3Q 등 다양한 캐싱 알고리즘을 사용하여 “가장 최근에 사용된 블록”을 유지하고, “오랫동안 사용되지 않은 블록”을 제거(교체)함.

InnoDB는 LRU 리스트, Young/Old 분리, Flush 리스트 등 여러 자료구조로 세분화해 관리함.

Oracle, PostgreSQL도 유사한 원리를 활용함.

 

버퍼 캐시 구조와 동작 : Dirty page와 Clean Page

Clean Page: 버퍼 캐시에 올라와 있지만, 디스크에 있는 내용과 동일한 상태.

Dirty Page: DBMS가 해당 페이지를 수정했으나, 아직 디스크에 기록(Flush)되지 않은 상태.

DBMS는 체크포인트(Checkpoint) 이벤트 등을 통해 Dirty Page를 디스크에 쓰면서 Redo 로그 및 Undo/Undo 세그먼트와 동기화함.

 

버퍼 캐시와 트랜잭션, 로그의 관계 : WAL

다수의 DBMS(InnoDB, PostgreSQL 등)는 WAL 기법을 사용함.

데이터를 버퍼 캐시(메모리)에서 수정하기 전에, Redo 로그(WAL 로그)에 먼저 기록한 뒤 변경을 적용함.

이는 장애 시 로그를 재적용(REDO)해, 수정사항을 복구할 수 있도록 해줌.

 

버퍼 캐시와 트랜잭션, 로그의 관계 : Undo/Rollback Segment 또는 MVCC

UPDATE/DELETE 작업 시 원본 데이터를 복구하거나, 특정 시점의 일관된 뷰를 제공하기 위해 Undo 정보를 생성함.

Oracle은 Undo Tablespace, InnoDB는 Undo 로그를 사용하여, Rollback이나 MVCC를 지원함.

이 Undo 정보 또한 버퍼 캐시와 밀접히 연동되어, 메모리에 올라온 내용을 통해 빠르게 롤백을 처리하거나 과거 버전을 조회할 수 있음.

 

버퍼 캐시 운영 메커니즘(예시)

아래는 MySQL InnoDB 버퍼 풀(Buffer Pool)을 예로 든 흐름임.

Oracle의 SGA(Buffer Cache), PostgreSQL의 Shared Buffer도 유사한 개념임.

 

1. 버퍼 풀 초기화

DB가 시작될 때, 설정값(innodb_buffer_pool_size 등)에 따라 버퍼 풀 메모리를 할당.

 

2. 페이지 요청 시

쿼리가 특정 블록을 읽으려고 하면,

버퍼 풀 내에 이미 로드된 페이지가 있는지 확인(해시 검색 등).

없으면 디스크에서 해당 블록을 읽어 버퍼 풀에 로드.

기존 페이지 중 LRU 알고리즘에 따라 교체할 페이지(가장 오래 사용되지 않은 등)를 선택해 새로운 페이지를 적재.

 

3. 쓰기 (INSERT / UPDATE / DELETE)

버퍼 풀에 해당 블록이 로드된 상태에서 메모리 내용을 변경(DML) → Dirty Page화.

Redo 로그(Write-Ahead Logging)에 먼저 기록해두고, 커밋 시점에서 로그를 디스크에 확실히 기록.

Dirty Page는 이후 체크포인트, Flush 스레드 등에 의해 디스크에 기록(Flush)됨.

 

4. 체크포인트(Checkpoint)

일정 시점 또는 Dirty Page가 많아지면, DBMS는 Redo 로그와 버퍼 풀 상태를 디스크와 동기화함.

이때 Dirty Page를 디스크에 반영(Flush)하고, Redo 로그의 Log Sequence Number(LSN) 등을 업데이트하여 장애 발생 시 복구 시점을 결정함.

 

5. 모니터링 및 통계

DBMS는 버퍼 풀 이용률, Dirty Page 개수, 히트율(Buffer Hit Ratio) 등을 모니터링하여 성능 최적화에 활용함.

 

성능적 이점과 최적화 전략

1. 캐시 히트율(Buffer Hit Ratio) 상승

버퍼 캐시가 커지고 효율적인 교체 알고리즘을 사용하면, 동일한 블록에 대한 재접근 시 디스크 I/O를 회피하여 성능을 크게 높일 수 있음.

 

2. 쓰기 작업(Dirty Page Flush) 지연

트랜잭션 커밋 시마다 데이터를 직접 디스크에 쓰지 않고, Redo 로그만 기록 후 일정 시점에 모아서 디스크에 반영함.

이를 통해 작은 단위의 쓰기 요청을 여러 번 하지 않고, 배치(Batch) 형식으로 처리해 I/O 부담을 줄임.

 

3. 버퍼 캐시 크기 설정

너무 작으면 자주 디스크 I/O가 발생.

너무 크면 운영체제 레벨에서 스왑(Swap)이 발생할 수도 있음.

워킹 셋(Working Set), 애플리케이션 특성, 시스템 메모리 등 고려하여 적절한 크기로 조정해야 함.

 

4. 다중 버퍼 풀/파티션

InnoDB나 일부 DBMS는 버퍼 풀을 여러 파티션으로 나누어 락 경합(Latch Contention)을 줄이기도 함.

대규모 시스템에서는 여러 버퍼 캐시를 병렬 처리하여 스레드 간 대기 시간 감소를 노림.

 

장애 복구와 버퍼 캐시

1. 장애 발생 시

버퍼 캐시에 있던 Dirty Page가 아직 디스크에 기록되지 않았다면, 커밋된 트랜잭션 정보라도 Redo 로그를 통해 재적용(복구)해야 함.

커밋되지 않은(롤백되어야 할) 내용은 Undo 로그를 통해 복원함.

 

2. 재시작 후 Warm-up

DB를 재시작하면 버퍼 캐시는 초기화되어 “차가운(cold) 상태”임.

일반적으로, “Warm-up” 시간이 걸려야 버퍼 캐시가 쿼리 패턴에 맞춰 페이지를 적절히 로딩하고 캐시 히트율을 끌어올릴 수 있음.

 

버퍼 캐시와 동시성 제어

1. 락(Lock) 혹은 래치(Latch)

여러 세션(스레드)이 동시에 동일한 페이지를 수정하거나 로드하려 할 때 충돌이 발생할 수 있으므로,

DBMS는 래치(Latch) 혹은 뮤텍스(Mutex)를 사용하여 버퍼 캐시의 안정성을 보장함.

 

2. MVCC와 버퍼 캐시

PostgreSQL, MySQL(InnoDB), Oracle 등에서 사용하는 MVCC는 버퍼 캐시 안에 여러 버전의 로우가 공존할 수 있도록 설계함.

Undo/Redo 정보와 결합하여, “읽기 트랜잭션”은 과거 버전을 보고, “쓰기 트랜잭션”은 새로운 버전을 생성해 충돌 최소화.

 

요약

버퍼 캐시(Buffer Cache)는 데이터베이스 핵심 엔진에서 가장 빈번히 사용되는 메모리 영역으로, 테이블/인덱스 블록을 디스크 대신 메모리에 보관함으로써 디스크 I/O를 대폭 줄이고 성능을 끌어올리는 역할을 담당함.

Dirty Page, Redo/Undo 로그, 체크포인트 등과 유기적으로 작동하여 ACID(Atomicity, Consistency, Isolation, Durability) 트랜잭션 특성을 지키면서도 성능을 극대화함.

효율적인 버퍼 캐시 운영을 위해서는 적절한 캐시 크기, 교체 알고리즘, 동시성 제어, 체크포인트 메커니즘이 조화를 이루어야 하며, 이는 제품마다 최적화 방식과 모니터링 포인트가 다를 수 있음.

결론적으로, 버퍼 캐시는 데이터베이스 성능을 좌우하는 핵심 구성 요소이며, 장애 복구 및 트랜잭션 일관성 측면에서도 중요한 역할을 담당함.