【実務・中級編】 HSAM (Hierarchical Sequential Access Method) – 階層型DBMS

HSAMの真実：なぜ今、私たちは「最も原始的な順次アクセス」から学ぶべきなのか

こんにちは。チーフアーキテクトの私だ。
今日のコードレビュー、あるいは基本設計レビューで、君たちはまた「とりあえずRDBMSの外部キーとインデックスを張っておけばいいか」という安易な設計を持ち込んできたな。

ちょっと待て。現代の分散ストレージやNoSQL、さらにはSSDの物理特性を極限まで引き出すアーキテクチャを語る上で、HSAM（Hierarchical Sequential Access Method）の概念を理解していないのは、コンパスを持たずに大海原へ漕ぎ出すようなものだ。

「おいおい、レガシーの骨董品か？」と思ったなら大間違いだ。HSAMは、階層型DBMSの祖でありながら、「極限まで無駄を削ぎ落としたI/Oとは何か」を我々に教えてくれる唯一無二の物理格納手法なのだから。

今日は、現代のエンジニアであっても知っておくべきHSAMの核心、そのデータ構造、そして実務における「設計の急所」をロジカルかつシャープに伝授しよう。

—

1. HSAMとは何か？ — 妥協なき純粋・順次アクセスの世界

HSAMは、Hierarchical Sequential Access Method（階層順次アクセス方式）の略称だ。文字通り、階層型データベースのツリー構造を、物理的に完全な順次ファイル（Sequential File）としてシーケンシャルに配置する、最もプリミティブにして最もハードウェアに優しい格納方式である。

RDBMSのように「ランダムアクセス用のB+樹木インデックス」などという贅沢な代物は一切存在しない。あるのは、物理的な磁気テープや、SSDの連続領域を舐めるように読み込むという「純粋なストリーム」だけだ。

物理レイアウトの思想

HSAMのデータセットは、親セグメント（Segment）の直下に子セグメント、その直下に孫セグメントが、完全に深さ優先探索（DFS）の順序でベタ書きされる。

この構造の何が美しいか？ ポインタのオーバーヘッドがほぼゼロ、そしてシーク待ち（Seek Time）が原理的に発生しないことだ。ストレージコントローラーのプリフェッチ機能がこれほど最高に効くアーキテクチャ他にはない。

—

2. DDLとスキーマ定義のリアル：HSAMはどう表現されるか

現代のSQLにおける `CREATE TABLE` のような洗練されたものではなく、階層型DBMS（IBMのIMSなどを想起してほしい）では、セグメントの親子関係と物理順序を厳密に定義するマクロやDDLが存在した。

概念的なHSAMのスキーマ定義を見てみよう。

==========================================================
HSAM スキーマ定義例: 企業・組織階層システム
==========================================================
根（Root）セグメント：企業情報

DBD NAME=CORPDB,ACCESS=HSAM

物理ブロックサイズとレコード長の設定

DATASET BLOCK=4096,RECSIZE=512

セグメント階層の定義

SEGM NAME=COMPANY,PARENT=0,BYTES=100
FIELD NAME=COMP_ID,SEQ,BYTES=10
FIELD NAME=COMP_NAME,BYTES=90

子セグメント：部門情報（COMPANYの直属）

SEGM NAME=DEPT,PARENT=COMPANY,BYTES=80
FIELD NAME=DEPT_ID,SEQ,BYTES=5
FIELD NAME=DEPT_NAME,BYTES=75

孫セグメント：社員情報（DEPTの直属）

SEGM NAME=EMP,PARENT=DEPT,BYTES=200
FIELD NAME=EMP_ID,SEQ,BYTES=8
FIELD NAME=EMP_NAME,BYTES=192
END

チーフアーキテクトからの指摘：

