HSAMの呪縛と生存戦略：磁気テープの亡霊から学ぶデータ構造の原点
おい、そこの設計書を出してくれ。
……なんだこれは。「HSAMを用いたマスターデータのリアルタイム更新バッチ」？
ふざけるな。君は正気か？
磁気テープ時代に生まれた太古の遺物、HSAM（Hierarchical Sequential Access Method：階層順次アクセス方式）の制約を何だと思っているんだ。
「読み取り専用」「物理的な更新・削除不能」「完全なシーケンシャルアクセス」。現代のSSDやNVMeが当たり前の世界で、なぜ我々がこのプリミティブな構造に向き合わなければならないのか。
だが、コードレビューで「古いからダメ」と一蹴するのはチーフアーキテクトの名折れだ。
なぜHSAMという構造が生まれ、物理制約が如何にしてパフォーマンスを強制するのか。その本質を理解していなければ、いざ極限のバッチ処理やレガシーマイグレーション、あるいは特定の監査ログアーキテクチャに直面したとき、君たちは必ず足元をすくわれる。
今日は、階層型DBMSの原点にして最もスパルタンなアクセス方式であるHSAMについて、徹底的に叩き込んでやる。耳の穴をかっぽじいて聞け。
—
1. HSAMの本質：なぜ「更新できない」のか？
現代のリレーショナルデータベース（RDBMS）やNoSQLに慣れきった脳みそには、HSAMの物理レイアウトは暴力的に映るだろう。
HSAMは、その名の通り「階層構造を持つデータを、物理的に完全に直列化（シーケンシャル）して配置する」だけの方式だ。
[ 根セグメント: 顧客A ] -> [ 子セグメント: 注文1 ] -> [ 子セグメント: 明細1 ] -> [ 子セグメント: 明細2 ] -> [ 子セグメント: 注文2 ] …
ここにランダムアクセスの概念は微塵もない。
インデックス？ そんな優れものはない。ポインタのハッシュ？ 夢物語だ。あるのは「物理的な次のアドレス（Physical Sequential）」だけ。
なぜ更新・削除が物理的に不可能なのか？
磁気テープ（Magnetic Tape）を想像してほしい。
テープの途中にデータを「挿入」したり、長さを変えて「更新」したりできるか？ 無理だ。途中のデータを書き換えようとすれば、それ以降の物理的な物理ブロック（物理レコード）がすべて破壊されるか、シフトを余儀なくされる。
そのため、HSAMのスキーマ定義とデータ操作には以下の鉄の掟がある。
- 挿入（Insert）の禁止: 既存データの間に新しいセグメントを割り込ませることはできない。
- 更新（Update）のインプレース禁止: 可変長のデータをその場で上書きすることはできない（サイズが変われば後続が溢れる）。
- 削除（Delete）の物理的除外禁止: データを消して隙間を詰めるようなことはしない（テープ上でそんなことをすればO(N)の全書き直しが発生する）。
「じゃあ、どうやってデータをメンテするんだ？」という話になる。
答えは一つ。「全件書き換え（Re-creation）」だ。変更差分を適用した新しいテープ（またはファイル）を最初から最後まで丸ごと作り直す。これ以外に道はない。
—
2. 厳格なスキーマ定義：HSAMのデータ構造
HSAMのDLD（Data Definition Language / データベース記述言語）の概念を、現代的な視点で抽象化した疑似コードで見てみよう。
階層型モデルの本質である「親セグメント」と「子セグメント」の親子関係（Parent-Child）が、物理的な順序としてどう定義されるかがポイントだ。
— 【概念スキーマ定義】HSAMマスターデータ構造
— 物理的順序: COMPANY (会社) -> DEPARTMENT (部門) -> EMPLOYEE (従業員)
DATABASE COMPANY_HSAM_DB
ACCESS METHOD HSAM
BLOCK SIZE 4096; — 物理I/Oの基本単位（物理ブロック）
— 根セグメント (Root Segment)
SEGMENT NAME = COMPANY_SEG,
BYTES = 100;
FIELD NAME = COMP_ID, START = 1, LENGTH = 10, TYPE = CHAR;
FIELD NAME = COMP_NAME, START = 11, LENGTH = 90, TYPE = CHAR;
— 子セグメント (Child Segment: 会社に属する部門)
SEGMENT NAME = DEPT_SEG,
PARENT = COMPANY_SEG,
BYTES = 80;
FIELD NAME = DEPT_ID, START = 1, LENGTH = 5, TYPE = CHAR;
FIELD NAME = DEPT_NAME, START = 1, LENGTH = 75, TYPE = CHAR;
— 孫セグメント (Grandchild Segment: 部門に属する従業員)
SEGMENT NAME = EMP_SEG,
PARENT = DEPT_SEG,
BYTES = 150;
FIELD NAME = EMP_ID, START = 1, LENGTH = 10, TYPE = CHAR;
FIELD NAME = EMP_NAME, START = 11, LENGTH = 140, TYPE = CHAR;
チーフアーキテクトの視点：この構造の恐ろしさ
この定義を見て、何を感じるべきか？
ブロックサイズが `4096` バイト（4KB）に固定されている点に注目しろ。
HSAMでは、論理的なセグメントがこの物理ブロックの境界をまたぐことや、逆にブロック内にパディングが生じることに対する制御が極めてシビアだ。
もし `EMP_SEG` のレコードサイズを後から変更したくなったらどうなるか？
スキーマを変え、アプリケーションを改修し、過去の全データを新しいフォーマットへコンバートするプログラム（リライトバッチ）を走らせる必要がある。RDBの `ALTER TABLE ADD COLUMN` のような軽いノマド感覚でスキーマ変更など絶対にできない。スキーマ変更＝システムの全リフレッシュなのだ。
—
3. 実務における使用例：いつ、なぜHSAMを選ぶのか？
「おいおい、そんな不便なもの、現代のどこで使うんだ？」と思うだろう。
だが、プロフェッショナルであれば、あえてHSAM的アーキテクチャを選択すべきユースケースを知っている。
それは、「イミュータブル（不変）であり、完全なシーケンシャルスキャンしか行わず、かつデータ量がテラ/ペタバイト級に達する巨大な監査ログや、月次アーカイブデータ」だ。
具体例：金融機関の「完全性保証付きトランザクション・ジャーナル」
日々の全取引をミリ秒単位で記録し、後から絶対に改ざんできない、かつランダムアクセスを一切必要とせず「過去ログの古い順からの総なめ集計」しか行わないバッチ処理基盤。
ここにRDBを置くとどうなるか？
B-Treeインデックスのメンテコスト、トランザクションログ（WAL）の肥大化、断片化（Fragmentation）によるパフォーマンス劣化に悩まされる。
しかし、HSAMであれば、インデックス構造体そのものが存在しないため、ストレージの限界スループット（IOPSの天井ではなく帯域の限界）まで読み取り速度を極限まで引き上げることができる。
—
4. 堅牢な設計パターンとパフォーマンスの極意
もし君たちのプロジェクトで、HSAM的なデータ構造、あるいはその精神を汲んだシーケンシャル処理システムを設計・実装しなければならない場合、以下の設計パターンを遵守しなさい。
設計パターン1: 「世代管理とスワップ（Generation Management & Swap）」による更新
前述の通り、HSAMデータはインプレース更新できない。したがって、データの更新は常に「世代交代（Shadow Pagingのバッチ版）」で行う。
[ 既存データ: v1.hsam (Read-Only) ]
+
[ 変更差分ファイル: delta.dat ]
↓
【マージバッチ実行】
↓
[ 新規データ: v2.hsam (原子的にリネーム配置) ]
- 実装上の注意:
バッチ処理中は、必ず新しいファイル（`v2.hsam`）へ出力し、全処理が正常終了（Commit）した瞬間に、ファイルシステムの原子的な `rename` 操作でポインタを切り替えること。途中でコケたら古い世代（`v1.hsam`）に即座にフォールバックできるようにせよ。
設計パターン2: ブロックブロッキングとバッファリングの最適化
HSAMの読み取りは常に `GET NEXT` の連続だ。OSやランタイムのファイルI/Oキャッシュの振る舞いがパフォーマンスの生死を分ける。
- アンチパターン: 1セグメント（数バイト〜数百バイト）ごとにシステムコールを発行して読み取る。
- 正しい設計: アプリケーション層で大きめのメモリバッファ（例: 物理ブロックサイズの数百倍）を確保し、OSのページキャッシュと協調した先読み（Read-ahead）を最大限に活かす構造にコードをブロッキングしろ。
—
5. コードレビューで使えるチェックリスト
最後に、君たちが部下や後輩から設計書やコードが出てきたときに叩きつけるべき、レビューのチェックリストを授けよう。
1. 「このデータ、本当にランダムアクセス不要か？」
- もし途中のデータをピンポイントで検索・更新する要件が1ミリでも混じっていたら、即座にHSAM的アプローチを捨てさせろ。それはHIMAM（Hierarchical Indexed Sequential Access Method）か、素直なRDBを使うべきだ。
2. 「スキーマ変更時のマイグレーションプランはあるか？」
- フィールドの追加・削除が発生した際の影響範囲と、全件リライトバッチの所要時間が見積もられているか確認しろ。「後から何とかする」は死刑宣告に等しい。
3. 「I/Oのブロックサイズはストレージの物理特性に調律されているか？」
- OSやSSDのセクタサイズ、あるいはクラウドストレージのストライプサイズとブロックサイズがミスマッチを起こしていないか検証させろ。ここがズレると、シーケンシャルアクセスの優位性が完全に消え失せる。
—
チーフアーキテクトからの総括
HSAMは、データベースの歴史の教科書の最初の一ページに載っている「古い技術」ではない。
「ランダムアクセスを捨て、シーケンシャルに特化することで、物理限界のパフォーマンスを引き出す」というアーキテクチャの極限形だ。
基礎を極めた者だけが、複雑な抽象化レイヤーの裏側にある物理の理（ことわり）を見通すことができる。
次に「古いから変えましょう」と安易に言うエンジニアがいたら、こう問いかけろ。
「お前は、このデータ構造が持つ物理的な強靭さと速度の理由を、本当に説明できるのか？」とね。
さて、コーヒーブレイクは終わりだ。手を動かせ。
コメント