階層型DBMSの極意：PHDAM / PHIDAMによる大規模データ時代の物理スキーマ設計
こんにちは。チーフアーキテクトの私だ。
今日のコードレビューで、また「なんとなく」パーティションを切っただけの甘い物理スキーマを見かけた。リレーショナルデータベース（RDBMS）のシャスディングやパーティショニングの感覚で階層型DBMS（IMSなど）を触ると、確実にシステムは崩壊する。
特に、テラバイト級、あるいはそれ以上の超大規模データセットを扱う現場において、PHDAM（Partitioned Hierarchical Direct Access Method）とPHIDAM（Partitioned Hierarchical Indexed Direct Access Method）の選択と物理定義（DBD: Database Definition）は、システムの生死を分ける決定打となる。
今日は、このPHDAMとPHIDAMの深層を抉り出し、実務の現場で即座に使える堅牢な設計パターンを伝授しよう。
—
1. なぜ PHDAM / PHIDAM なのか？（アーキテクチャの本質）
従来のHDAMやHIDAMは、単一の巨大なOSファイル（あるいはデータセット・グループ）として管理されていた。しかし、現代のデータ量は、1つのストレージ領域にすべてを収めることを許さない。
- PHDAM: ハッシュアクセスによる高速なルートセグメント検索を維持しつつ、データセットを物理的に複数のパーティションに分割する。
- PHIDAM: 高度な索引（Primary Index）を用いた順次アクセスを維持しつつ、同様にパーティション分割を行う。
ここで重要なのは、「論理的な階層構造は1つに見せかけながら、物理的なストレージとI/Oを完全にスケールアウトさせる」という点だ。これを見誤ると、ホットスポット（特定のパーティションへのI/O集中）が発生し、どんなに高価なハードウェアを並べてもスループットは頭打ちになる。
—
2. 実践：DBD（Database Definition）のコードレビュー
百聞は一見に如かず。まずは、私がプロジェクトで厳格にレビュー・承認しているPHDAMのDBDマクロ定義のサンプルを見せよう。
———————————————————————-
- PHDAM データベース定義 (DBD) のサンプル
———————————————————————-
DBD NAME=CUSTDB,ACCESS=PHDAM 階層型かつパーティション化HDAMを指定
- 仮想ストレージおよびバッファプール要件の定義
DATASET BLOCK=(4096,35790), ブロックサイズとオプティマム値
OSAM, アクセス方式 (OSAM/VSAM)
RDBASE=CUSTLIB データセット群のベース名
- セグメント階層の定義
SEGM NAME=CUSTSEG, ルートセグメント (顧客マネージャ)
PARENT=0, 親なし (ルート)
BYTES=(120,50), 最大長 / 平均長
PTR=NOTWIN 同一階層ポインタ不要 (ルートのため)
- ルートセグメントのランダム化ルーチン (RPA) の指定
- ※ここがPHDAMの命運を握る。衝突率の低いアルゴリズムを選定せよ。
LCHILD NAME=(CUSTX,CUSTLIB), パーティション索引への言及
POINTER=SNGL ポインタ指定
DEVTYPE=3390 デバイスタイプ
DBDGEN DBD生成の終端
FINISH
END
チーフアーキテクトの視点：ここがポイントだ
1. ブロックサイズとストレージ効率
`BLOCK=(4096,35790)` の指定を見てほしい。ここではOSAM（Overflow Sequential Access Method）を使用している。ブロックサイズに対する実効容量のチューニングを怠ると、OSレベルのI/Oペナルティをモロに食らう。
2. ランダム化ルーチン（Randomizing Module）の選定
PHDAMの性能は、ルートセグメントをどのブロックに割り振るかを決める「ハッシュ関数（ランダム化ルーチン）」の出来栄えで9割決まる。偏ったキー設計を放置してランダム化任せにすると、特定のパーティションだけがオーバーフローし、連鎖的なI/O遅延を引き起こす。
—
3. PHDAM vs PHIDAM：どう使い分けるべきか？
設計レビューで最も多く受ける質問がこれだ。「先生、ウチのデータはPHDAMとPHIDAM、どっちにすべきですか？」
私の答えは一貫している。「アクセスパスの偏りとバッチ処理の要件を見ろ」。
| 評価軸 | PHDAM (Partitioned HDAM) | PHIDAM (Partitioned HIDAM) |
| :— | :— | :— |
| 主アクセス方式 | ハッシュ（ダイレクト・アルゴリズム） | 索引順次（Primary Index経由） |
| ルート検索性能 | 圧倒的に高速（理論値 1～2 I/O） | 索引ツリーの分、ややコスト増 |
| 順次処理（Seq Scan）| 極めて非効率（バラバラに配置されるため） | 極めて効率的（索引順にスキャン可能） |
| 向いている用途 | オンライントランザクション（OLTP）でキー直叩きするデータ | 月次バッチなどで全件シーケンシャル処理が必須のデータ |
現場の判断基準
- OLTP主体の顧客マスタ・口座マスタ: PHDAMを選べ。秒間数千件のランダムアクセスをさばくにはこれしかない。ただし、パーティション境界を決めるキー範囲（High Key）の設計には細心の注意を払え。
- 履歴データ・集計前提のトランザクション: PHIDAMを選べ。バッチ処理で「キー順にきれいに舐めたい」という要件がある場合、PHDAMを選ぶとヘッドのシークが暴発し、バッチウィンドウに確実に収まらなくなる。
—
4. パーティション定義（PSB/Partition Definition）の堅牢な設計パターン
データベース定義（DBD）だけでは完了しない。パーティションの境界値（High Key）を定義するパーティション定義（HALDB Partition Definitionなど）が不可欠だ。
ここで適当なキー設計をすると、後からパーティションの分割・統合（スプリット/マージ）を行う羽目になり、現場の運用チームから殺意を向けられることになる。
堅牢なキー設計のアンチパターンと正解
- 【アンチパターン】連番（オートインクリメント）をパーティションキーにする
- 末路: すべての新規INSERTが「最後のパーティション」に集中し、真のパラレル処理が完全に崩壊する。
- 【正解】業務的な分散キー（顧客IDのハッシュプレフィックス、あるいは地域コード ＋ タイムスタンプ）にする
- 理由: データの発生源が均等に各パーティションへ分散するため、PHDAM/PHIDAMの並列I/Oの恩恵を100%引き出せる。
—
5. パフォーマンス・チューニングの極意：I/Oの呪縛から逃れるために
最後に、実務でパフォーマンス問題に直面したときの処方箋を授ける。
1. Free Spaceの適切な配分
PHDAM/PHIDAMともに、データセット内には「将来の挿入（Insert）」のためのFree Space（FSE）を確保する必要がある。これをケチると、すぐにオーバーフローエリアへの飛びつきが発生し、チェイン（ポインタの連鎖）が伸びきってI/Oが激増する。定期的な統計情報の採取と、再編成（Reorganization）の自動化を設計段階から組み込め。
2. バッファプール（BFPOOL）の独立管理
パーティションごとにアクセス頻度が異なる場合、すべてのパーティションを同一のバッファプールに相乗りさせてはならない。ホットスポットとなるパーティションには専用の高速バッファプールを割り当て、LRUアルゴリズムのヒット率を極限まで高めろ。
—
総括
PHDAMおよびPHIDAMの設計は、単なる「データ置き場の分割」ではない。
ハードウェアの物理特性、OSのI/O境界、そしてアプリケーションのアクセスパターンを完全に理解した者だけが描ける「建築物」だ。
「動けばいい」という妥協は、大規模データの海の前では一瞬で瓦解する。
次の設計レビューでは、君たちがロジカルで隙のないパーティション戦略を持ち寄ることを期待している。質問があればいつでも私の席に来たまえ。
コメント