Phase 7레슨 32

Bigtable

SSTable, MemTable, LSM Tree, Tablet — 페타바이트 규모의 구조화된 저장

💡ELI5·

편지함과 Bigtable

Bigtable 데이터 모델:
  (row_key, column_family:column, timestamp) → value

  예: "com.example.com" 행
    contents:html   t3 → "<html>..."
    contents:html   t2 → "<html>..(이전 버전)"
    anchor:cnn.com  t1 → "CNN"
    anchor:bbc.com  t1 → "BBC"

  행 키로 정렬 → 범위 조회 가능
  컬럼 패밀리 단위로 저장 → 같은 패밀리는 디스크에 인접

💡 비유 — 편지함. 각 편지함(행)은 주소(row key)로 정렬. 편지함 안에는 여러 칸(컬럼 패밀리)이 있고, 각 칸에 여러 편지(버전)가 시간순으로 쌓임. 특정 주소의 편지함을 빨리 찾고, 특정 칸의 최신 편지만 읽을 수 있음.

🔬Deep Dive·

LSM Tree 구조

쓰기:
  Client → MemTable (메모리) → 즉시 반환 (빠름!)
           ↓ 임계치 도달
           Flush → SSTable-1 (디스크, 순차 쓰기)
                    SSTable-2
                    SSTable-3
                    ↓ Compaction
                    SSTable-merged (정리 + 병합)

읽기:
  MemTable 확인 → 최신 SSTable → 오래된 SSTable (여러 개 확인)
  → 읽기가 B-Tree보다 느릴 수 있음 (대신 Bloom Filter로 보완)

구조	쓰기	읽기	적합
B-Tree	랜덤 I/O (느림)	한 번에 찾음 (빠름)	읽기 많음 (RDBMS)
LSM Tree	순차 I/O (빠름)	여러 파일 확인 (느릴 수 있음)	쓰기 많음 (Bigtable, Cassandra)

🔬Deep Dive·

Tablet — 분산의 단위

Tablet Server 1: Tablet [a-f]
Tablet Server 2: Tablet [g-p]
Tablet Server 3: Tablet [q-z]

데이터 증가 → Tablet [g-p]가 너무 커짐
→ 자동 분할: Tablet [g-j] + Tablet [k-p]
→ 한 서버에서 다른 서버로 이동 가능

Master: 어느 서버가 어느 Tablet을 담당하는지 추적
Chubby: Master 선출, Tablet 위치 메타데이터 저장

🔬Deep Dive·

Bigtable의 후손들

시스템	기반	추가 기능	적합
HBase	Bigtable + HDFS	강한 일관성, Hadoop 생태계	Hadoop 환경 일관성 필요
Cassandra	Bigtable + Dynamo	가용성 우선(AP), 튜닝 가능 일관성	높은 가용성, 쓰기 성능
RocksDB	LSM Tree (단일 노드)	임베디드 KV 저장소	단일 서버 고속 쓰기

⚖️Trade-off·

Bigtable 모델의 Trade-off

이점	희생
페타바이트 확장	조인 불가 (앱에서 처리)
높은 쓰기 처리량 (LSM)	읽기가 B-Tree보다 느릴 수 있음
자동 분할/이동	트랜잭션 없음 (단일 행만 원자적)
유연한 스키마	Compaction 비용 (주기적 부하)

❓ 체크포인트 질문

1.Bigtable이 RDBMS와 다른 점은?
2.LSM Tree가 B-Tree보다 쓰기 성능이 좋은 이유는?
3.Compaction이 왜 필요한가?
4.Tablet이 확장성의 핵심인 이유는?
5.Bigtable 모델이 적합한 사용 사례는?

← 이전

MapReduce

Spanner