HDAMの極意：ハッシュ直接アクセスで階層型DBMSの限界を突破するアーキテクチャ設計
チーフアーキテクトの私だ。今日のコードレビュー、あるいは基本設計レビューで、また「とりあえずインデックスを貼る」という安易な設計を見かけた。リ relational な常識をそのまま階層型DBMS（IMSなど）に持ち込もうとする悪癖は、ここできっぱり断ち切る。
現代の分散KVSやNoSQLの原点であり、極限のパフォーマンスが要求されるメインフレームの世界でいまだに現役バリバリのアクセス方式、HDAM（Hierarchical Direct Access Method）について徹底的に叩き込む。
インデックスのルックアップコストすら許されない超高負荷環境において、如何にしてハッシュ関数でデータスペースを支配し、真の「O(1)に近いランダムアクセス」をもぎ取るか。その設計の全貌を共有しよう。
—
1. なぜHDAMなのか？ —— インデックス信仰の終焉
リレーショナルデータベース（RDBMS）であれば、B-Treeインデックスを構築して検索するのが王道だ。しかし、考えてみてほしい。B-Treeは階層を下るたびにポインタを辿り、I/Oが発生する。数千万件、数億件のオーダーを持つ基幹システムのマスターデータにおいて、この「わずか数回のI/O」が、ピーク時のスループットを確実に殺す。
HDAMは、この「インデックス探索というオーバーヘッドそのものを排除する」ために生まれた。
ルートセグメント（最上位セグメントオカレンス）のキー値を独自のハッシュ関数に投入し、ストレージ上の物理的な格納位置（RBA：Relative Byte Address あるいは UR：Unit of Work）を直接算出する。これにより、インデックスを経由することなく、ダイレクトにデータブロック（CI：Control Interval / データベースブロック）へ到達する。
[アプリケーション]
│
▼ (ルートキー)
[ハッシュ関数]
│
▼ (ダイレクト計算)
[物理ストレージ / CI] ──> ルートセグメントを一撃でヒット
この「潔さ」こそが、HDAMを極限の高速アクセスメソッドたらしめている所以だ。
—
2. HDAMスキーマ定義（DBD）の急所
では、実際のDBD（Database Description：データベース定義）におけるHDAMの定義を見ていこう。実務で設計する際、適当なパラメータを入れているようではプロ失格だ。コントロール・インターバルとランダム化モジュール（ハッシュ関数）のチューニングが命運を分ける。
以下は、典型的なHDAMのDBDソースコードだ。
———————————————————————-
- HDAMデータベース定義 (DBD) のサンプル
———————————————————————-
DBD NAME=CUSTDB,ACCESS=HDAM,RTM=(DFSDOH03,7,500)
- │ │ │ │ │ │
- │ │ │ │ │ └─ ルートごとの最大バイト数(Bytes)
- │ │ │ │ └─── ルート部分に割り当てるCI数(RAs)
- │ │ │ └─────────── ランダム化モジュール名
- │ │ └─────────────── アクセス方式 (HDAM)
- │ └─────────────────────── データベース名
DATASET DD1=CUSTDS1,DEV=3390,BLOCK=4096,
SIZE=(8000,2000)
- — ルートセグメント定義 —
SEGM NAME=ROOTSEG,PARENT=0,BYTES=250,PTR=T
FIELD NAME=(CUSTID,SEQ,U),BYTES=10,START=1
- — 従属セグメント (依存関係の定義) —
SEGM NAME=ORDSEG,PARENT=ROOTSEG,BYTES=150,PTR=TWIN
FIELD NAME=(ORDID,SEQ,U),BYTES=8,START=1
END
設計レビューのポイント
1. `RTM=(DFSDOH03, 7, 500)` の解釈
- DFSDOH03: 標準のランダム化モジュール（カスタマイズすることも可能だが、大抵は標準か特製の最適化モジュールを使う）。
- 7 (RAs: Root Addressable Area): ルートセグメントを直接格納するために最初に割り当てられるCIの数。ここに入りきらなかったデータは、オーフローエリア（Overflow Area）に溢れる。
- 500: 1つのCI（またはブロック）に格納するルートセグメントのバイト数の上限目安、あるいはオーバーフロー許容量のチューニングパラメータ。この数値を誤ると、オーバーフロー領域へのアクセス多発（チェインの肥大化）を招き、HDAMの最大の武器である「ダイレクトアクセス」が死ぬ。
—
3. 実務でハマる「アンチパターン」と堅牢な設計パターン
HDAMは強力だが、取り扱いを誤るとRDBMS以上に厄介なパフォーマンス劣化を引き起こす。現場でよく見る地雷と、それを踏まないための黄金律を伝授する。
アンチパターン：ハッシュ衝突とオーバーフローの放置
- 症状: キーの偏り（特定のプレフィックスを持つデータに集中するなど）により、特定のCIにハッシュ値が集中。結果としてオーバーフローエリアへのチェインが長くなり、ルートセグメントの検索であってもシーケンシャルなポインタ追跡が発生する。
- 対策:
1. 業務キーの特性を分析し、偏りのないランダム化モジュールを選定・実装する。
2. 定期的な再配置ユーティリティ（Image Copy / Reload）を実行し、ストレージの断片化とチェインを解消する。
堅牢な設計パターン：ポインタオプション（PTR）の最適化
HDAMにおいて、ルート配下の従属セグメント（子・孫）へのアクセスパスは、セグメント定義の `PTR=` パラメータで決まる。ここを適当にやると、子セグメントの検索で地獄を見る。
- 良い設計例：双方向ポインタと物理親ポインタの適切な組み合わせ
SEGM NAME=ORDSEG,PARENT=ROOTSEG,BYTES=150,PTR=(TWIN,PARENT)
- ルートから子、子から親、そして兄弟（TWIN）へのポインタを明確に定義し、不要な双方向ポインタ（`NOTWIN` や冗長なペア）を削ぎ落とすことで、ポインタメンテナンステストのオーバーヘッドとストレージ容量を最小化する。
—
4. チーフアーキテクトからのメッセージ
階層型DBMSのHDAMは、現代の分散システムにおける「ハッシュベースのパーティショニング」や「KVSのダイレクトストレージエンジン」の原風景だ。インデックスという便利な「言い訳」に逃げない者だけが、ハードウェアの限界性能を引き出すことができる。
スキーマを設計する際は、単に「データが入るか」を見るのではない。
「そのキーはどのハッシュ関数で、どの物理ブロックのどのバイトに落ちるのか」を脳内で完璧にシミュレーションしろ。
それができれば、君が設計したHDAMデータベースは、どんな高負荷なトランザクションの嵐が来ようとも、決して揺らぐことはない。
さあ、設計書を開き直せ。そのインデックス、本当に必要か？ ハッシュで一撃で抜けよ。
コメント