データベースの「コミット」とは何か？ログバッファと揮発性の問題をわかりやすく整理してみた

はじめに

「コミットってなに？SQLのCOMMITと内部処理のコミットって違うの？」
「ログバッファって消えたらヤバいやつ？」
「更新情報がメモリにしかない状態で電源が落ちたらどうなる？」

読書中にこんな疑問が出てきました。

この記事では、DBMSのログバッファ、ログファイル、コミット、そしてそれにまつわるトレードオフについて、記事として残します。

まずSQLでのCOMMIT文の使い方を思い出してみましょう。

BEGIN;
UPDATE users SET name = 'Taro' WHERE id = 1;
COMMIT;

このCOMMIT文は、「ここまでの変更を確定してね」という意味です。
でもDBMS内部ではこのとき、ある重要な処理が走っています。

SQLのCOMMITを受け取ったDBMSは、次のようなステップを踏みます：

ポイントは「ログがディスクに書かれるまでは、更新は“未確定”」 ということです。

名前	保存場所	性質	消える？
ログバッファ	メモリ	一時的	障害で消える
ログファイル	ディスク	永続的	基本消えない

ここが今回の本題。

たとえばこんな状況を想像してみてください：

このとき、ログバッファはメモリなので全部消えます。
つまり、更新情報も消えます。
結果、DBMSが復旧しても「更新はなかった」ことになってしまうんです。

この揮発性の問題を防ぐため、DBMSは次のようにルールを設けています：

この処理があるからこそ、障害が起きても更新履歴が残っていて復旧できるのです。

ここで出てくるのがディスク書き込みのタイミングによるトレードオフです。

優先するもの	方法	メリット	デメリット
安全性	`COMMIT`時にログを即ディスクへ（同期）	データ損失なし	書き込みが遅くなる
パフォーマンス	ログは後でまとめて書く（非同期）	書き込みが速い	障害時にログが失われる可能性

DBMSの内部動作を知ると、何気なく使っているSQLにも深みが出てきますよね。
おしまい。