階層型DBMSにおける「二次索引」の深淵 —— ポインタの迷宮をいかに突破するか
階層型DBMS（IMS等）を「過去の遺物」と呼ぶ者は、その物理レイヤが持つ狂気的なまでの効率性に無知である。リレーショナルモデルが集合論の抽象化に逃げる一方で、我々はポインタという名の「物理的な近道」を駆使し、ハードウェアの限界性能を絞り出してきた。
今回は、階層型データベースにおいて最も禁断であり、かつ最も強力な機能である「二次索引（Secondary Indexing）」の内部機構について、アーキテクトの視点から解剖する。
—
1. 階層の呪縛と二次索引のパラドックス
階層型DBMSの基本は、親子関係（Parent-Child）を辿る物理的ポインタのトラバーサルである。ルートから子へ、子から孫へ。この構造は「ルートキーによるアクセス」には最適化されているが、末端のセグメントを「属性値」で検索しようとすれば、データベース全体をスキャン（全探索）するという悪夢が待っている。
二次索引は、この「階層の呪縛」を物理的に断ち切るためのバックドアだ。
内部メカニズムの真髄
二次索引は、独立した「索引データベース（Index DB）」として存在する。これは実データを持つDBとは別の物理ファイルであり、以下の構造で構成される。
1. 索引キー値: 検索対象となる属性値。
2. ポインタセグメント: 該当する実データ（ターゲットセグメント）を指す物理的アドレス（あるいはRBA: Relative Byte Address）。
ここで重要なのは、「索引から実データへのポインタは、階層構造を無視する」という点だ。本来、子セグメントは親を通さねば到達できないが、二次索引を使えば、データベースの物理的な構造をバイパスして、目的のセグメントへ直接ジャンプできる。
—
2. 索引データベースのメモリ最適化とI/O削減
二次索引は諸刃の剣である。索引を貼れば貼るほど、更新時のコスト（索引の再構築）は指数関数的に増大する。これをどう制御するかが、アーキテクトの腕の見せ所だ。
スパース索引（Sparse Indexing）の戦略
すべての実データに対して索引エントリを作る必要はない。特定の属性を持つセグメントのみを索引化する「スパース索引」を構築せよ。
/
- 概念的実装: 索引エントリの生成ロジック
- 階層構造における「キー」の重複を排除し、
- 検索頻度の高い属性のみを抽出するフィルタリング層
/
void generate_secondary_index(Segment target) {
if (target->is_frequently_queried()) {
// RBA（相対バイトアドレス）を直接索引へ書き込む
// 階層を無視した物理ポインタの生成
uint64_t rba = get_physical_address(target);
index_tree_insert(target->attribute_value, rba);
}
}
この際、索引ページをメモリ上に常駐させるためのバッファプール設計が鍵となる。階層型DBMSでは、実データのページと索引のページが物理的に離れていることが多い。I/Oのレイテンシを最小化するには、索引ページを先行読み込み（Read-ahead）し、キャッシュヒット率を95%以上に維持するチューニングが不可欠だ。
—
3. 伝説的アーキテクトからの忠告：ポインタの「腐敗」を防げ
二次索引の最大のリスクは、データの更新や削除に伴う「ポインタの不整合」である。リレーショナルデータベースなら整合性はトランザクションログで保証されるが、階層型においては、ポインタの再配置（Reorganization）が頻繁に行われると、索引が指し示す先（RBA）が無効化されるリスクがある。
解決策：物理アドレスの抽象化
実データに対して直接物理アドレスを保持するのではなく、論理的な「シンボリック・ポインタ」と「物理的ポインタ」のハイブリッド戦略を推奨する。
- 物理ポインタ: 高速だが、データ移動に弱い。
- シンボリック・ポインタ: 階層キー（Path）を保持する。データ移動には強いが、ルックアップコストがかかる。
大規模システムでは、「頻繁に動くデータにはシンボリックを、静的なマスターデータには物理ポインタを」という使い分けが、システムを延命させる唯一の道だ。
—
まとめ：効率という名の規律
二次索引は、階層型データベースに「自由」をもたらす。しかし、その自由は「物理構造を管理する」というエンジニアの規律の上に成り立っている。
リレーショナルなクエリプランナーにすべてを委ねる現代のDBエンジニアには見えない「物理レイヤの風景」が、ここにはある。ポインタを最適化し、I/Oを制御し、メモリの最後の一バイトまで使い切る。その先にこそ、真の高速化がある。
次に階層型DBMSと向き合うとき、君たちはただの「インデックス」ではなく、その背後にある物理アドレスとポインタの潮流を読み解いてほしい。それこそが、このアーキテクチャを扱う者に与えられた特権だ。
コメント