こんにちは！データベースの世界へようこそ。
普段、何気なく使っているデータベース。でも、その裏側で一体どんな「魔法」が起きているのか、気になったことはありませんか？
今回は、PostgreSQLというデータベースの心臓部で働く、「XID（トランザクションID）」という、ちょっと地味だけど、実はものすごく重要なヒーローについてお話ししようと思います。
専門用語だらけの分厚いマニュアルを読む前に、まずは一緒に「とある図書館」を想像してみてください。
—
データベースは「巨大な図書館」だと思ってみよう
データベースには、世界中のたくさんの人が同時にアクセスしてきます。みんながバラバラに「この本（データ）を書き換えたい！」「いや、こっちの本を読み取りたい！」とリクエストを送るわけです。
さて、ここで問題です。もし、一人の人が本を書き換えている最中に、別の人がそのページを読もうとしたらどうなるでしょう？ 内容がぐちゃぐちゃになってしまいますよね。
そこでPostgreSQLは、「誰が、いつ、どの作業をしているのか」を厳密に管理することにしました。その管理番号こそが、今回のお題である「XID（トランザクションID）」なんです。
「整理券」がなければ、作業は始まらない
PostgreSQLに「何かを変えたい（書き込みや更新をしたい）」とお願いすると、データベースはまず、あなたに「整理券（XID）」を渡します。
- 「はい、あなたは100番さんですね」
- 「じゃあ、次は101番さん、どうぞ」
こんなふうに、作業をする人には必ず番号が割り振られます。これがトランザクションIDです。32ビットという数字の枠組みで、順番に番号が発行されていきます。
なぜこの番号が重要なのか？
この整理券がすごいのは、「時間の前後関係」を教えてくれるところです。
例えば、あるデータに「100番の人が書いたよ」というハンコが押されているとします。すると、あとから来た101番の人はこう判断するんです。
- 「あ、このデータは100番さんが書いたものだ。私は101番だから、100番の作業はもう終わっているはず。なら、この内容は見ていいんだな」
逆に、まだ作業中の人（整理券を持っているけどハンコを押す前）のデータは、他の人には見えないように隠されます。これによって、「作業中の汚い状態を見せない」という、MVCC（多版同時実行制御）という高度なテクニックを実現しているんです。
「ぐるっと一周」の落とし穴（おまけの話）
最後に、ちょっとだけマニアックな話をしますね。
この整理券の番号、実は「32ビット」という限りある枠（約42億個！）の中でやりくりしています。ずっと使い続けると、いつか番号が足りなくなって「0」に戻ってしまいます。
これを「XIDの周回問題」と呼ぶのですが、PostgreSQLはこの番号が一周する前に、賢い仕組みを使って「古い番号」を整理整頓（バキュームといいます）して、番号を再利用できるようにしています。
まるで、図書館の古い整理券をシュレッダーにかけて、また新しい番号を振り直すようなイメージですね。このメンテナンスをサボるとデータベースが止まってしまうので、エンジニアたちは日々この「整理整頓」に心を砕いているんですよ。
—
終わりに
まとめると、XIDは「誰がいつ作業をしたか」を証明する、データベース界の整理券です。
これがあるおかげで、私たちは誰かの作業を邪魔することなく、安全に、そしてスムーズにデータを読み書きできているんですね。
「ただの数字の羅列」に見えていたものが、少しだけ愛おしく感じられませんか？ もし次にPostgreSQLを触ることがあったら、「ああ、今まさに整理券が発行されているんだな」と、その裏側で働く小さなヒーローたちに思いを馳せてみてくださいね。
それでは、また次回の記事でお会いしましょう！
コメント