【テクニカル・上級編】インテントロック – 階層型DBMS

インテントロックの深淵：階層型DBMSにおける「整合性のコスト」を極限まで削ぎ落とす

現代のRDBMS全盛の時代において、階層型DBMS（IMS等）を語ることは、いわば「骨董品」を愛でる趣味のように思われるかもしれない。しかし、それは大きな誤解だ。階層型DBMSが実装しているロック制御、特に「インテントロック（Intention Lock）」の概念は、並列処理におけるオーバーヘッド削減の歴史そのものだ。

我々アーキテクトが直面するのは、常に「正確性」と「並列度」という矛盾する二項対立である。この二つをいかに高次元で両立させるか。インテントロックの内部メカニズムを紐解くことで、現代の分散システムにも通じる「ロックの哲学」を再確認しよう。

—

1. インテントロックの存在意義：ツリーを全走査する愚を避ける

階層型DBMSのデータ構造は、論理的に親から子へのポインタを辿るツリー構造だ。ここで、あるリーフ（下位セグメント）を排他制御（Xロック）したいとする。

もしインテントロックが存在しなければ、システムはどう動くか。下位の全ノードに対してロックをかけようとすれば、トラバースのコストは線形に増大する。逆に、上位のルートノードにXロックをかければ、システム全体の並列性が死ぬ。

ここで導入されるのがインテントロック（IS, IX, SIX）だ。

IS (Intention Shared): 「この下の階層のどこかでSロックを要求するぞ」という意思表示。
IX (Intention Exclusive): 「この下の階層のどこかでXロックを要求するぞ」という意思表示。

この仕組みの肝は、「上位階層のロック状態を見るだけで、下位階層の干渉可能性を即座に判断できる」ことにある。探索コストをツリーの深さ（$O(log N)$）に抑えつつ、競合を最小化する。この設計思想は、現代のマルチレベル・ロック・マネージャーの始祖である。

—

2. 内部メカニズム：ロックテーブルとメモリ最適化の極致

伝説的なエンジン設計者であれば、インテントロックの実装において「ロックテーブル」のメモリ配置に執着するはずだ。

ロック・リクエスト・ブロック（LRB）の構造

メモリを節約し、キャッシュミスを防ぐために、LRBは以下のようなビットマップ表現に極限まで圧縮される。

概念的なロック制御構造体
実際には、高速なビット演算のためにアラインメントとパディングを極限まで排除する

/
typedef struct {
uint32_t segment_id; // セグメント識別子
uint8_t lock_mode; // IS=1, IX=2, S=3, SIX=4, X=5
uint8_t wait_count; // 待機中のトランザクション数
struct LRB parent; // 親階層のロックへのポインタ（高速探索用）
/ 下位階層へのリンクはハッシュチェーンで管理 /
} LockControlBlock;

インテントロックの真のコストは、実は「上位への伝播」にある。リーフのロックを獲得する際、ルートから当該ノードに至るまでのすべての祖先ノードのステータスを更新しなければならない。

これを実装する際、我々が避けるべきは「親の親まで辿る再帰処理」だ。
ポインタによるリンクをハードコーディングし、L1/L2キャッシュに乗るようにロック管理テーブルをアロケートする。もしロック獲得時にキャッシュミスが多発するようであれば、そのデータベースエンジンのスケーラビリティは死んだも同然だ。

—

3. 階層型DBMS特有の「限界突破」手法

現代のエンジニアがインテントロックを語る時、忘れがちなのが「階層のパス」の固定化だ。

階層型DBMSにおいては、アクセスパスが物理的に決まっているため、ロックの範囲が限定しやすい。私はかつて、ロック獲得のオーバーヘッドを削減するために「ロック・エイリアス」という手法を導入したことがある。

ロック・エイリアスの概念

頻繁にアクセスされるサブツリーのルートに対して、あらかじめ擬似的なロックをキャッシュしておく。
1. 通常: 下位の更新前に毎回ルートからインテントロックを要求。
2. 最適化: 頻出サブツリーについては、ルート階層のインテント情報をローカルメモリにマッピング。

これにより、ツリー構造を物理的に辿る必要性を排除した。この手法は、現代のKey-Valueストアにおける「キー空間のパーティショニングによるロックの局所化」と極めて近いアプローチだ。

—

結論：歴史は繰り返す、最適化の形を変えて

インテントロックは、単なる「古いDBMSの機能」ではない。それは「データ構造における情報の局所性と、並列性の競合をどう解決するか」という問いに対する、人類の最初の回答の一つだ。

今のクラウドネイティブなデータベースでも、マイクロサービス間の分散トランザクションにおいても、この「上位で意図を表明し、下位で実行する」というパターンは形を変えて生き続けている。

もし、あなたが今、パフォーマンスボトルネックに悩んでいるなら、一度立ち止まってシステム内の「意図の伝播」を見てほしい。不要なロック伝播を削ぎ落とし、最短距離でノードを特定できる構造を作れた時、あなたのデータベースは真に伝説の一歩を踏み出すことになるだろう。

技術に近道はない。あるのは、アーキテクチャへの深い洞察と、メモリの1バイトに至るまでの執念だけだ。