こんにちは!データベースの世界へようこそ。
普段、何気なくSQLを書いて「SELECT FROM…」なんて実行していますが、裏側でデータベースがどれほど必死に、そして賢く働いているか想像したことはありますか?
今日は、PostgreSQLという優秀な「司書さん」が、図書館の巨大な本棚から一瞬で目的のページを見つけ出すための秘密兵器――「インデックス(索引)」の仕組みについて、少しだけ掘り下げてみようと思います。
難しい専門用語はなるべく抜きにして、一緒にイメージを膨らませてみてくださいね。
—
図書館の「目録カード」を想像してみて
想像してみてください。あなたは今、数万冊の本がある巨大な図書館にいます。特定の情報を探したいとき、本棚を端から端まで歩き回っていたら日が暮れてしまいますよね。
そこで役立つのが、入り口にある「目録カード」です。
「あいうえお順」や「ジャンル別」に整理されたカードがあるおかげで、私たちは目的の本がどの棚の、どのあたりにあるかすぐに分かります。
PostgreSQLのインデックスも、これと全く同じことをやっているんです。そして、そのインデックスの整理整頓を担当しているのが「ページ」という小さな箱です。
—
ページは「情報の小箱」
PostgreSQLのインデックスは、データを「8KB(キロバイト)」という決まったサイズの小さな箱(これをページと呼びます)に小分けして詰め込んでいます。
このページには、大きく分けて3つの役割があります。
1. メタページ:図書館の「案内図」
一番最初にあるのが「メタページ」です。これは図書館の入り口にある「館内案内図」のようなもの。「このインデックスにはどんな情報が詰まっているのか?」「最新の情報はどこから始まるのか?」といった、インデックス全体の基本情報を管理しています。
2. 内部ページ:大きな「見出し」
次に登場するのが「内部ページ」。これは目次や、分厚い本の章の扉のような存在です。「AからMまではこっちのエリア」「NからZまではあっちのエリア」という風に、情報をざっくりと仕分けして、目的の場所まで案内してくれます。
3. リーフページ:実物が入った「引き出し」
最後が「リーフページ」。ここには、探しているデータの実際の場所(ポインタ)が書かれています。図書館で言えば、本の背表紙に貼られたラベルそのもの。ここまで辿り着けば、ようやく「あ、このデータはここにあるんだ!」と確信を持って取りに行けるわけです。
—
なぜこんなに複雑な形をしているの?
「そのままリストにすればいいじゃん」と思うかもしれません。でも、もしデータが1億件あったらどうでしょう? リストを全部眺めていたら、それこそ何時間もかかってしまいますよね。
この「案内図(メタ)→ 見出し(内部)→ 実物(リーフ)」という木のような構造(B-tree)のおかげで、データベースはたった数回のジャンプで、何億というデータの中からたった一つの正解にたどり着くことができるんです。
まるで、「〇〇階の、何番の棚の、左から3番目」と、迷いなく指さしてくれるようなものですね。
—
最後に:データベースの健気な努力
私たちが「検索速いなー」と当たり前に感じている裏側では、PostgreSQLがこうしたページ構造を常にきれいに整頓し、効率よくデータにアクセスできるよう、裏でせっせと汗をかいています。
次にデータベースを触るとき、「今、司書さんが一生懸命インデックスのページをめくって案内図を見てくれているんだな」なんて想像してみてください。そう思うと、SQLの実行結果を待つ数ミリ秒も、少しだけ愛おしく感じられませんか?
もし「もっと深いところまで知りたい!」という好奇心が湧いてきたら、またいつでも遊びに来てくださいね。次は、このページがどんな風に更新されていくのか、少し専門的なお話をしてみましょうか。
それでは、また次回の記事でお会いしましょう!
コメント