WALバッファ

WALバッファとは, データの変更履歴であるログをストレージへ書き出す前に, 一時的に保持しておくためのメモリ領域である. WALとは「Write-Ahead Logging[先行書き込みログ]」の略であり, データ本体を変更する前に必ずログを先に書き出すという原則を指す. この原則によってクラッシュ時の復旧とトランザクションの原子性が保証される. 現代のシステムでは高速なSSDが主流となっているが, メモリ[RAM]との速度差は依然として大きく, またSSDは微細なデータを頻繁に書き込むよりも, ある程度の塊でまとめて書き込む方が性能と寿命の両面で有利である. そのため, 変更内容をまず超高速なバッファに集約し, 最適なタイミングで一括して書き出すことで, データの持続性とシステム全体のレスポンスを高いレベルで両立させている.

Oracle Databaseにおいては, この領域は「レッドゥ・ログ・バッファ[Redo Log Buffer]」と呼ばれる. Oracleは, サーバー・プロセスがバッファへ書き込む動作と, ログ・ライター[LGWR]プロセスがディスクへ書き出す動作を極めて高度に並行化させている. 多コアCPU環境で複数のプロセスが同時にバッファへアクセスしても競合が起きないよう, 内部的にバッファを細分化して管理する「リドゥ・ログバッファの分割[Redo Log Buffer細粒化]」構造を採用しており, エンタープライズ級の巨大なトランザクション負荷にも耐えうる設計となっている.

Microsoft SQL Serverでは, 「ログ・キャッシュ[Log Cache]」または単にログ・バッファと呼ばれる. SQL Serverは最大60KBを上限とする可変サイズの「ログ・ブロック」という単位でバッファを管理するのが特徴である. SSDへの書き込み効率を最大化するため, ログがこのブロックを満たすか, あるいはコミットが発生するまでメモリに留める. また, 超高速な不揮発性メモリ[NVDIMM]をログ・バッファの拡張として利用し, SSDへの書き込み待ちを事実上ゼロにする「永続的ログ・バッファ[Accelerated Database Recovery との併用]」という現代的な最適化手法も提供している.

PostgreSQLにおいては, wal_buffersとして管理される. 複数のバックエンドプロセスが生成するログをバッファ上で一列に並べ, 専用のWALライタープロセス[walwriter]あるいはコミット時のバックエンド自身が代表してSSDへ書き出す「グループコミット」を基本戦略とする. 書き込み先が高速なNVMe SSDであっても, OSを介した通信回数[システムコール]を減らすことがCPU負荷の軽減に直結するという, 効率性を重視した設計である.

MySQL[InnoDB]においては, innodb_log_buffer_sizeで設定される. 最大の特徴は, SSDの性能をどう活かすかの制御をユーザーに委ねている点である. innodb_flush_log_at_trx_commitパラメータの設定により, 毎トランザクションコミット時の厳格な書き込みで安全性を担保するか, あるいは数秒分をバッファに溜めて一気に流し込み, SSDの帯域を限界まで使い切ってスループットを稼ぐかという, 柔軟なトレードオフの選択が可能である.

このように, 各RDBMSは「SSDという高速な物理媒体への通信を, いかに論理的なバッファリングで最適化するか」という課題に対し, それぞれの製品思想に基づいた具体的な解決策を提示している.

Mathematics is the language with which God has written the universe.