注目★★★★★Lobsters
PostgreSQL の MVCC は本当に悪いのか、他のDB エンジンの選択肢と比較
30秒で把握
- 1PostgreSQL MVCC は 40 年前の設計だが、write amplification・テーブル肥大化・長時間スナップショットの問題は意図的選択に由来することを実証
- 2全 MVCC エンジンが 4 つの設計選択肢で異なる答えを与え、各々が別の層 (キャッシュ / tempdb / ライター側) に代償を転嫁している
- 3ワークロード特性に応じた DB 選定には「PostgreSQL は何が得か・何が代償か」の比較フレームワークが必須
要約
PostgreSQL の MVCC 設計は 40 年前のものだが、批評家の主張すべてが設計欠陥ではなく設計選択に由来することを実証する。行更新時に全インデックスが新レコード位置を追従する write amplification (Uber は 2016 年に計測)、トランザクション終了後も dead tuple が蓄積されるテーブル肥大化、長時間のオープンスナップショットが VACUUM を無効化する問題を再現した。MVCC を採用する全 DB エンジン (MySQL / Oracle / SQL Server 等) は old/new バージョン保存位置、バージョンチェーン方向、インデックスの指示先 (物理位置 vs 論理キー)、清掃タイミング (背景 vs トランザクション側) の 4 つの選択肢にそれぞれ異なる答えを与えており、各々の選択が別の層に代償を転嫁している。PostgreSQL は行ベル保存・背景清掃で読書を優遇する設計だが、他エンジンはライター・履歴読者・tempdb・キャッシュなど別の対象に負荷をかける。
あなたへの影響
PostgreSQL の MVCC 的な問題 (肥大化・WAL 増大・vacuum 負荷) は欠陥ではなく読書優遇の必然的代償であり、代替エンジンでは書き込み側やキャッシュ層がその負荷を引き受けることを理解すれば。
推奨：自社ワークロード (OLTP vs 分析・行サイズ・更新頻度) に応じて適切な取捨選択ができる。