【実務・中級編】 HIDAM (Hierarchical Indexed Direct Access Method) – 階層型DBMS

現代のエンジニアへ告ぐ：あえて『HIDAM』の深淵を覗く理由

おい、そこの君。設計レビューの最中に「なぜこのルートセグメントへのアクセスパスにVSAM KSDSを選ぶのか、ポインタのオーバーヘッドとスプリット時のコストを説明してくれ」と言われて、冷汗をかいたことはないか？

「いや、今は2020年代だし、NoSQLかRDBのシャードで十分ですよ」と思ったなら、甘い。
現代のマイクロサービスや分散KVSが直面している「データローカリティ（局所性）の最適化」と「ポインタによる高速な実物理結合」の課題は、実は数十年前にメインフレームの階層型DBMS、すなわちIMS（Information Management System）のHIDAM（Hierarchical Indexed Direct Access Method）が、すでに極限の美しさで解決していた問題そのものなのだ。

今回は、階層型DBのアーキテクチャの極みに位置するHIDAMの構造、DDL（DBD）の設計作法、そして実務で踏み抜く地雷の回避策を、チーフアーキテクトの視点からロジカルかつシャープに伝授しよう。

—

1. HIDAMの本質：なぜHSAMやHISAMでは足りなかったのか？

まず、敵を知るために歴史の文脈を整理する。

HSAM (Hierarchical Sequential Access Method): テープ時代の遺物。順次アクセスしかできず、ランダムアクセスは全件スキャンという名の暴力。
HISAM (Hierarchical Indexed Sequential Access Method): ルートの索引はあるが、子セグメントが同一物理レコード（CI）内に入り切らなくなるとオーバーフローチェーンが発生し、更新が走るたびに性能が崩壊する。

そこで登場したのが HIDAM だ。
HIDAMは、「ルートセグメントへのアクセスは外部インデックス（VSAM KSDS または OSAM）に任せ、セグメント間の親子関係は物理的なポインタで直接結ぶ」という、いいとこ取りのアーキテクチャである。

[ 外部インデックス (VSAM KSDS) ]
│ (ルートキーによる索引)
▼
[ ルートセグメント (Root) ] ──(物理ポインタ)──> [ 子セグメント (Dependent) ]

この分離構造により、「ランダムアクセスの高速性」と「大量データの順次処理（シーケンシャル）」、そして「階層構造の深さによる柔軟性」が完全に両立する。これがHIDAMの本質だ。

—

2. 実務設計：DBD（Database Description）のコードレビュー

それでは、実際のスキーマ定義（IMSにおけるDBD：Database Description）を見ていこう。
コードレビューで私が「ここを修正しろ」と指摘するポイントを交えて解説する。

———————————————————————-

案件: 次世代EC基幹システム顧客・注文統合データベース
アーキテクトによる設計レビュー指摘 반영版 DBD

———————————————————————-
PRINT NOGEN
DBD NAME=CUSTDB,ACCESS=HIDAM アクセス方式にHIDAMを指定

— ルートセグメント定義 —

SEGM NAME=CUSTSEG, X
PARENT=0, X
BYTES=(100), X
PTR=TWIN 双方向ポインタ

ルートのユニークキー（顧客ID）

FIELD NAME=(CustId,SEQ,U), X
BYTES=10, X
START=1

— 従属セグメント（子）定義 —

SEGM NAME=ORDSEG, X
PARENT=CUSTSEG, X
BYTES=(150), X
PTR=(TWIN,LPARNT) 親ポインタ付与が鉄則

注文ID

FIELD NAME=(OrdId,SEQ,U), X
BYTES=12, X
START=1

END

チーフアーキテクトのコードレビューの眼所

1. `ACCESS=HIDAM` の選択根拠
もしルートへのランダムアクセスが全体の1%未満で、常にバッチ処理で全件舐める要件であれば、HSAMやHIDAMではなくHDAM（Hierarchical Direct Access Method：ハッシュアクセス）を選択すべきだ。HIDAMのインデックス管理コスト（VSAMの分裂と再編成）を正当化できるのは、「OLTP的なランダムアクセスと、階層順のバッチ処理が混在するワークロード」だけである。
2. `PTR=(TWIN,LPARNT)` の呪文
子セグメント (`ORDSEG`) において、親へのポインタ (`LPARNT`: Logical Parent) を省く設計をするジュニアがいる。今すぐやめろ。 親への逆引きができない構造は、後からデータ修復や双方向の走査が必要になったとき、システムを致命的なデッドロックとパフォーマンス低下の泥沼に引きずり込む。

