【入門編】 B-treeインデックス – PostgreSQL

こんにちは!データベースの世界へようこそ。

現場でバリバリとデータベースを触っていると、「SQLを書けばとりあえず動くけれど、なんだかデータが増えてきて重くなってきた…」なんて悩みに直面すること、ありますよね。そんなとき、必ずと言っていいほど救世主として現れるのが「インデックス」です。

今日は、PostgreSQLの標準装備であり、もっとも頼りになる相棒「B-tree(ビーツリー)インデックス」について、専門用語を抜きにしてお話ししてみようと思います。

—

本を探すとき、全部のページをめくりますか?

想像してみてください。あなたは今、図書館にいます。目的は「おいしいカレーの作り方」が載っている1ページを探すこと。

もし、図書館に何千冊もの本がバラバラに置いてあって、インデックス(索引)もなかったらどうでしょう?端から端まで、すべての本を1ページずつめくっていかなければなりませんよね。これ、めちゃくちゃ大変だし、時間もかかります。

でも、もし本の後ろに「カレー:120ページ」と書いてあったら?一瞬で見つかりますよね。

データベースにおける「インデックス」も、これと全く同じ仕組みなんです。

B-treeインデックスの「B」ってなに?

PostgreSQLで一番よく使われる「B-tree」というインデックス。名前を聞くと難しそうですが、要は「辞書」や「電話帳」のような整理整頓術だと考えてください。

「B」は「Balanced(バランスが取れた)」の頭文字です。なぜこの仕組みがそんなにすごいのか、少しだけ構造をのぞいてみましょう。

1. 枝分かれの魔法

B-treeは、上から下へ「枝分かれ」していくツリー構造をしています。
例えば「あ・か・さ・た・な」と大きく分かれていて、そこからさらに「あ」の中の「あい・あう・あえ…」と細分化されていくイメージです。

2. 常にバランスを保つ

ここが賢いところなのですが、B-treeはデータが増えたり減ったりしても、常に「どの道を通っても同じ深さで目的地にたどり着ける」ように、自分でバランスを整えてくれます。
だから、データが100件あっても100万件あっても、探しに行く手間(深さ)が極端に変わらないんです。これが、どんなにデータが膨らんでも安定した速さを誇る理由なんですね。

どんなときに力を発揮するの?

B-treeが特に得意なのは、こんな検索です。

  • 「名前が『佐藤』の人を教えて!」(等価比較)
  • 辞書の目次を使うように、一発で該当箇所にジャンプします。
  • 「20歳から30歳までの人を全員出して!」(範囲検索)
  • 辞書の「20歳」の場所を見つけたら、あとはそこから「30歳」のところまで隣のページをペラペラめくっていくだけ。この連続したデータを拾う速さが、B-treeの最大の強みです。

—

ちょっとしたアドバイス:インデックスは「貼りすぎ注意」!

ここまで聞くと「じゃあ、全部の列にインデックスを貼っちゃえば最強じゃない?」と思うかもしれません。でも、ここで一つだけ注意点を。

さっきの図書館の例えに戻りましょう。本棚にインデックスを貼るたびに、司書さんは「新しい本が来るたびに索引を書き直さないといけない」という仕事が増えますよね?

データベースも同じです。インデックスをたくさん作ると、データを見るのは速くなりますが、データの追加(INSERT)や更新(UPDATE)をするたびに、裏側でインデックスを修正する作業が発生して重くなってしまうんです。

「読み取りは速くなるけど、書き込みは少し重くなる」。このトレードオフを意識するのが、プロへの第一歩ですよ。

まとめ

  • B-treeは、図書館の索引のようなもの。
  • 枝分かれ構造のおかげで、データが膨大でも目的地にすぐたどり着ける。
  • 「特定のデータ」や「範囲指定」の検索には最強の味方。
  • でも、インデックスは「ここぞ!」という場所に貼るのが一番効率的。

どうでしょう、少しだけインデックスとの距離が縮まった気がしませんか?

まずは、今あなたが関わっているテーブルで「よく検索される列」はどこか、眺めてみることから始めてみてください。それが、データベースを「速くする」ための最初の一歩です。

それでは、また次回の記事でお会いしましょう!Happy Coding!

コメント

タイトルとURLをコピーしました