HISAMの真実：なぜ現代の我々が「階層型DBMSの極北」から学ぶべきなのか
おい、そこの設計書をちょっと止めろ。
「リレーショナルデータベース（RDB）を正規化しておけば、世の中のデータ構造は大抵なんとかなる」――そう思っていないか？
確かにOLTPの大部分において、B+TreeインデックスとJOINの組み合わせは正解だ。だが、お前が向き合っているそのシステム、「1対Nの深さが固定されており、親を引いた瞬間に子も孫も一気にごっそりメモリ上に展開したい超高スループットな読み込み系バッチ」や、「物理的なディスクシークを極限まで排除しなければ秒間10万件のトランザクションをさばけないミドルウェアの内部ストレージ」だったらどうする？
RDBのJOIN地獄でCPUキャッシュをドブに捨て続けるか？ それとも、ここで語るHISAM（Hierarchical Indexed Sequential Access Method）の思想に立ち返るか。
今回は、階層型DBMS（IMS等）の歴史的遺物と片付けるにはあまりにも美しく、そして現代のストレージエンジニアリングにも通じる「HISAMのスキーマ設計と物理配置の極意」を、コードレビューのつもりで叩き込んでやる。耳の穴をかっぽじいてよく聞け。
—
1. HISAMの本質：なぜ「インデックス付き順次」なのか
HISAMを語る上で絶対に外してはならない大原則がある。それは、「論理的な階層構造を、物理的なストレージ上でいかに連続配置するか」という執念だ。
リレーショナルデータベースは、行（Row）がディスク上のどこに散らばっていいても、RID（Row ID）やクラスタ化インデックスでかき集めてくる。しかしHISAMは違う。
- ルートセグメント（Root Segment）：全体の起点。これは従来のISAMと同様に、キー順のインデックスによってO(log N)で一発で引ける。
- 従属セグメント（Dependent Segments）：ルートの「子供」や「孫」にあたるデータ。ここがHISAMのキモだ。ルートの物理的直後に、まるでパンの串刺しのように連続して配置される。
[HISAMの物理レコードイメージ (OSのブロック内)]
+——————+——————+——————+——————+
| ルートセグメント | 子セグメント(1) | 子セグメント(2) | 孫セグメント(1) |
| (Key: 001) | (Type: A) | (Type: B) | (Type: B-sub) |
+——————+——————+——————+——————+
<---------------------- 1回の物理I/Oで一網打尽 ---------------------->
この構造がもたらすメリットが分かるか？
ルートを索引でヒットさせたら、ディスクヘッダ（あるいはSSDのフラッシュコントローラー）を微動だにさせず、ストリーミング読み込みだけで従属セグメントをごっそりメモリにロードできるのだ。ポインタ追跡（Pointer Chasing）によるキャッシュミスの嵐とはおさらばよ。
—
2. 脳内コンパイルせよ：HISAMスキーマ定義（DDL）の作法
現代のSQLに見慣れた脳には、HISAMのセグメント定義（ここでは概念的なDDLとして表現する）は異世界に見えるかもしれない。だが、ここには「物理レイアウトの制御権を完全にプログラマに委ねる」というDBMS全盛期の気概が宿っている。
以下のスキーロジックを見ろ。顧客（Customer）をルートとし、その下に注文（Order）、さらにその下に注文明細（OrderItem）がぶら下がるECの購買履歴モデルだ。
— 【HISAM 概念スキーロジック定義】
— 注意：これはRDBのCREATE TABLEではない。物理配置を強制する宣言だ。
DATABASE ECommerceHISAM
ACCESS METHOD HISAM
BLOCK SIZE 4096; — 物理I/Oの基本単位を4KBに固定
— 1. ルートセグメント：これにのみ高速なインデックスが張られる
SEGMENT DEFINITION Customer
PREFIX ISAM_INDEX
KEY (CustomerID CHAR(8)) ASCENDING
DATA LENGTH 128;
— 2. 従属セグメント（子）：Customerの物理的直後に配置される
SEGMENT DEFINITION Order
PARENT Customer
POINTER TWIN FORWARD — 同位セグメントへのポインタ（同一顧客の複数注文用）
DATA LENGTH 64;
— 3. 従属セグメント（孫）：Orderの物理的直後に配置される
SEGMENT DEFINITION OrderItem
PARENT Order
POINTER TWIN FORWARD
DATA LENGTH 32;
チーフアーキテクトからの厳しいツッコミ
お前らが設計レビューでやりがちなミスを指摘しておく。
「とりあえず将来のためにデータ長を大きくしておこう」だと？ HISAMでそれをやったら即死する。
HISAMのブロックサイズ（例：4KB）を超過した従属セグメント群はどうなるか知っているか？ オーバーフロー・ファイル（Overflow Chaining）への溢れ出しが発生する。
オーバーフローが発生した瞬間、物理的な連続配置というHISAM最大の武器が崩壊し、ポインタを辿るための無駄なディスクシーク（I/Oペナルティ）が発生する。データの最大サイズを予測し、ブロック内に綺麗に収まるよう `DATA LENGTH` をパッキングすること。これができないエンジニアにHISAMを触る資格はない。
—
3. 実務で踏み抜く「HISAMの罠」とパフォーマンス・チューニング
HISAMは「読み込み（特に親から子への一括スキャン）」においては神速を発揮する。しかし、実務の現場でこれを導入したプロジェクトがなぜ炎上するのか。その理由を教えよう。
罠1：動的な「挿入（INSERT）」と「削除（DELETE）」のコスト
HISAMは、その名の通り「インデックス付き順次アクセス手法」だ。
ルートセグメントの追加や、既存セグメントの間に割り込むような子セグメントの挿入が発生した場合、物理的に後続のデータをシフトさせる必要がある（あるいはオーバーフローブロックの管理コストが跳ね上がる）。
> 【教訓】
> 頻繁にINSERT/UPDATEが発生するマスタ系データや、サイズが予測不能に肥大化するログ系データにHISAMを適用した瞬間、そのシステムは自壊する。
> 「書き込みはバッチで一括、普段は超高速な参照専用（Read-Mostly）」というユースケース以外にHISAMを選定するな。
罠2：物理削除のメカニズムとスペースの断片化
リレーショナルDBなら `DELETE FROM` を叩けばスペースはいずれ再利用されるが、HISAMの物理連続領域において中途半端な削除を行うと、「削除マーカー（Tombstone）」が残り、再編成（Reorganization）バッチを定期的に回さないと空間効率が急速に悪化する。
運用設計の段階で、以下の運用コマンド（イメージ）をcronに組み込む覚悟はあるか？
HISAMデータベースの夜間デフラグ・再編成バッチ
物理連続性を強制的に復元する
db_reorg –database=ECommerceHISAM –overflow-threshold=15%
このメンテナンスをサボったシステムは、半年後には見事なパフォーマンス劣化を引き起こし、お前の机に障害チケットの山が積み上がるだろう。
—
4. まとめ：現代のエンジニアがHISAMから学ぶべき知見
ここまで読んで、「なんだ、古い技術の話か」と思ったなら、お前のエンジニアとしての視野はまだ狭い。
HISAMが教えてくれる本質は、「ストレージの物理特性（セクタ、ブロック、キャッシュライン、シーク時間）を無視した抽象化は、時にパフォーマンスの悪魔を生み出す」という真理だ。
現代のNoSQL（Key-ValueストアやWide-Column Store）、あるいは自前でストレージエンジンを書くとき、私たちは常にこの問題に直面する。データをどう並べ、どう一網打尽にフェッチするか。
- データのアクセスパターンを徹底的に分析し、
- 結合（JOIN）という高コストな演算を「物理的近接性（Locality）」によってあらかじめ排除し、
- 読み込みと書き込みのトレードオフを冷徹に見極める。
コードレビューで「なぜこのデータ構造なのか？」と問われたとき、お前は論理モデルだけでなく、物理的なI/Oの挙動まで含めてその理由を語れるか？
設計とは、妥協の歴史ではなく、物理法則に対する宣戦布告だ。HISAMの思想を血肉に変え、次のシステム設計に活かせ。期待しているぞ。
コメント