こんにちは！データベースの世界へようこそ。
普段、PostgreSQLを使っていると「なんだか最近、動きが重たい気がするなぁ」と感じることはありませんか？実はそれ、データベースが裏で「お片付け」に追われているせいかもしれません。
今日は、そんなデータベースの知られざる努力……というか、賢いショートカット術である「HOT更新（Heap Only Tuple）」についてお話しします。
専門用語を並べるのは一旦お休みして、ちょっとした「図書館」の例えで考えてみましょう。
—
本の場所を書き換える「大変な作業」
想像してみてください。あなたは巨大な図書館の管理人です。
利用者が「この本の内容をちょっと書き換えたい」と言ってきたとき、あなたはどうしますか？
1. 本の内容を書き換える（ページを修正）。
2. 「この本は〇〇棚の何番目にある」という索引カードを、新しい場所に書き直す。
実は、PostgreSQLも普通はこの「2番」をやっています。でも、もし本の場所（ページ番号）が変わっていないのに、わざわざ索引カードを書き換えるのって、すごく無駄だと思いませんか？
「中身は変わったけど、置いている場所は同じなんだから、索引カードはそのままでいいじゃん！」
これがHOT更新の考え方なんです。
なぜ「HOT」が大切なの？
もし、中身を直すたびに索引カード（インデックス）まで書き直していたら、どうなるでしょう。
- 手間が増える： 修正のたびに棚まで走って、カードを書き換えて……と、作業量が増えますよね。
- カードが溢れる： 「修正前」のカードと「修正後」のカードがどんどん増えて、索引の箱がパンパンになってしまいます。
これがデータベースの世界では「インデックスの肥大化」という現象です。インデックスが巨大になると、目的の本を探すのに時間がかかってしまい、結果として「データベースが遅い！」という悲劇が生まれるわけです。
HOT更新を成功させる「たった一つのルール」
この魔法のようなHOT更新をデータベースに行わせるには、実は私たち人間が気をつけてあげないといけないルールが一つだけあります。
「検索に使っている情報（インデックスの列）は、できるだけ書き換えない」
これだけです。
例えば、「会員番号」や「登録日時」のように、一度決めたら変わらないものを検索条件にするのはOK。でも、頻繁に変わる「現在のポイント数」や「最終ログイン時刻」といった項目をインデックスに含めてしまうと、PostgreSQLは「あ、これインデックスも書き直さなきゃ！」と判断して、HOT更新を諦めてしまうんです。
ちょっとしたコツ
- 更新頻度が高い項目には、インデックスを貼るのを慎重にする。
- テーブルの設定で「Fillfactor（詰め込み率）」を少しだけ余裕持たせてあげる。（これは「棚に少し隙間を作っておく」ようなイメージです。これがあると、HOT更新が成功しやすくなりますよ！）
—
まとめ：データベースと仲良くするために
HOT更新は、データベースが自ら「効率よく動こう！」としてくれる素晴らしい機能です。でも、私たちが「あちこちの項目にインデックスを貼りまくる」ような無茶な設計をしてしまうと、その能力を発揮できなくなってしまいます。
「この項目はよく変わるかな？」「ここは検索で一番使う場所かな？」
そんなふうに、データベースの気持ち（？）になって設計を考えてみると、あなたの作ったシステムはきっと、驚くほど軽やかに動いてくれるはずです。
データベースのチューニングって、なんだか料理の隠し味や、整理整頓のコツと似ていると思いませんか？ぜひ皆さんの開発現場でも、この「HOT更新」を意識したモデリングに挑戦してみてくださいね！
それでは、また次回の記事でお会いしましょう！
コメント