ルートアンカーポイント（RAP）の真実：HDAMの生死を握る「最初の一歩」の設計思想
こんにちは。チーフアーキテクトの私だ。
今日のコードレビュー、あるいは昨今のレガシーマイグレーションの現場で、若いエンジニアからこんな質問を受けた。
「なぜ今更、IMS DBのHDAM（Hierarchical Direct Access Method）やルートアンカーポイント（RAP）なんてものを気にする必要があるのですか？ リレーショナルデータベースのインデックス全盛の時代に、ハッシュとポインターの塊なんて骨董品でしょう？」
私はこう返した。
「甘い。データ構造の本質を理解していないから、RDBでも平気でO(N)のフルスキャンを発生させるクエリを書くのだ」
現代の分布式・KVSデータベースのパーティショニングやハッシング戦略のルーツは、まさにこのメインフレーム時代、HDAMの「ルートアンカーポイント（RAP）」に詰まっている。今回は、このRAPの構造、実務における設計パターン、そしてパフォーマンスの急所を、容赦ないエンジニアリングの視点から解き明かしていこう。
—
1. そもそもRAP（Root Anchor Point）とは何か
HDAM（Hierarchical Direct Access Method）は、ルートセグメントの検索にハッシュアルゴリズムを使用するダイレクト・アクセス手法だ。リレーショナルデータベースにおける「ハッシュ索引」や、NoSQLにおける「パーティションキーによるハッシュ分散」の祖先だと考えてもらえばいい。
HDAMブロック（通常はOSの物理ブロック、CI：Control Interval）の先頭に位置するのが、ルートアンカーポイント（RAP）である。
+——————————————————-+
| RAP 1 | RAP 2 | RAP 3 | … (RAPスロット領域) |
+——————————————————-+
| ルートセグメント A (ハッシュ値 -> RAP 1) |
+——————————————————-+
| 子セグメント B (ポインターで接続) |
+——————————————————-+
| フリースペース (Free Space) |
+——————————————————-+
処理の流れはこうだ：
1. アプリケーションがルートセグメントのキーを指定して検索/挿入を要求する。
2. HDAMランダムizingモジュール（ハッシュ関数）がキーを処理し、「どのCIの、何番目のRAPか」を算出する。
3. 指定されたCIのRAPが指し示すチェイン（ポインターリスト）を辿り、目的のセグメントに到達する。
つまり、RAPはハッシュ空間のバケットそのものであり、ルートセグメントへのエントリーポイントなのだ。
—
2. データベース定義（DBD）におけるRAPの設計
DBD（Database Description）のコーディングにおいて、HDAMのACCESSパラメータとRAPの指定は、システムの生死を分ける。具体的な定義を見てみよう。
—————————————————
- DBD定義例 (HDAM / RAP指定の勘所)
—————————————————
DBD NAME=CUSTDBO
DATASET DD1=CUSTDA01,DEV=3390,BLOCK=4096
SEGM NAME=CUSTSEGM,PARENT=0,
BYTES=(120,50),
PTR=TWINBWD
LCHILD NAME=(CUSTIXL,CUSTIXDB),
POINTER=SNGL
RMNAME =(DFPHDU01,10,500,2048)
- ——— — — —–
- (1) (2)(3) (4)
- (1) ランダムizingモジュール名
- (2) RAPの数 / CI (Control IntervalあたりのRAP数)
- (3) 最大ルードセグメント数 (ブロック上限)
- (4) バイト数上限 (Bytes limit)
この `RMNAME=(DFPHDU01, 10, 500, 2048)` の 「10」 という数値、これが1CIあたりのRAP数だ。
設計レビューで「とりあえずデフォルトのままでいいか」などと言おうものなら、その場でペンを置かせる。この数値の意味をロジカルに説明できなければならない。
—
3. 実務で直面する「RAPアンバランス」の悪夢
シニアエンジニアとしての経験から、本番障害で最も多かった原因の一つが「ハッシュの偏り（コリジョン：衝突）によるRAPの崩壊」だ。
罠1: RAP数が少なすぎる（チェインの肥大化）
1CIあたりのRAP数が少なすぎると、異なるキーが同じRAPにハッシュ値として落ちる確率（コリジョン）が跳ね上がる。
結果として、1つのRAPからぶら下がるルートセグメントの双方向ポインター（TWIN）のリストが長大化する。
- 症状: O(1)であるはずのハッシュアクセスが、実質的にO(N/RAP数)の線形探索（チェインスキャン）に堕ちる。CPU使用率が跳ね上がり、バッチ処理が夜間バッチの枠から溢れ出す。
罠2: RAP数が多すぎる（スペースの無駄撃ち）
逆に、RAP数を過剰に大きくするとどうなるか。
RAP領域自体がCI内の多くのスペースを消費するため、肝心のセグメントデータを格納するフリースペースが圧迫される。
- 症状: 「CIスプリット」や「オーバーフロー」が頻発し、物理I/Oの効率が劇的に悪化する。
—
4. 堅牢な設計パターン：プロフェッショナルのチューニング手法
では、どう設計すべきか。コードレビューで私が見るべきポイントは以下の3点だ。
① キーのカーディナリティと分散性の検証
ランダムizingモジュール（ハッシュ関数）に渡すルートキーの性質を見極めろ。
例えば、顧客番号（CUST-ID）の頭文字や、連番のプレフィックスが含まれているキーをそのままハッシュにかけると、特定のRAPにデータが集中する。
必要であれば、カスタムのランダムizingモジュールを作成し、キーのビットシフトやXOR演算を組み合わせて均等分散（Uniform Distribution）を担保しなければならない。
② フリー・スペース（FSE）との黄金比
CIサイズ（例: 4096バイト）に対して、セグメントの平均長と1CIあたりのレコード数から逆算してRAP数を決める。
一般的には、「1CIあたりの平均格納セグメント数 ≒ RAP数」、あるいはトラフィックのピーク時にチェイン長が平均して「2〜3個以内」に収まるようにチューニングするのが鉄則だ。
[理想的な状態]
RAP 1 -> [Seg A] (チェイン長: 1)
RAP 2 -> [Seg B] -> [Seg C] (チェイン長: 2)
RAP 3 -> [Seg D] (チェイン長: 1)
これを超えてチェインが伸びている場合、それは設計の敗北を意味する。
—
5. パフォーマンス監視とリビジョンの見極め
階層型DBMSであっても、RDBの実行計画チューニングと本質は同じだ。定期的にユーティリティ（IBMであれば `DFPReorg` や `HDAM` の統計レポート）を分析しろ。
- 確認すべきメトリクス:
- 最大チェイン長（Maximum Chain Length）
- 空きRAPの割合（Unused RAP Ratio）
- オーバーフロー・セグメントの発生率
もし「最大チェイン長」が許容値（例えば「5」など）を超えているセグメントグループを見つけたら、即座に以下のアクションを取れ：
1. ランダムizingモジュールの再評価
2. DBDの `RMNAME` パラメータにおけるRAP数の見直し（再定義と再ロード）
—
チーフアーキテクトからのメッセージ
「古い技術」と切り捨てるのは簡単だ。だが、データを物理アドレスやハッシュ、ポインターでどう配置し、CPUキャッシュやディスクI/Oのコストを最小化するかという物理設計の美学は、マイクロサービスの時代になっても1ミリも変わっていない。
君たちが次にデータベースのスキーマを設計するとき、あるいはKVSのパーティションキーを選ぶとき、今日の話を思い出してほしい。
「このキーのハッシュ先、つまりRAPはどこに落ちるのか？ そこに偏りは起きないか？」
その視点を持てるエンジニアこそが、真にスケーラブルで堅牢なシステムを作り上げることができる。
次のレビューでは、論理的かつ数学的に裏付けられた美しいDBD定義を持ってくることを期待する。健闘を祈る。
コメント