巷で話題の『失敗から学ぶRDBの正しい歩き方』(通称「そーだい本」: 以下、文字列長の都合でこの呼称を使用します)を読んだメモです。 Webアプリケーションを構築していく時、データの設計や運用の面で「こうしておけばよかったー」と後から悶々とする場面は多々あるんですが、本書はそれら現場のモヤモヤや失敗の数々に名前を付け、「アンチパターン」として断罪(！？)していく内容になってます。 元々は『SQLアンチパターン』という、よく似たコンセプトの素晴らしいオライリー本があるんですが、本書でも随所に言及があるので未読の方はまずそちらから手をつけるのがいいかもしれません。 ざっくりした内容はそれぞれリンク先の章立てを覗いてみてください。なんとなく雰囲気はつかめるんじゃないかと思います。 今回は両者を比べながらゆるーく感想を書いていきたいと思います。 両者の守備範囲この2つ、まぁよく似た構成ではあるんで

図1　主なプロセスの流れ PostgreSQLは、ライタがデータファイルやインデックスファイルをディスクに更新しています。ただし、その更新は、コミットに合わせてリアルタイムで行われているわけではありません。性能向上のため、チェックポイントと呼ばれる更新タイミングが発生するまでは、更新があっても共有バッファにデータを貯めておきます。この貯められたデータをダーティページと呼びます。そしてチェックポイントのタイミングで、チェックポインタがダーティページをディスクに書き込みます。 そのため、共有バッファに更新情報を貯めている間に障害が起きると、ダーティーページを失う可能性があります。それを防ぐために、共有バッファ中のデータに対してどのような更新を行ったかの情報を保存しているのがWALです。WALはコミットのタイミングでWALライタが記録しています。クラッシュリカバリが必要になったときは、WALの中