PHDAMの深淵：物理アドレスの極致とデータセット分離の哲学
現代の分散型キーバリュー・ストアが「パーティショニング」という言葉で喧伝している概念は、実は数十年前にメインフレームの深淵で完成されていた。それがPHDAM (Partitioned Hierarchical Direct Access Method)だ。
リレーショナルデータベースがインデックスの海で溺れている間、我々はポインタの連鎖で宇宙を構築してきた。なぜ今、PHDAMなのか。それは、ペタバイト級のデータをミリ秒でスキャンする必要があるとき、SQLの実行計画がゴミのように見えてくるからだ。
今日は、HDAMの概念を拡張し、物理的な制約を跳躍したPHDAMのアーキテクチャの真髄を解剖する。
—
1. PHDAMの本質：物理的制約からの解放
HDAM（Hierarchical Direct Access Method）は、ルートセグメントをランダム化関数（Randomizer）で直接アドレス指定し、物理的なI/Oを最小化する。しかし、単一のデータセット（OSAM/VSAM）では、OSのファイルサイズ制限や、単一ボリュームのI/Oボトルネックに直面する。
PHDAMは、このHDAMをパーティションという単位で物理的に分離する。
- 物理分割の妙: データベース全体を論理的に一つの木構造として扱いながら、物理的には複数のデータセット（パーティション）に分散する。
- ランダム化関数の再定義: PHDAMにおけるランダム化関数は、単にセグメントを配置するのではなく、どのパーティションに属すべきかを決定する「ルーター」の役割を果たす。
アーキテクトが理解すべきは、この「ルーター」と「物理オフセット」の計算コストが、システム全体のCPU負荷の9割を占めるという事実だ。
—
2. 内部メカニズム：ポインタの連鎖と物理アドレス
PHDAMの真骨頂は、セグメント間のポインタ構造にある。以下の図は、パーティションを跨ぐポインタの概念的フローだ。
[Partition A] [Partition B]
+—————-+ +—————-+
| Root Segment A |—–>| Child Segment B|
| (RAP offset) | | (Physical ptr) |
+—————-+ +—————-+
^
|
[Randomizer] -> Hash(Key) -> Partition Selector (ID)
ここで重要なのは、物理ポインタ（RBA: Relative Byte Address）の制約だ。
かつての32bit制限を突破するため、PHDAMは「Extended RBA」を採用している。この64bitのアドレス空間こそが、現代の大規模データを支える土台である。
アーキテクトへの警告：オーバーフロー領域の扱い
PHDAMの性能を決定づけるのは、`ROOT`セグメントが収まらない場合のオーバーフロー領域（Overflow Data Set）の設計だ。
ランダム化関数の衝突（Collision）が発生した際、同一パーティション内で解決するのか、あるいは別パーティションへ溢れさせるのか。このパラメータを誤ると、I/Oが指数関数的に増大する。
—
3. パフォーマンス最適化の極致：バッファプールと物理配置
PHDAMを運用する際、チューニングの対象はメモリだ。
/ 擬似的なバッファ管理ロジックの概念 /
void access_segment(key_t key) {
int part_id = get_partition(key); // ランダム化関数によるパーティション特定
buffer_pool_t bp = get_buffer_pool(part_id);
// RBA (64bit) を用いた高速なダイレクトアクセス
void segment = fetch_from_buffer(bp, rba_address);
if (segment == NULL) {
// バッファミス時の物理I/O発行 (ここがボトルネック)
issue_io(part_id, rba_address);
}
}
チーフアーキテクトの知見：
1. ランダム化関数の偏り: 均一に分散させるランダム化関数を書くのは難しい。パーティションごとの「埋まり具合（Utilization）」を常に監視し、再編成（Reorganization）の閾値を動的に変更せよ。
2. バッファの分離: パーティションごとにバッファプールを独立させろ。特定のパーティションへのアクセス集中が、システム全体を止めることを防ぐ唯一の手段だ。
3. LPAR（論理区画）との協調: PHDAMのパーティションを物理的に異なるボリューム、さらには異なるチャネルに配置することで、ハードウェアレベルのI/O並列性を引き出せ。
—
4. 結び：過去の遺物か、未来の青写真か
「階層型DBMSは古い」と口にする若手エンジニアは、疎結合なグラフ構造がいかに非効率かを理解していない。PHDAMは、データの局所性（Locality）を物理的な配置レベルで制御できる、現代でも稀有なアーキテクチャだ。
大規模なデータを扱うとき、汎用的なインデックス構造に頼るな。物理アドレスを直接制御し、ポインタの連鎖を支配せよ。PHDAMを理解することは、データベースエンジンの最深部で「データがどう生きているか」を理解することに他ならない。
次に設計するシステムが数ペタバイトのスケールに達したとき、この「古くて新しい」知見が、君のシステムの生存を分けることになるだろう。
以上だ。実装で迷ったら、まずはランダム化関数の出力分布をダンプすることから始めよ。真実は常に、そのバイナリの中に隠されている。
コメント