諸君、よく集まってくれた。
今日は、現代の分散データベースやRDBMSの喧騒から一歩離れ、データ構造の「原点」にして「極北」、HSAM（Hierarchical Sequential Access Method）について講義する。
「テープ時代の遺物だろう？」と鼻で笑った者は、設計の本質が見えていない。HSAMを知ることは、データの物理配置がいかにパフォーマンスの決定打となるか、その冷酷な真理を学ぶことと同義だ。現代のビッグデータ処理やログ構造化ストレージ（LSM-Tree）に通じる思想が、ここには凝縮されている。
心して聴け。これが「階層型DBMSの極限」だ。
—
1. HSAMの本質：物理配置と論理構造の完全一致
HSAMの設計思想は極めてシンプルだ。「親子関係にあるデータを、物理的にも隣接して並べる」。ただそれだけだ。
階層型データベースにおいて、データはルート（Root）から始まり、その子、孫へと続く木構造を持つ。HSAMはこの木構造を「先行順巡回（Pre-order Traversal）」、つまり「上から下へ、左から右へ」という順序で、物理的なストレージ上に隙間なくパッキングする。
HSAMの物理レイアウト
例えば、「顧客（Root）ー 注文（Child）ー 明細（Grandchild）」という階層を考えてみよう。
[顧客A][注文A-1][明細A-1-1][明細A-1-2][注文A-2][顧客B][注文B-1]…
ポインタなどという軟弱なものは存在しない。次のデータは常に「物理的に次の場所」にある。これが何を意味するか分かるか？ ディスクのヘッド移動（シーク）を極限まで排除し、スループットを最大化するということだ。
—
2. スキーマ定義（DDL）：物理構造を支配する
HSAMを制御するには、DBD（Database Description）の定義がすべてだ。ここでミスをすれば、バッチ処理のパフォーマンスは崩壊する。
以下に、標準的なHSAMのDBD定義例を示す。
- HSAM データベース定義：顧客マスターアーカイブ
DBD NAME=CUSTARCH,ACCESS=HSAM
- データセット定義：物理的なブロックサイズが勝負を決める
DATASET DD1=CUSTDATA,DEVICE=TAPE,BLOCK=(16384),RECORD=2048
- セグメント定義：階層とバイト長を指定
SEGM NAME=CUSTOMER,PARENT=0,BYTES=512
FIELD NAME=(CUSTID,SEQ,U),BYTES=10,START=1
SEGM NAME=ORDER,PARENT=CUSTOMER,BYTES=256
FIELD NAME=(ORDID,SEQ,U),BYTES=12,START=1
SEGM NAME=ITEM,PARENT=ORDER,BYTES=128
FIELD NAME=(ITEMID,SEQ,U),BYTES=8,START=1
DBDGEN
FINISH
END
プロの視点：なぜ `BLOCK` サイズが重要か
HSAMにおいて、`BLOCK`（物理ブロックサイズ）と `RECORD`（論理レコード長）の設計は生命線だ。
HSAMは順次アクセスしかできない。OSレベルでのバッファリング効率を最大化するため、デバイスのトラック容量やテープの特性に合わせた最適なブロックサイズを算出せねばならない。中途半端なサイズ指定は、物理デバイスの帯域をドブに捨てる行為だ。
—
3. HSAMの「鉄則」と運用パターン
HSAMは「万能」ではない。「不器用な天才」だ。その特性を理解した設計パターンを叩き込め。
① 更新は「マージ」で行え
HSAMは物理的に詰めて書き込まれるため、途中のセグメントを「削除」したり「追加」したりすることは不可能だ。
更新が必要なら、「旧マスター ＋ 差分データ ＝ 新マスター」という、伝統的なマッチング・マージ（バッチ更新）を行う。
「オンラインでリアルタイムに1件更新したい」などという要求が来たら、即座に設計ミスだと突き返せ。それはHSAMの領分ではない。
② 検索は「フルスキャン」を前提とせよ
任意の顧客データをピンポイントで引く（Random Access）場合、HSAMは先頭から順に読み飛ばすしかない。
したがって、HSAMを採用するのは以下のケースに限る。
- アーカイブ・データ: 二度と更新せず、監査などで一括抽出するデータ。
- マスタ配信: 大規模なバッチ処理の入力ソースとして、全件を舐める必要がある場合。
—
4. パフォーマンス上の注意点：沈黙の罠
HSAMの設計で初心者が陥る罠、それが「セグメントの出現頻度の見誤り」だ。
HSAMは階層順に並ぶため、特定のルートの下に数万件の子セグメントがぶら下がっている場合、その後のルートセグメントに到達するまでに膨大なI/Oが発生する。
設計上のアドバイス:
1. 階層の深さを抑えよ: 深すぎる階層は、スキャン時のオーバーヘッドを増大させる。
2. 可変長セグメントを避ける: HSAMで可変長を扱うと、物理レコードの境界を跨ぐ際のパディング処理でCPUを食う。極力固定長で設計し、構造をシンプルに保つのが定石だ。
—
5. 結論：なぜ今、HSAMを学ぶのか
諸君、現代のクラウドネイティブなストレージエンジンを思い出してほしい。
たとえばGoogleのBigtableやApache HBase、あるいはParquetのような列指向フォーマット。これらは「データの近接性（Locality）」を利用して、大量のデータを高速に処理している。
HSAMが体現している「ポインタを排し、物理的な連続性のみを信頼する」という思想は、現代のメモリ帯域やNVMeのシーケンシャル性能を引き出すための究極の解でもあるのだ。
HSAMを理解することは、単なる古い技術の習得ではない。
「データ構造が物理デバイスをいかに駆動するか」という、エンジニアとして一生モノの嗅覚を養うことなのだ。
この設計思想、自身のプロジェクトのデータ構造設計にどう活かすか。
次に会うときまでに、自分なりの答えを出しておくように。
以上だ。
コメント