数十億行を持つ単一テーブルをどのようにパーティション分割しますか？

Question

IT Interview Practice · Accepted Answer

**巨大なテーブルをパーティションキーで小さな物理的な子テーブルに分割し、各クエリが数十億行をスキャンする代わりに必要なパーティションだけに触れるようにします（パーティションプルーニング）。** 50億の注文行を持つテーブルでも1つの論理テーブルのように振る舞いますが、`WHERE` がパーティションキーでフィルタするとエンジンはその99%をスキップします。

## パーティション分割されたテーブルの形

```text
                 orders (logical parent)
                        │  partition key = created_at
       ┌────────────────┼────────────────┬───────────────┐
       ▼                ▼                ▼               ▼
 orders_2024_q1   orders_2024_q2   orders_2024_q3   orders_2025_q1
  (child table)    (child table)    (child table)    (child, active)
       │                                                  │
   local index                                        local index
   (per child)                                        (per child)
```

## パーティション戦略の選択

- **レンジ** — 日付/idの範囲で。時系列（注文、ログ、イベント）に最適。最近のデータがホットに保たれ、古い範囲を落とすのが容易。
- **ハッシュ** — `hash(key) % N` でNパーティションに均等分散。自然な範囲がなく負荷を均衡させたいときに使う（例：`user_id`）。
- **リスト** — 明示的なバケット（`region IN ('EU','US')`）。テナントやリージョンの分離に良い。

```sql
-- Postgres: range partition by month, prune on created_at
CREATE TABLE orders (id bigint, created_at date, amount numeric)
  PARTITION BY RANGE (created_at);

CREATE TABLE orders_2025_01 PARTITION OF orders
  FOR VALUES FROM ('2025-01-01') TO ('2025-02-01');

-- This scans ONLY orders_2025_01, not the whole table
SELECT sum(amount) FROM orders
 WHERE created_at >= '2025-01-01' AND created_at < '2025-02-01';
```

## プルーニング、インデックス、メンテナンス

- **パーティションプルーニング**はクエリが**パーティションキー**でフィルタする場合にのみ機能します。それ以外でフィルタすると全パーティションをスキャンします。これが最大のミスです。
- **ローカルインデックス** = 子ごとに1つのインデックス（Postgresのデフォルト）。パーティションとともに構築・削除が安価です。**グローバルインデックス**（Oracle）は全パーティションにまたがり、パーティションをまたぐ一意ルックアップに役立ちますが、1つを落とすと再構築が必要です。
- **メンテナンス**はO(partition)になります。古いデータを `DROP TABLE orders_2019`（即時、巨大な `DELETE` なし）でアーカイブし、ローリングウィンドウには `ATTACH`/`DETACH` を使います。

## 面接での観点

面接官は、あなたが**パーティショニングはインデックスではない**と理解しているかを探ります。パーティショニングはスキャンするデータを減らし、インデックスはスキャン内で調べる行を減らします。多くの場合両方が必要です。良い回答はレンジ/ハッシュ/リストを挙げます。優れた回答は**パーティションキーが支配的なクエリのフィルタに一致しなければならない**と強調し、誤ったキーがプルーニングを殺すと警告し、`DROP` による安価なアーカイブに言及します。

**トレードオフ：** クロスパーティションクエリ（キーフィルタなし、またはパーティションをまたぐ一意制約）は遅くなり、一意性の強制が難しくなります。1000万行のテーブルをパーティション分割してはいけません。利得なしに運用の複雑さを増やします。テーブルが巨大**かつ**クエリがキーで自然にスコープされるときにパーティション分割します。

パーティション分割されたテーブルの形

パーティション戦略の選択

プルーニング、インデックス、メンテナンス

面接での観点

関連する質問