ワークロード視点の地図 ─ 6 軸でデータを見る
特性駆動の流派は「ワークロードから始めろ」と言う。だが「ワークロード」と一括りにされる対象は実は多次元で、それを構成する軸を持っていないと、結局「何となく RDB」「流行ってるから NoSQL」という選定に逆戻りする。
この章では、ワークロードを 6 軸で分解する地図を立てる。これが特性駆動の語彙になる。
6 軸でデータを見る
軸 1：read/write 比率
| 比率 | 例 | 適性 DB |
|---|---|---|
| read 圧倒的（99:1） | コンテンツ配信、商品カタログ | Cache（Redis）+ RDB / 列指向 |
| read >> write（90:10） | 多くの SaaS の OLTP | RDB（PostgreSQL）+ Cache |
| read ≒ write（50:50） | チャット、ジョブキュー | Stream（Kafka）/ KV（DynamoDB） |
| write 圧倒的（10:90） | IoT センサー、ログ | Time-series / Stream |
この軸を見ずに RDB を選ぶと、write 圧倒的なワークロードで詰む。逆に read 圧倒的なら、Cache の前段が必須。
軸 2：レイテンシバジェット
| バジェット | 用途 | 適性 |
|---|---|---|
| μs オーダー（マイクロ秒） | 高頻度取引、ad bidding | In-memory（Redis、ScyllaDB） |
| ms オーダー（〜10ms） | OLTP、API リクエスト | RDB + Cache、DynamoDB |
| 〜100ms | Web 画面、検索 | RDB、Search engine |
| 秒オーダー | 分析クエリ | OLAP（ClickHouse、DuckDB） |
| 分・時オーダー | バッチ、ETL | DWH（BigQuery、Snowflake） |
レイテンシバジェットを 1 桁見誤ると、設計全体が破綻する。
軸 3：整合性モデル
| モデル | 意味 | 例 |
|---|---|---|
| Strong / Linearizable | 最新の書き込みを必ず読める | Spanner、CockroachDB |
| Snapshot | スナップショット時点で一貫 | PostgreSQL（MVCC）、MySQL |
| Causal | 因果順序は保証 | DynamoDB（条件付き）、Cassandra |
| Eventual | いつか一貫する | DynamoDB（デフォルト）、S3 |
Linearizable を要求しないシーンで Spanner を使うのは過剰。Eventual で良いシーンで Postgres を分散させるのは無理。整合性モデルは要件と実装能力の合わせ目。
軸 4：データ形状
| 形状 | 例 | 最適 |
|---|---|---|
| 行（Row） | OLTP のレコード | RDB |
| 列（Column） | 分析対象、aggregation | ClickHouse、BigQuery |
| KV | session、設定、cache | Redis、DynamoDB |
| Document | JSON、可変 schema | MongoDB、DynamoDB |
| Stream | event、log | Kafka、Pulsar |
| Graph | 関係性、SNS | Neo4j、TigerGraph |
| Vector | embedding、類似度検索 | Pinecone、pgvector、Redis |
データ形状を間違えると、クエリパフォーマンスが 10 倍遅いことが起きる。
軸 5：データ寿命
| 寿命 | 性質 | 戦略 |
|---|---|---|
| Hot（数分〜数日） | 直近の操作データ | In-memory + 永続化 |
| Warm（数日〜数月） | 通常の業務データ | OLTP DB |
| Cold（数月〜数年） | アーカイブ、監査 | OLAP DWH、S3 |
| Forever | 法的保管、event log | Object storage + Stream |
寿命を考えずに 1 つの DB に全部入れると、最終的に Hot ワークロードが Cold データに引きずられて遅くなる。Tiering / Archive 戦略は最初から想定する。
軸 6：スケール軸
| 軸 | 性質 | 例 |
|---|---|---|
| Vertical | 1 ノードを大きく | PostgreSQL 単体 |
| Read scale-out | replica で読みを散らす | RDB + read replica |
| Sharding | データを複数ノードに分割 | MongoDB、Vitess |
| Geo-distributed | 複数リージョン跨ぎ | Spanner、CockroachDB |
地理跨ぎが要件にないのに NewSQL を選ぶのは過剰。1 ノードで足りるのに最初から分散にすると複雑性で負ける。
各 DB のプロファイル
主要 DB を 6 軸で簡単に整理すると：
| DB | read/write | レイテンシ | 整合性 | データ形状 | 寿命 | スケール |
|---|---|---|---|---|---|---|
| PostgreSQL | read 寄り | ms | Snapshot | 行 | Hot+Warm | Vertical+Replica |
| DynamoDB | 半々〜write | ms | Causal/Eventual | KV/Doc | Hot+Warm | Sharding（auto） |
| Redis | read 圧倒 | μs | Strong（単一 node） | KV+構造 | Hot | Sharding（Cluster） |
| ClickHouse | read 寄り | 秒 | Eventual（merge） | 列 | Warm+Cold | Sharding |
| Kafka | append-only | ms | Causal | Stream | Hot+Warm（retention） | Partitioning |
| Spanner | read 寄り | 数十 ms（geo） | Linearizable | 行（SQL） | Warm | Geo-distributed |
1 つの DB で 6 軸全てを最適化できる魔法はない。だから “purpose-built databases”（Vogels）になる。
6 軸を見るレーダーチャート
graph TB
subgraph "DB 選定 = 6 軸の合致"
A[読み書き比率] --> M{自分のワークロード}
B[レイテンシ] --> M
C[整合性] --> M
D[データ形状] --> M
E[寿命] --> M
F[スケール] --> M
M --> R[Postgres / DynamoDB / Redis / ClickHouse / Kafka / Spanner ...]
end
style M fill:#e1f5ff
style R fill:#fff4e1この 6 軸プロファイルが、DB 選定の「起点」になる。ドメイン側からの要求（前章）と、この軸プロファイルが合流する地点で、設計判断が生まれる。
Pat Helland の Inside vs Outside
ここで一つの古典を導入する。Pat Helland の論文 “Data on the Outside vs. Data on the Inside” (CIDR 2005) は、データを 2 種類に分類した：
Inside Data: 1 つの DB の中で、トランザクションで保護される、可変なデータ
Outside Data: DB の境界の外に出て流通する、immutable な、ID で参照される、メッセージ・イベント・ファイル等
この 2 分類が現代の Polyglot Persistence の根拠になっている。Inside は OLTP DB が担う。Outside は Stream / Object Storage / Search Index 等に流れる。Inside と Outside の橋渡しが、データプラットフォーム設計の核心だ ── これは第 12 章 Stream と第 17 章 Polyglot で深掘りする。
graph LR
subgraph "Inside data（可変、Trans 保護）"
DB[OLTP DB]
end
subgraph "Outside data（immutable、ID 参照）"
S[Stream]
OS[Object Storage]
SI[Search Index]
end
DB -.CDC / Outbox.-> S
S -.consumed.-> OS
S -.consumed.-> SI
style DB fill:#e1f5ff
style S fill:#ffe1e1
style OS fill:#ffe1e1
style SI fill:#ffe1e1この観点を入れると、「単一 DB でドメイン全てを担う」考え方が、現代では成立しない理由が見える。
この章の要点
- ワークロードは 6 軸（read/write 比率・レイテンシ・整合性・データ形状・寿命・スケール）で分解できる
- 各 DB は特定の軸の組み合わせに最適化されており、1 つで全部はカバーしない
- これが Werner Vogels の “purpose-built databases” 戦略の根拠
- Pat Helland の Inside vs Outside が、複数 DB を持つ世界の地図を提供する
次章への問いかけ
6 軸の地図を立てた。次は具体的なワークロードに降りる。
第 4 章から第 15 章までは、6 つのワークロード（OLTP / OLAP / Cache / NoSQL / Stream / NewSQL）を「本質編」と「設計編」の 2 章ずつで深掘りする。最初は OLTP の本質 ── PostgreSQL の MVCC・WAL・行指向の世界から始める。