まずアクセスパターンを設計し、次にパーティショニング + 適切なインデックス/PKを選んで、単一クエリが小さく境界のあるスライスだけに触れ、決して100億行をスキャンしないようにします。100億レコードでのサブ100msは、より速いディスクの話ではありません。ワーキングセットを極小にする話です。
text
Query ─▶ Router ──▶ Partition (by tenant/time) ──▶ Index/PK lookup ─▶ ~thousands of rows
│ (prune 99.9% of data) (B-tree / sort key)
└─▶ Cache (Redis) ─▶ hit? return in <5ms
miss ▼
Columnar store (ClickHouse) for aggregates / scans
アクセスパターンがすべてを駆動する
技術を選ぶ前に問います： 「ユーザーXの直近20件の注文を取得」はポイント/レンジクエリで、パーティションキーとソートキーがそれに正確に一致してほしいです。「今月の地域別売上を合計」は分析スキャンで、行ストアは誤ったツールです。クエリを先にモデル化することが、機能する設計と、一見妥当だが全スキャンする設計を分けます。