階層型DBMSの深淵：オンライン再編成という名の「外科手術」
君たちが普段何気なく使っているリレーショナルデータベースの裏側で、あるいはかつてメインフレームの心臓部を支えていた階層型DBMS（IMS等）の世界で、最も忌避される言葉が何か知っているか？
それは「Downtime（停止）」だ。
階層型DBMSは、物理的なポインタ（Child/Twin Pointer）によってレコード間を緊密に連結する。この「物理的結合」こそが爆速のルックアップを実現する源泉だが、同時に、構造変更や断片化解消のための「再編成（Reorganization）」を極めて困難な作業へと変貌させる。
今日は、データ構造を破壊することなく、稼働中のシステムにメスを入れる「オンライン再編成」の内部メカニズムについて、アーキテクトの視点から深掘りする。
—
1. 物理ポインタの呪縛と断片化のメカニズム
階層型DBMSにおいて、セグメントの挿入と削除を繰り返すと、データセット内には「穴」が生じる。OSのページングに近いが、より深刻なのは「ポインタの連鎖」による物理的局所性の崩壊だ。
- 物理的近接性の喪失: 直近のTwinセグメントが遠く離れたページに配置されることで、I/Oのレイテンシが指数関数的に増大する。
- ポインタのオーバヘッド: 断片化を放置すると、単なるレコード走査にさえ数倍のI/Oコストを要するようになる。
この断片化を解消するには、物理的な再配置が必要だが、再配置を行うにはポインタを一時的に切り離さねばならない。ここが「オンライン」の最大の壁だ。
2. オンライン再編成の核心：Shadow Copying と Pointer Swizzling
オンライン再編成を実現するためのアルゴリズムは、実はシンプルだが、実装には極限の精度が求められる。
A. シャドウ・マッピング（Shadow Copying）
再編成対象のセグメント領域を「アクティブ」と「シャドウ」の2つに分離する。
1. Read-Onlyフェーズ: アクティブ領域からデータを読み出し、シャドウ領域へ再配置（デフラグメント）を行う。
2. ログ・トラッキング: 処理中に発生した更新（UPDATE/INSERT/DELETE）を、専用のジャーナルバッファにキャプチャし続ける。
B. ポインタ・スウィズリング（Pointer Swizzling）
これが最も面白い部分だ。物理アドレスが変更される際、DBMSは以下のロジックで整合性を担保する。
/ 擬似コード: セグメント移動時のポインタ修正メカニズム /
void remap_segment(Segment old_addr, Segment new_addr) {
// 1. 既存の親セグメントからのポインタをロック
lock_parent_pointer(old_addr->parent);
// 2. 物理ポインタの付け替え
update_pointer(old_addr->parent, new_addr);
// 3. メモリバリアを挿入し、キャッシュの一貫性を強制
memory_barrier();
// 4. 旧領域のマークアップ（再利用可能フラグのセット）
mark_as_free(old_addr);
}
この処理中、当該セグメントへのアクセスは一旦キューイングされる。アーキテクトが設計すべきは、この「キューイング時間」をいかにマイクロ秒単位に抑えるかという一点に尽きる。
3. メモリ最適化とログの非同期統合
オンライン再編成中のパフォーマンス低下を防ぐ鍵は、「ログの統合戦略」にある。
再編成中の書き込みログをすべて同期的に適用しようとすると、再編成のプロセス自体がボトルネックになり、システム全体のトランザクションスループットを押し下げる。
- バッファリング: ログは一度メモリ上のリングバッファに書き出し、再編成プロセスがバッチ単位でシャドウ領域に適用する。
- 衝突回避: 再編成対象のページに対して排他制御（Latch）を行う際、読み込みリクエストを優先する「Read-Preference Latch」を実装する。これにより、書き込み側は「待たされる」が、エンドユーザーの検索性能は維持される。
4. 伝説のアーキテクトからの提言
「オンライン再編成」は、データベースという巨大な心臓を動かしながら、血管のバイパス手術を行うようなものだ。
もし君たちがこの機能を実装、あるいは運用する立場にあるなら、以下の3点を肝に銘じてほしい。
1. 断片化の許容限界を知れ: 全ての断片化を解消しようとするな。再編成自体がCPUとI/Oを食い潰す。統計的なコストベースで「再編成のROI」を算出するアルゴリズムを導入せよ。
2. ポインタの整合性を疑え: システム障害が発生した瞬間、シャドウ領域とアクティブ領域のポインタが乖離する。再起動時にどちらを正（Source of Truth）とするか、その復旧ロジックに全てを賭けろ。
3. ハードウェアを信じるな: メモリ上のポインタ修正は高速だが、メモリ故障やキャッシュの一貫性問題は容赦なく発生する。ECCメモリの監視と、堅牢なチェックサムの検証は必須だ。
階層型DBMSは古臭い遺物ではない。そのポインタによる直接アクセスと、オンラインでの整合性維持の知見は、現代のNoSQLや分散KVSの内部構造にも脈々と受け継がれている。
低レイヤの泥臭い処理を極めた者だけが、高レベルなシステム設計の主導権を握ることができる。次回の更新では、このポインタ整合性を維持するための「マルチバージョン・コンカレンシー・コントロール（MVCC）」との親和性について語るとしよう。
以上だ。コードを書き続けろ。
コメント