【入門編】論理レコード長と物理ブロック長の最適化 – 階層型DBMS

こんにちは！データベースの世界へようこそ。
今日は、少しレトロでありながら、現在でも超高速なデータ処理の現場でその思想が息づいている「階層型DBMS（データベース管理システム）」について、お話ししていきたいと思います。

「階層型」と聞くと、なんだか難しそうに聞こえるかもしれませんが、安心してください。
今回は、データベースのパフォーマンスを左右する超重要ポイント「論理レコード長と物理ブロック長の最適化」というテーマを、日常の身近な例えを交えながら、一緒に分かりやすく紐解いていきましょう。

ここをクリアすれば、階層型DBMSのデータ構造の本質はバッチリマスターできますよ！

—

1. そもそも「階層型DBMS」ってどんなもの？

今の主流であるリレーショナルデータベース（RDB）は、表（テーブル）同士を結合してデータを取得しますよね。
一方、階層型DBMSは、データを「家族の樹形図（ツリー構造）」のように管理します。

例えば、学校のクラスをイメージしてください。

親（ルート）：クラス（例：1年A組）
子（セグメント）：生徒（例：山田くん、佐藤さん）
孫（サブセグメント）：生徒の提出物（例：国語のレポート、数学のドリル）

親を辿れば必ず子が見つかる。この「一本道の家族関係」が、階層型DBMSの最大の特徴です。迷子になる心配が少ない分、決まった経路の検索スピードがもの凄く速いというメリットがあります。

—

2. 「論理レコード長」と「物理ブロック長」を、お弁当箱で例えてみよう

さて、本日のメインテーマである「論理レコード長」と「物理ブロック長」の話に入りましょう。
専門用語を排して、身近なもので例えてみますね。

論理レコード ＝ 「生徒一人が食べるお弁当の中身（おかずのセット）」
物理ブロック ＝ 「学校の給食を運ぶコンテナボックスの大きさ」

データベースは、ディスク（ハードディスクなど）という巨大な倉庫から、データをメモリ（机の上）に引っ張り出して作業をします。この時、ディスクからデータを読み書きする「ひとかたまりの単位」が物理ブロックです。

最悪のシナリオ：お弁当箱とコンテナのサイズが合っていない

もし、「お弁当（論理レコード）」のサイズが、「コンテナ（物理ブロック）」のサイズに対して中途半端だったらどうなるでしょうか？

1. お弁当がコンテナに入りきらない場合（レコード長＞ブロック長）

山田くんのおかず（データ）が大きすぎて、1つのコンテナに収まりません。結果として、コンテナを2つに跨いで詰め込むことになります。「あれ？山田くんの唐揚げの半分が、隣のコンテナに行っちゃったぞ？」という状態です。
これをデータベースの世界では「スパン・レコード（跨りレコード）」と呼びます。これを読み込むには、ディスクを2回見に行かなければならず、I/O（読み書きの回数）が無駄に増えてしまいます。

2. コンテナに対してお弁当が小さすぎる場合（ブロックの無駄遣い）

大きなコンテナ（例えば4KB）を用意したのに、中身がスカスカ（数十バイトのお弁当）だったらどうでしょう？空いたスペースがもったいないですよね。ディスクの容量を無駄に消費するだけでなく、1回あたりの読み込みで効率よくデータを持ち帰れません。

—

3. 最適化の極意：サイズをピタリと合わせる！

私たちが目指すべきエンジニアリングのゴールはシンプルです。
「コンテナ（物理ブロック）の中に、綺麗にお弁当（論理レコード）が並ぶように設計すること」です。

例えば、物理ブロックのサイズが「4,096バイト（4KB）」だと決まっているなら、
子や孫のセグメントが集まった「1つの論理レコード」の合計サイズが、ちょうど4KBの倍数、あるいは4KBの中に綺麗に収まるようにスキーマ（設計図）を定義します。

イメージとしてはこんな感じです：

このようにサイズを綺麗に整えてあげると、ディスクを「1回ガチャンと開けただけ」で、必要な家族のデータ（親から子までのツリー丸ごと）を一度にメモリへ持ち帰ることができます。これが、I/O効率の最大化です。余計なディスクの回転を発生させない、シブい職人技がここにあります。

—

DDL（スキーマ定義）のイメージを見てみよう

階層型DBMSの代表格であるIBMのIMSなどをイメージした、仮想的なDDL（データ定義言語）の雰囲気を少しだけ覗いてみましょう。

— 物理的なデータベースおよびブロックサイズの定義
DATABASE SchoolDB (BLOCK_SIZE = 4096);

— ルートセグメント（親：クラス）の定義
SEGMENT ClassRecord (MAX_LENGTH = 512) {
ClassID CHAR(5);
ClassName CHAR(30);
}

— 子セグメント（生徒）の定義：親の中に綺麗に収まるサイズを意識する
SEGMENT StudentRecord (MAX_LENGTH = 1024, PARENT = ClassRecord) {
StudentID CHAR(8);
StudentName CHAR(50);
}

※実際の構文はシステムによって異なりますが、このように「ブロックサイズ」と「レコードの最大長（MAX_LENGTH）」を意識して設計するのが鉄則です。

—

まとめ

いかがでしたでしょうか？

論理レコード長 ＝アプリケーションが扱うデータのまとまり（お弁当）
物理ブロック長 ＝ディスクが読み書きする単位（コンテナ）
最適化の本質 ＝この2つのサイズを調和させ、ディスクへのアクセスのムダ（I/Oロス）を極限まで削ぎ落とすこと

階層型DBMSは古い技術だと思われがちですが、「ハードウェアの物理特性を限界まで引き出す」というデータベース設計の最も美しい原点がここに詰まっています。

この「コンテナとお弁当」の感覚さえ掴んでおけば、どんなに巨大なシステムを前にしても、迷うことなく最適なデータ構造を設計できるようになりますよ。
データベースの奥深い世界、一緒に楽しんでいきましょう！