db-partitioning-sharding

db-partitioning-sharding (M16)

スケーリングのトポロジは パフォーマンスとスケール（軸 performance）です。リレーショナルの Escala w12（M17/M2/M9 と共有）と、NoSQL プロファイルの Shard-key / Partición&hot カテゴリに反映されます。失敗の方向は対称的です。スケーリングが 遅すぎる（パーティショニングすべき巨大テーブル）場合と、早すぎる（単一ノードで難なく処理できる 5 GB のデータベースをシャーディングする）場合があります。

チェック内容

1. パーティショニングの適合性 — Postgres の宣言的な範囲／リストパーティショニング（低コストのプルーニング、高速な保持期限切れデータの削除）の利点が見込める、大規模な追記専用／時系列テーブル（イベント、ログ、メトリクス）が単一のヒープになっているかを確認します。
2. ホットパーティション／偏ったキー — カーディナリティが低い、または時間的に偏りのあるパーティションキー／シャードキー（例：tenant_id でパーティショニングしているが、1 つのテナントがトラフィックの 90% を占める場合や、すべての書き込みが「今日」のパーティションに集中する場合）を確認します。ワイドカラムストアでは、イベントテーブルの上限のない／ホットなパーティションは、実際の書き込みレートの証拠がある場合に severity:5（perf）です。証拠がなければ directional です。
3. 時期尚早なシャーディング — サイズやスループットの根拠がないまま、アプリケーションレベルのシャーディング／複数シャードを導入していないかを確認します。メリットがないまま、シャード間クエリやリバランシングのコストが増加します。

スコア／軸

performance のみを反映します（リレーショナルの Escala w12、Shard-key document / Partición&hot KV+WC / Escala vector+graph）。

Tier-0（静的解析）

パーティショニングの DDL（PARTITION BY、子パーティション）、選択されたパーティションキー／シャードキーと見かけ上のカーディナリティ、命名や列（タイムスタンプ＋挿入頻度が高いことを示す情報）から候補となる大規模テーブル、およびシャードへのファンアウト処理を検出します。テーブルの サイズ、行数、パーティションごとの書き込みレートは実行時の情報です。Tier-0 では needs_api とし、暗黙の合格にはしません。

Tier-1/2（検証クエリ、Postgres）

-- partition inventory + sizes (Tier-1):
SELECT inhparent::regclass AS parent, inhrelid::regclass AS partition,
       pg_size_pretty(pg_total_relation_size(inhrelid)) AS sz
FROM pg_inherits ORDER BY pg_total_relation_size(inhrelid) DESC;
-- candidate (unpartitioned) large tables:
SELECT relname, pg_size_pretty(pg_total_relation_size(oid)) AS sz, reltuples::bigint AS est_rows
FROM pg_class WHERE relkind='r' ORDER BY pg_total_relation_size(oid) DESC LIMIT 20;

メソッド schema_introspect / query_stat。パーティショニングされていない大規模テーブルがあれば、パーティショニング適合性の検出結果を established とします。パーティションごとの偏りの検証には Tier-2 の書き込み統計が必要です。統計がない場合、ホットパーティションは directional とし、上限判定には決して使いません。

検出結果

schema/finding.schema.json に従って検出結果を出力します。例：

• M16.events.unpartitioned_large_table — 単一のヒープである大規模な追記専用テーブル（severity:3、warn、軸 performance、確信度は Tier-1 で established／Tier-0 で needs_api、fixable: advisory）。
• M16.metrics.hot_partition_today — すべての書き込みが現在のパーティションに集中している／偏ったキー（severity:3、warn、静的解析では directional／Tier-2 では established。WC のイベントテーブルで実際の書き込みレートが確認できる場合のみ severity:5、fixable: advisory）。
• M16.app.premature_sharding — サイズやスループットの根拠がないシャーディング（severity:2、warn、directional、fixable: advisory）。

各検出結果では、evidence.observed に DDL／シャードコード／カタログ行をそのまま引用します。verification.reproduce には、$DATABASE_URL を参照する上記のクエリを指定します。expected_impact は範囲と確信度タグを付けます（パーセンテージのみの記載は禁止）。

誠実性

• パーティショニングには実際のオーバーヘッド（プランニング時間、パーティションをまたぐ制約）があります。真に大規模なテーブル、または保持期限やプルーニングの要件があるテーブルに限って推奨し、デフォルトでは推奨しません。
• パーティショニングの正当化（または反証）のために、行数やテーブルサイズを決して捏造しません。サイズに関する主張には Tier-1 が必要です。Tier-1 の情報がなければ needs_api を出力します。
• ホットパーティションの sev-5 には、実際の書き込みレートの証拠が必要です。静的なキーのカーディナリティ推測は directional のままであり、上限判定には使えません。
• これらはアーキテクチャ上の変更なので、advisory（具体的な宣言的パーティショニングへの移行案がある場合は proposed）とし、決して auto にはしません。