Hashing vs Indexing: HISAMという「執念」の物理設計
諸君、今さら階層型データベースの話かと思ったか？ もし君がリレーショナルモデルの抽象化に甘んじ、ポインタが物理メモリ上でどう蠢いているかを想像できないのであれば、ここでブラウザを閉じることを勧める。
だが、もし君が「なぜ現代のDBエンジンがKVSやグラフDBでさえ、結局はHISAMの亡霊を追いかけているのか」という問いに興味があるなら、この先の話は君のアーキテクトとしての視座を確実に変えるはずだ。
今日は、IMS（Information Management System）の心臓部であり、現在もなお「高速アクセス」の哲学を体現するHISAM（Hierarchical Indexed Sequential Access Method）の深淵に潜る。
—
1. HISAMの真髄：順次アクセスへの回帰
HISAMの本質を理解するには、RDBMSのインデックスが「ポインタの迷宮」であるのに対し、HISAMが「物理的連続性」をいかに神聖視しているかを理解する必要がある。
HISAMは、ルートセグメントをKSDS（Key Sequenced Data Set：VSAMの索引付き順次データセット）に置き、その配下の従属セグメントを同一の物理ブロック内に逐次詰め込む。
[ルートセグメント(KSDS)] -> [従属セグメント(ESDS/または同一ブロック内)]
なぜこれが重要なのか？ 現代のNVMe SSDであれ、いにしえの磁気ディスクであれ、「ランダムアクセスは死、シーケンシャルアクセスは生」という物理原則は不変だからだ。HISAMは、関連するデータを物理的に隣接させることで、OSのページフォルトと物理的なヘッドシークを最小化することだけに命を懸けている。
2. 物理格納構造の限界と「オーバーフロー」の悪夢
HISAMのアーキテクチャで最も興味深いのは、物理的連続性を維持しようとする「執念」が、逆にシステムを追い詰める瞬間だ。
もし、あるルートセグメント配下の従属セグメントが肥大化し、あらかじめ確保したブロック内に収まらなくなった場合どうなるか？ そこで登場するのがオーバーフロー・データセット（OSDS）だ。
/ 概念的なオーバーフロー制御フロー /
if (segment_size > remaining_block_space) {
// 物理的連続性を捨て、オーバーフローポインタをセット
pointer = allocate_overflow_page();
write_to_overflow(pointer, data);
update_overflow_pointer_in_primary(pointer);
}
この「オーバーフロー」が発生した瞬間、HISAMのパフォーマンスは崩壊する。論理的には階層構造だが、物理的には不連続なポインタの追跡が必要となり、CPUのキャッシュミス率が跳ね上がるからだ。
熟練のアーキテクトであれば、設計段階で「ルート配下の平均的な従属セグメントの総サイズ」を計算し、LRECL（論理レコード長）とブロックサイズをいかにチューニングしてオーバーフローをゼロに近づけるかに心血を注ぐはずだ。それができない者は、単なる設定屋である。
3. メモリ最適化：バッファ・プーリングの極意
HISAMにおけるバッファ管理は、RDBMSのLRUアルゴリズムとは一線を画す。階層型DBMSにおいて重要なのは「いかにセグメント同士の親子関係を物理的に保持したままメモリに載せるか」だ。
特に意識すべきは「サブプール（Subpool）」の分離である。
- ルートセグメント用プール: インデックスとルートのみを保持し、常にメモリに常駐させる。
- 従属セグメント用プール: リーフレベルのセグメントを保持し、シーケンシャルなスキャンを高速化する。
これを分離せず、闇雲に単一のバッファプールで管理すれば、ルートセグメントが従属セグメントのゴミデータによって追い出される（バッファ・チェイシング）。結果として、ルートの探索という最も重要なパスでさえI/Oが発生するという、本末転倒なシステムが出来上がる。
4. 伝説のアーキテクトからの提言
HISAMは古い技術ではない。それは「物理配置の最適化」というデータベースエンジニアリングの最も原初的かつ強力な武器だ。
現代の分散データベースやNoSQLエンジンにおいても、シャードキーの設計やデータ配置戦略（Data Affinity）の根底には、必ずHISAMの哲学が流れている。
- データは近くに置け。
- 物理レイアウトを制御できないアーキテクトに、パフォーマンスを語る資格はない。
- オーバーフロー（断片化）を恐れるな、制御せよ。
もし君がシステムのパフォーマンスに頭を悩ませているなら、抽象化レイヤーを剥ぎ取り、そのデータがディスク上でどう並んでいるかを想像してみろ。HISAMのアーキテクチャこそが、その視点を持つための最高の教材になるはずだ。
データベースを「ブラックボックス」として扱うな。
その中身を定義し、制御しているのは、他ならぬ君たちエンジニアなのだから。
コメント