—

3. インデックス構造（IHIDX）の深層：VSAM KSDSの呪縛

HIDAMの心臓部は、ルートセグメントを指し示すインデックスデータベース（通常はVSAM KSDS）である。このインデックス構造が、実務でパフォーマンスチューニングの標的になる。

CI（Control Interval）サイズとフリースペースの設計

VSAM KSDS側の設計で手を抜くと、データ更新時の「CIスプリット（制御区画分裂）」が多発し、I/O性能が劇的に劣化する。

ルール of チーフ:

高頻度でルート（顧客など）が追加されるテーブルのインデックス領域では、フリースペース（FREESPACE）を十分に確保しろ。
`FREESPACE(20, 10)` （CIの20%、CAの10%を空き領域とする）などの余裕を持たせないと、インデックスのB-Treeが頻繁に分裂し、ランダムアクセスのレイテンシが跳ね上がる。

—

4. パフォーマンス上の最大の罠：ポインタの劣化とデフラグメント

HIDAMを運用する上で、避けて通れない最大の敵が「物理ポインタのチェイン切れ・断片化（Fragment）」だ。

RDBであれば、インデックスとデータ実体が分離しており、行の削除や挿入はストレージエンジンがよしなにやってくれる。しかし、HIDAMのような物理ポインタ結合型DBMSでは、セグメントの削除（DELETE）と挿入（INSERT）が繰り返されると、データセット内に「ゴミ領域（Free Space）」が散在し、ポインタのチェインが物理的に遠く離れた位置を指すようになる。

これが何を意味するか？
論理的には「隣接する子セグメントを読む」だけの処理が、ストレージ層では「ディスクヘッドのシークを伴うランダムI/Oの嵐」に化けるのだ。

実務での対策：定期的な再編成（Reorganization）の自動化

近代的なRDBの「VACUUM」や「REINDEX」のレベルではない。HIDAMでは、以下のサイクルを厳格に回す必要がある。

1. SMF（System Management Facilities）やログの監視: フリースペースの枯渇率とI/O待ち時間をメトリクス化する。
2. イメージコピとDBアンロード/ロード（HD Reorganization Utility）:
定期的にデータベース全体をシーケンシャルに吐き出し（Unload）、物理的に綺麗な状態で再配置（Load）するバッチをCI/CDパイプラインならぬ「運用運用パイプライン」に組み込む。
これができない組織に、HIDAMを運用する資格はない。

—

5. 結びにかえて：現代のエンジニアがHIDAMから学ぶべき教訓

「なぜ、いまさら古いメインフレームの仕組みを語るのか？」と訝しんだ読者も、ここまで読めば気づいたはずだ。

現代のマイクロサービスアーキテクチャにおいて、データベースの正規化を過剰に進めた結果、数回のJOINやネットワーク越しのRPC（Remote Procedure Call）が発生し、レイテンシが爆発するアンチパターンが後を絶たない。これに対する現代の解が「CQRS」や「マテリアライズドビュー（非正規化）」であり、データ構造をアプリケーションのアクセスパターンに物理的に寄せることだ。

HIDAMがやっていることは、まさにこれのハードウェア制約が極めて厳しかった時代における極限の最適化である。

アクセスパターンから逆算したデータ構造の物理配置
インデックスによるランダムアクセスと、ポインタによる局所性の融合
構造の劣化を防ぐための、容赦ないメンテナンス（再編成）の自動化

これらは、時代がRDBに変わろうが、NoSQLやクラウドネイティブな分散DBに移ろうが、一流のエンジニアが持ち続けるべき普遍的なアーキテクチャの美学である。

コードレビューで「なぜこのデータ構造なのか？」と問われたとき、胸を張って答えられるだけの知見を、君の武器庫に常備しておいてほしい。さあ、設計書に戻るとしよう。