Storage-Workload Architecture Taxonomy
OLTP·OLAP·HTAP·LTAP를 시스템·워크로드·스토리지 티어·가시성·copy 수로 기술하는 어휘
핵심 개념
트랜잭션·분석·하이브리드·공유 스토리지 시스템의 경계가 흐려지면서, 아키텍처를 명확히 논하려면 공유 어휘가 필요하다. Jack Vanlightly의 taxonomy는 다섯 차원으로 시스템을 분류한다: 시스템 수, 워크로드 수, 가시성(언제 다른 워크로드에서 데이터가 보이나), durable copy 수(캐싱 제외).
- OLTP(row-based) / OLAP(columnar)는 두 워크로드 + 특화 엔진·스토리지
- HTAP: 단일 시스템, 두 워크로드(row + columnar를 stitch)
- LTAP(Databricks): 두 워크로드 + 두 시스템(Postgres + lakehouse) + 두 스토리지의 blend
- tiering: 한 시스템이 hot→cold 이동(1 copy, 2 tier)
- materializing: 한 시스템이 다른 시스템으로 copy(2 copy)
6가지 분류
| Type | Systems | Workloads | Vis | Copies | Example |
|---|---|---|---|---|---|
| Single Tier | 1 | 1 | - | 1 | Postgres + SSD |
| Internal Tiering | 1 | 1 | - | 1 | Kafka tiered storage, ClickHouse MergeTree |
| Hybrid (HTAP) | 1 | 2 | Sync/Async | 1 | SingleStore, TiDB, Snowflake Hybrid tables |
| Materializing | 2 | 2 | Async | 2 | ETL/Connectors, Confluent Tableflow |
| Shared Tiering | 2 | 2 | Async | 1 | LTAP, Apache Fluss |
Hybrid의 두 sub-category
- Freshness-by-composition: 동기 dual write(OLAP가 column-store만 hit) 또는 비동기 복제 + merge-on-read로 일관 뷰 (SingleStore, SAP Hana)
- Freshness-by-catchup: OLAP 쿼리를 비동기 복제된 columnar store로 라우팅. 강한 일관성은 columnar store가 query LSN에 도달해야 서빙 (PolarDB-IMCI, TiDB/TiFlash)
HTAP vs LTAP
- HTAP: 단일 hybrid 시스템이 트랜잭션·분석 쿼리에 동시 가시성
- LTAP: 두 시스템(각기 다른 워크로드)의 데이터를 unify하고 colder 데이터를 공유해 durable copy 불필요. fundamentally async — hottest는 System A에만, colder는 System B에 저장되되 A의 cold tier로 제공. 둘이 같은 플랫폼이면 Shared-Sync-RR로 veering하며 다시 HTAP와 murky해짐
자주 가려지는 차원 — 데이터 모델
unified OLTP-OLAP marketing이 흔히 가리는 것: OLTP의 3NF와 분석의 Kimball(star/snowflake). 둘 다 원하면 보통 Materialization이 필요(star schema는 3NF의 cold tier로 부적합). 즉 query engine·storage layout·storage substrate 외에 데이터 모델도 차원이다.
저자 견해: “zero-copy/one-copy”는 과한 marketing — copy 수를 주 설계 포인트로 삼는 건 이상하며 현실은 더 nuanced(materialization에선 시스템별 독립 expiration으로 중복이 0.0027%일 수도).
연관 개념
- Real-Time Stream Processing — stream-table duality, Fluss의 shared tiering
- Catalog-Managed Tables — lakehouse의 materialize/tier 대상
- Database Concurrency Control — OLTP 엔진
- Query Optimization — OLAP 엔진
- Data Modeling — 3NF vs Kimball 차원
- DuckDB — 임베디드 OLAP
Source: Can We Agree on a Storage-Workload Architecture Taxonomy