【入門編】トランザクションID (XID) – PostgreSQL

こんにちは！データベースの世界へようこそ。
普段、PostgreSQLを何気なく使っていると、「トランザクションID（XID）」なんて言葉、あまり意識することはありませんよね。

でも実はこれ、PostgreSQLという巨大な組織を裏で支える「背番号」のような、めちゃくちゃ重要な仕組みなんです。今日は少しだけ、この「背番号の秘密」と、それが引き起こすかもしれない「ある問題」について、コーヒーでも飲みながら気軽にお話ししてみましょう。

—

想像してみてください。あなたは今、超人気のアイスクリーム屋さんで働いています。そこには毎日、たくさんのお客さんがやってきます。

お客さんたちはみんな、「あのアイスをください！」と注文しますが、もし「誰がいつ注文したか」を記録しなかったらどうなるでしょう？お客さん同士の注文が混ざって、大混乱ですよね。

そこで登場するのが「整理券」です。
PostgreSQLもこれと同じことをしています。データに変更を加えるとき、「これは〇番さんの注文ですよ！」と印をつけるための番号、それがトランザクションID（XID）です。

PostgreSQLは、この番号のおかげで、「どのデータが最新で、どれがまだ処理中なのか」を正確に把握できているんですね。

—

さて、ここからが少し面白い（そして怖い）話です。
この整理券ですが、実は「32ビット」という決まった枠しかありません。数字に直すと、だいたい40億枚くらい。

「40億枚あれば十分じゃない？」と思いましたか？
確かに大昔はそうだったかもしれません。でも、現代の忙しいシステムでは、あっという間に番号を使い切ってしまうんです。

もし、整理券が40億まで達してしまったらどうなるか。
なんと、番号は「0」に戻って、また最初からカウントし始めるんです！これを専門用語で「ラップアラウンド」と呼びます。

ここで問題発生です。
「あれ？今の番号は『1番』だけど、これってさっきの『1番』？それとも、ぐるっと回って一周したあとの新しい『1番』？」
これでは、データの歴史がめちゃくちゃになってしまいますよね。

—

この大ピンチを救うために、PostgreSQLには「凍結（Freeze）」という特別な仕組みがあります。

先ほどのアイス屋さんで例えると、古い整理券はもう「過去の遺物」として倉庫にしまって、「これはもう確定済みだから、古い番号と混同しないように『凍結』しておこう！」とラベルを貼る作業です。

これを専門用語で「VACUUM（バキューム）」と呼びます。
PostgreSQLは定期的にこのバキュームを行って、「古い番号はもう気にしなくていいですよ！」と整理整頓することで、番号が一周してしまっても混乱しないように守っているんです。

—

ここまでの話をまとめると、こういうことになります。

もし皆さんがデータベースの運用に関わるなら、「バキュームがちゃんと動いているかな？」「古すぎるデータが溜まって、番号の枯渇が近づいていないかな？」と、たまに気にかけてあげてください。

まるで、散らかった机を片付けるようなもの。
最初は難しそうに見えるアーキテクチャも、実は「混乱を防ぐための工夫」でできていると分かると、なんだか少し愛着が湧きませんか？

データベースの深淵はまだまだ奥が深いですが、まずは「XIDという背番号を守るための掃除」があるんだな、ということだけ覚えて帰ってくださいね！

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