階層型DBMSの深層：RBAと直接アドレスポインタ管理の実践的アーキテクチャ
こんにちは。チーフアーキテクトの私だ。
本日は、現代のWeb系エンジニアから見れば「太古の遺物」のように映るかもしれないが、金融・社会インフラの基幹で今なお圧倒的なスループットを叩き出している階層型DBMS（IMS DBなど）の核心、そしてその生命線である「直接アドレスポインタ管理」と「RBA（Relative Byte Address）」について、実務の現場で使えるレベルの知見を赤裸々に語ろう。
コードレビューで「なぜこのポインタ構造にしたのか」「再編成（Reorg）時のコストをどう見積もっているのか」と後輩に問うたとき、表面的なリファレンスの引き写ししか返ってこないようでは、ミッションクリティカルなシステムは任せられない。
今日は、その甘さを完全に断ち切るためのセッションだ。心してついてきてほしい。
—
1. なぜ「RBA」なのか？ — 概念の再定義と物理アドレスの幻想
RBA（Relative Byte Address：相対バイトアドレス）とは何か。
リレーショナルデータベース（RDBMS）に慣れ親しんだ脳みそで考えると、「主キー（Primary Key）によるインデックス探索」や「UUIDによるランダムアクセス」を想像しがちだが、階層型DBMSの世界観は全く異なる。
RDBMSが「論理的な関係性（結合条件）」をランタイムのオプティマイザに解決させるのに対し、階層型DBMSは「物理的なポインタの鎖」によってデータ構造そのものをストレージ上にハードコードする。
RBAの正体
RBAは、データセット（OSのデータ・ファイルやVSAMのLVSなど）の先頭からの相対バイトオフセットである。
例えば、`0x00A4F000` というRBAは、ファイル先頭から数えてそのバイト位置にターゲットセグメントのプレフィックス（制御情報）が存在することを意味する。
ここで重要なのは、RBAは論理的なキーではないという点だ。
親セグメントから子セグメントへのポインタとして、論理キーではなくこの「物理的なRBA」を直接保持する（これを直接アドレスポインタと呼ぶ）。これにより、B-Treeインデックスを何段も潜るオーバーヘッドを完全に排除し、O(1)に近い極限のアクセスコストを実現している。
—
2. アーキテクチャの核心：直接アドレスポインタとポインタの崩壊
階層型DBMSのスキーマ定義（DDLに相当するもの、例えばIMSのDBD：Database Definition）において、セグメント間の接続方式はパフォーマンスを決定づける最重要ファクターだ。
典型的なポインタタイプ
1. 物理子ポインタ (Physical Child Pointer – PC): 親セグメントから最初の子セグメントのRBAを指す。
2. 物理兄弟ポインタ (Physical Twin Pointer – PT): 同階層の次のセグメント（兄弟）のRBAを指す。双方向（Forward/Backward）で持つことが多い。
3. 物理親ポインタ (Physical Parent Pointer – PP): 子から親への逆流を防ぐためのバックポインタ。
崩壊のメカニズム：なぜポインタは腐るのか？
ここで実務上の大きな課題が浮上する。
データが頻繁に更新（挿入・削除・更新による可変長データの肥大化）されると、OSのファイルシステムやデータベースの空間管理（OSAMやVSAMの制御ブロック）において、セグメントが元の場所に入りきらなくなる。結果として、溢れ領域（Overflow Area）への追い出しや、ページの分割が発生する。
この時、何が起きるか？
セグメントの物理位置が移動するということは、他のセグメントが持っている「あのセグメントのRBAはここだ」という直接アドレスポインタが、すべて「嘘（無効なアドレス）」に変わるという地獄絵図が展開されるのだ。
—
3. データベース再編成（Reorg）とポインタ解決メカニズム
「ポインタが腐るなら、システムはどうやって整合性を保っているのか？」
その答えが、定期的に実施されるデータベース再編成（Reorganization）であり、そこで行われるポインタの再構築メカニズムだ。
設計レビューで必ず確認すべき、再編成時のポインタ解決のフローをコード（概念的な擬似コード）で示そう。再編成ユーティリティが裏側で何をやっているのかを理解していれば、運用の怖さは半分になる。
class SegmentRecord:
def __init__(self, old_rba: int, data: bytes, ptrs: dict):
self.old_rba = old_rba
self.new_rba = None
self.data = data
self.ptrs = ptrs # {‘PC’: old_child_rba, ‘PT’: old_twin_rba}
def reorg_database(segment_stream):
“””
階層型DBMSの再編成（Reorg）におけるポインタ解決のコアロジック
1. 順次読み込み、新しい連続領域に再配置して「新RBA」を割り当てる。
2. 古いRBAと新しいRBAのマッピングテーブルを作成する。
3. 全てのポインタフィールドを新しいRBAに書き換える。
“””
print(“=== Phase 1: 圧縮と新規物理アドレスの割り当て ===”)
new_address_space_cursor = 0
address_mapping = {} # {old_rba: new_rba}
new_segments = []
for seg in segment_stream:
seg.new_rba = new_address_space_cursor
address_mapping[seg.old_rba] = seg.new_rba
# 次のセグメントの配置位置を計算（データ長 + プレフィックス制御情報）
new_address_space_cursor += len(seg.data) + len_prefix(seg.ptrs)
new_segments.append(seg)
print(f”Total Segments Processed: {len(new_segments)}”)
print(“=== Phase 2: 直接アドレスポインタのパッチ当て（解決） ===”)
for seg in new_segments:
# 子ポインタの付け替え
if ‘PC’ in seg.ptrs and seg.ptrs[‘PC’] in address_mapping:
old_pc = seg.ptrs[‘PC’]
seg.ptrs[‘PC’] = address_mapping[old_pc]
print(f”Patched PC Pointer: Old RBA {old_pc:#010x} -> New RBA {seg.ptrs[‘PC’]:#010x}”)
# 兄弟ポインタの付け替え
if ‘PT’ in seg.ptrs and seg.ptrs[‘PT’] in address_mapping:
old_pt = seg.ptrs[‘PT’]
seg.ptrs[‘PT’] = address_mapping[old_pt]
print(f”Patched PT Pointer: Old RBA {old_pt:#010x} -> New RBA {seg.ptrs[‘PT’]:#010x}”)
print(“=== Phase 3: 新しいデータセットへのフラッシュ ===”)
# flush_to_disk(new_segments)
return address_mapping
def len_prefix(ptrs):
# ポインタ構造体のサイズ（例：4バイト ポインタ数）
return len(ptrs) 4
チーフアーキテクトからの実践的注意点
この再編成処理、見ればわかる通りI/Oバウンドかつ排他制御（Exclusive Control）が必須の重い処理だ。
24時間365日止まらないシステムにおいて、このリオーガナイゼーションをいかに短時間で終わらせるか、あるいはオンライン再編成（HICON / IMS Online Reorgなど）のメカニズムをどう使いこなすかが、インフラエンジニアの腕の見せ所となる。
—
4. 堅牢な設計パターンとパフォーマンス・アンチパターン
最後に、実務の設計・コードレビューで私が見るべきポイントを簡潔に授けよう。
[アンチパターン] 頻繁に更新される子セグメントへの直接ポインタ依存
- 症状: 頻繁にINSERT/DELETEが繰り返される末端の子セグメントに対し、親から直接RBAでガチガチに固めたポインタ設計にしている。
- 弊害: オーバーフロー領域への溢れが多発し、ポインタチェーンが分断され、チェーニングを辿るためのディスクシーク（あるいはバッファプールヒット率の低下）が発生する。結果、RDBMSのインデックススキャンより遅い「最悪の階層型」が完成する。
- 対策: 変動が激しいセグメント群には、RBA直接参照ではなく、論理的なキー順（Sequenced）や、スワップ可能な間接アドレス（RBAの代わりにシンボリックキーやハッシュを使う設計）をハイブリッドに検討せよ。
[設計パターン] アクセスパターンの「階層逆転」を防ぐスキーマ定義
階層型DBMSの鉄則は、「親から子へアクセスする頻度が圧倒的に高い構造」でスキーマを定義することだ。
例えば、「顧客（Root）」→「注文（Child）」という階層であれば、注文から顧客を引くことは頻繁であっても、ポインタは物理親ポインタ（PP）を適切に配置することでO(1)で戻れるようにする。
しかし、「注文」から「顧客」を逆引きする要件がメインストリームであるならば、それは階層型DBの選定ミス、あるいはスキーマ設計の破綻を意味する。RDBMSへの移行、あるいは二次索引（Secondary Index）の定義によるポインタターゲットの変更を直ちに検討すべきだ。
—
5. 結びにかえて
直接アドレスポインタとRBAの概念は、突き詰めれば「コンピュータのメモリ管理（ポインタ演算）」そのものである。
抽象化のレイヤーを一枚剥ぎ取れば、データベースも突き詰めると「バイト列の塊とそれを指すメモリアドレス」に過ぎないという真理を、階層型DBMSは教えてくれる。
現代のクラウドネイティブな開発においても、K/Vストアや分散ストレージの内部実装（LSMトリーのポインタ、SSTableのオフセット管理など）を設計・チューニングする際、この「物理位置の直接管理と再編成のコスト」という思想は確実に生きている。
表面的なAPIの使い方に溺れず、物理層の挙動まで見通せる「本物のエンジニア」であれ。
次のレビューを楽しみにしている。
コメント