데이터베이스 물리적 저장

데이터베이스 물리적 저장 (Database Physical Storage)

PostgreSQL이 데이터를 디스크에 실제로 어떤 모양으로 저장하는지 궁금했던 적 있나요? 이번 장에서는 데이터베이스가 사용하는 물리적 저장 형식(physical storage format)의 전반을 훑어볼게요. 테이블 하나가 파일로 어떻게 떨어지는지, 큰 값은 어디로 가는지, 페이지가 어떻게 생겼는지까지 — 내부 구조를 알아야 튜닝도 성능 분석도 제대로 할 수 있거든요.

출처: PostgreSQL 공식 문서 — storage

개요 (Overview)

이 장은 PostgreSQL 데이터베이스가 사용하는 **물리적 저장 형식(physical storage format)**에 대한 개요를 제공해요. SQL 레벨의 논리적 구조가 아니라, 그 논리적 구조가 디스크 위에서 실제로 어떻게 표현되는지를 다룬답니다.

그 내용은 크게 다음 하위 주제로 나뉘어 있어요.

저장 파일 배치 (Database File Layout)

  • 66.1. Database File Layout — 데이터베이스와 테이블이 파일 시스템 위에 어떤 구조로 배치되는지 살펴봐요. 테이블 하나의 데이터는 여러 8KB 페이지로 나뉘어 저장되는데, 이 파일 배치가 그 출발점이에요.

TOAST

큰 값(예: 아주 긴 텍스트, 큰 바이너리)을 일반 테이블 블록에 그대로 넣으면 행이 너무 커져서 페이지 하나에 못 들어가는 문제가 생겨요. TOAST가 바로 그 문제를 해결해요.

여유 공간 맵 (Free Space Map)

  • 66.3. Free Space Map — VACUUM이 관리하는 포크(fork)로, 각 페이지에 얼마나 여유 공간이 남아 있는지 기록해요. 새 데이터를 어느 페이지에 넣을지 정하는 데 쓰이죠.

가시성 맵 (Visibility Map)

  • 66.4. Visibility Map — 각 페이지가 "모든 행이 모든 트랜잭션에 보이는" 상태인지 표시해두는 포크예요. VACUUM과 index-only scan이 이 정보를 활용해요.

초기화 포크 (The Initialization Fork)

  • 66.5. The Initialization Fork — 새로 생성되는 릴레이션(relation)이 첫 데이터를 쓰기 전에 페이지를 초기화할 때 쓰는 포크에요.

데이터베이스 페이지 레이아웃 (Database Page Layout)

PostgreSQL은 데이터를 고정 크기 페이지(page, 기본 8KB) 단위로 관리해요. 이 페이지가 내부적으로 어떻게 구성되는지가 바로 성능과 공간 효율을 좌우해요.

힙 전용 튜플 (Heap-Only Tuples)

  • 66.7. Heap-Only Tuples (HOT) — 업데이트 시 발생하는 인덱스 부담을 줄이기 위한 최적화 기법이에요. 행을 위치 이동하지 않고 같은 페이지 안에서 갱신할 수 있게 해서, 인덱스 재작성 비용을 아껴요.

더 알아보기 (Learn more)