この定義における最大のポイントは、`ACCESS=HSAM` という指定と、ポインタ（Pointer）の定義が一切ない点だ。親IDを保持する外部キー（Foreign Key）すら存在しない。「物理的な並び順そのものがリレーションを意味する」。これがHSAMの真髄だ。

—

3. 実務設計における「致命的な制約」と堅牢なパターン

さて、ここからがエンジニアとしての腕の見せ所だ。HSAMは「最も単純」ゆえに、極めて暴力的なまでの制約を伴う。設計レビューでこれを誤れば、プロジェクトは確実に炎上する。

制約1: 逐次更新（In-Place Update）ができない

HSAMファイルは、基本的には「リードオンリー、または完全なバッチ書き込み専用」だ。
データを途中に挿入しようとすると、それ以降の全レコードを物理的に後ろへシフトさせなければならない。これは順次ファイルの特性上、実質的に不可能（＝全件書き直しになる）である。

制約2: ランダムアクセスの欠如

特定の社員ID（`EMP_ID`）を1件だけピンポイントで検索したいとする。HSAMでこれをやるには、ファイル先頭から目的のデータに到達するまで、全件を1件ずつ舐める（フルスキャンする）しかない。

堅牢な設計パターン：HSAMをどこで使うべきか？

「じゃあ使い道ないじゃん」と思った君、それは早計だ。以下のユースケースにおいて、HSAMは現代でも最強のパフォーマンスを発揮する。

1. 夜間バッチのマスターデータ・ロードファイル
前日のトランザクションを集計し、綺麗に階層順にソートされた巨大なマスターを生成・読込するバッチ処理。
2. 監査ログ・変更履歴のアーカイブ
「二度と更新されないが、時系列・階層構造を保ったまま高速に集計・ダンプしたい」データ群。

❌ やってはいけないアンチパターン

オンライントランザクション（OLTP）の基盤としてHSAMを採用すること。

（「社員IDで1件更新したい」という要件に対し、ファイルを先頭からデシリアライズし始めるコードをレビューで見つけたら、私はその場で差し戻す）

—

4. パフォーマンスの極意：ハードウェア特性をハックする

HSAMを使うプロジェクトで、システム全体のスループットを限界突破させるためのチューニング指針を授けよう。

物理ブロックサイズの最適化（`BLOCK`パラメータ）

OSのページサイズやSSDのセクタサイズ（あるいはストレージのストライプサイズ）の整数倍、あるいはキャッシュラインの境界に完全に一致させろ。HSAMは「シーケンシャルリードの塊」であるため、I/Oのバーストサイズをチューニングするだけでスループットが数倍変わる。

バッファプールの静的割り当て

HSAMのアクセスパターンは完全に予測可能（Predictable）である。OSやDBMSのバッファ管理に対し、先読み（Read-Ahead）を極限までアグレッシブに設定し、物理ディスクのスピンドルやSSDのチャネルを飽和させろ。

—

5. 総括：原始的な仕組みに宿る、システム設計の本質

HSAMという「階層型DBMSの最も原始的な順次アクセス手法」を紐解くことで、私たちは何を学ぶべきか。

それは、「リレーションやインデックスという抽象化の裏で、ハードウェア上でデータがどう並び、どう流れているか」という物理的リアリティだ。

RDBMSの複雑なクエリプランナーや、NoSQLの分散アルゴリズムに頼り切っていると、この「物理的な効率性」を見落としがちになる。データ構造をシンプルに保ち、アクセスの流れを一直線に整えることの美しさと圧倒的なパフォーマンス。

次の設計書を書くとき、あるいはデータベースの選定を行うとき、思い出してほしい。
「本当にその複雑なインデックスは必要か？私たちのデータは、実は美しい一本のストリーム（HSAM）として流せないか？」と。

優れたエンジニアとは、複雑な問題を複雑に解く者ではなく、最もシンプルな構造で極限の性能を引き出す者のことだ。
さて、今日の講義はここまでだ。各自、自分の設計書をもう一度見直しなさい。