2026/05/09 0:46
レイクベースアーキテクチャにより、Postgres の書き込み処理が大幅に高速化されます。
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
Lakebase は、コンピューティングとストレージを分離することで、従来の Postgres システムに固有の長年のパフォーマンスボトルネックを直接解決し、データベースの効率性を革新しています。核心的なイノベーションは、過去にはデータ破損を防ぐ役割を果たしていたが、現在は記述中心型アプリケーションにおいて膨大なログの増加を引き起こしてきたレガシーメカニズムである全ページ書き込み（FPW）を廃止することにあります。この必要性を取り除くことで、Lakebase はウォークトラフィックを 94% 削減し、ネットワークへの負荷を著しく低減しています。システムは個別のチェックポイントプロセスに依存するのではなく、「イメージ生成のプッシュダウン」を採用しており、そのページサーバーが全ページイメージの作成を直接処理することで最適化された速度を実現しています。3 月下旬に行われたシームレスなグローバル展開でダウンタイムゼロの要件を満たし、その結果は画期的です：書き込みスループットは 5 倍に増大し、読み取りの尾部レイテンシーは 2 分の 1 に低下し、新規注文率では 450% 以上の改善が確認されています。このアーキテクチャ的な転換は、データ整合性を損なうことなく、単一モノリシックデータベース展開に対して高いパフォーマンスを提供する代替手段として、取り込み容量を最大化するとともにストレージワークロードを劇的に削減します。
Text to translate:
Lakebase revolutionizes database efficiency by separating compute and storage, directly solving long-standing performance bottlenecks inherent in traditional Postgres systems. The core innovation lies in eliminating Full Page Writes (FPW), a legacy mechanism that once prevented data corruption but now causes massive log inflation on write-heavy applications. By removing this need, Lakebase reduces Write-Ahead Log (WAL) traffic by 94%, significantly lowering network strain. Instead of relying on separate checkpoint processes, the system employs "image generation pushdown," allowing its pageserver to handle full page image creation directly for optimal speed. Following a seamless global deployment in late March that required zero downtime, the results are transformative: write throughput has surged by five times, read tail latencies dropped two-fold, and new order rates exceed 450% improvements. This architectural shift not only maximizes ingestion capacity but also drastically cuts storage workloads, offering companies a high-performance alternative to monolithic database deployments without sacrificing data integrity.
本文
Lakebase におけるアーキテクチャの概要 Lakebase では、コンピューティングとストレージが設計段階から分離されています。この分離は当初、スケール拡大やブランチ作成、即時復旧など運用的な柔軟性を実現するために構築されましたが、同時に巨大なパフォーマンスの可能性を開放します。これらの層を結合（decouple）させることで、従来の単一構成の Postgres 導入では構造上不可能だった方法で、Postgres のコンピューティング負荷の一部を分散ストレージにオフロードできるようになります。本記事では、このアーキテクチャ的な優位性をどのように活かし、10 年以上にわたる Postgres のボトルネックを解消したかを解説します。具体的には、Postgres の書き込みスループットを 5 倍向上させ、読み取りの尾部レイテンシを 2 倍削減し、WAL（Write-Ahead Log）トラフィックを 94% 減少させることに成功しました。
従来型 Postgres の耐故障性の「見えないコスト」 管理された Postgres パフォーマンスで 5 倍の改善を達成した仕組みを理解するためには、従来の Postgres がどのように耐故障性（durability）を取り扱っているかを検討する必要があります。Postgres では、すべてのデータベースの変更はまず、クラッシュ時にデータを失わないようにするための連続したログ（Write-Ahead Log: WAL）に保存されます。クラッシュからの復旧時間を短く保つために、Postgres は定期的に「チェックポイント」と呼ばれるバックグラウンドによる片付け処理を実行します。スナップショットとは異なり、チェックポイントは単なるログ内のマイルストーン（区切り点）の印に過ぎません。チェックポイント実行中、Postgres はメモリー上にあるすべての変更されたデータ（8KB のチャンクとして管理される「ページ」を指す）を取得し、それをログ内の特定の時点でメインディスクにフラッシュします。もしここでクラッシュが発生した場合、Postgres はそのチェックポイントマイルストーンから再開し、ディスク上の直近の WAL ログを再生（replay）することでデータを復元します。
しかし、リスクがあります。サーバーが 8KB のページのディスクへの保存を行っている最中にクラッシュしてしまった場合、ページが一部のみ書き込まれたままとなり、「破断したページ（torn page）」とみなされデータが破損する可能性があります。もし Postgres が破断したページの上に小さなログ更新を再生しようとした場合、そのデータは永久に台無しになります。この問題を解決するため、Postgres は復旧プロセスで破損したディスクに依存しないことを保証する必要があります。これを実現するために「フルページライト（Full Page Write: FPW）」という機構を導入しています。チェックポイントマイルストーン以降のページの最初の書き込み時、Postgres は小さな変更量をログに記録するだけでなく、8KB のページ全体をコピーして WAL に埋め込みます。もしクラッシュが発生してディスク上のページが破損した場合でも、Postgres は壊れたディスクを無視し、WAL から pristine な 8KB バックアップを取得し、これを書き込み残りのログを再生する完璧なスタートポイントとして使用します。この仕組みは絶対的な安全性を保証しますが、コストが高いのが実情です。書き込み負荷の高いアプリケーションの場合、8KB ページ全体をログに記録することで、ログの体積が最大 15 倍まで膨張し、これがシステム全体の最も大きなパフォーマンスボトルネックとなり得ます。
Lakebase の解決策：破断ページリスクの排除 Lakebase のアーキテクチャでは、コンピューティングノードはステートレスです。つまり、ローカルなデータディレクトリに依存しません。代わりに、WAL を Paxos ベースのクォーラム構成である safekeepers（安全管理者）へストリーム送信用しています。ローカルディスク上のページが存在しないため、「破断したページ」が発生する故障モードそのものが存在しなくなります。しかし、FPW を安易に無効化すると二次的な問題として「読み取りパフォーマンス」が浮上します。ログ内にそのような定期的なフルページイメージが存在しない場合、ストレージ層は読み取りリクエストに対してページを再構築するために、無限長の小さなデルタ（差分）の連鎖全体を再生する必要が生じます。かつてはチェックポイント頻度という有界な O(checkpoint frequency) による再生だったものが、未確定な連鎖へと変化し、読み取りレイテンシとリソース消費の急増を引き起こすことになりました。
革新：イメージ生成のプッシュダウンと分散ストレージへの統合 この課題に対する解決策として、我々はコンピューティングノードからインテリジェンスをストレージ層へ移動させました。これを「イメージ生成のプッシュダウン」と呼びます。Postgres コーディングがストレージからページを要求する際、Lakebase 分散ストレージシステムの構成要素である pageserver（ページサーバー）は、そのページの最新のマテリアライズされた（実体化された）イメージを見つけ出し、その上に WAL のデルタ（差分）を重ねることで再構築します。かつてコンピューティング側で WAL に埋め込んでいたフルページイメージが、このデルタ連鎖内の定期的なリセットポイントとして機能することで、連鎖を自然に有界に保ち、読み取りも高速化されます。このメカニズムの詳細については「Neon ストレージエンジンへの深掘り」をご覧ください。
フルページライトを無効化すると、これらのリセットポイントは消え去ります。分散ストレージシステム内に追加のインテリジェンスが存在しない場合、頻繁に更新されるページは間に合図のないイメージがなく、小さなデルタの長い連鎖を蓄積してしまう可能性があります。その結果、pageserver が読み取りを処理するためにこの全連鎖を再生することとなり、読み取りレイテンシとリソース消費の不愉快な増加を引き起こします。この問題を避けるために、我々はコンピューティング側の WAL ストリームからイメージ生成の責任を負荷を、ストレージ層へとプッシュダウンしました。これにより、ストレージの有界な読み取り動作を維持しつつ、コンピューティング上の WAL オーバーヘッドを排除することができました。pageserver は現在、ページに累積されたデルタレコード数が設定閾値を超え、かつ間に合図のないイメージが存在する場合、フルページイメージを生成します。これは明らかに優れているアプローチです。なぜなら、新しいイメージを生成する判断は、Postgres のチェックポイントプロセスとは無関係な「ページの実際の変更数」に基づいているからです。
これによりパフォーマンスが劇的に向上する理由は以下の通りです：
- ネットワーク効率: コンピューティング側は実際の変更内容であるコンパクトなデルタのみを送信するため、我々のベンチマークではトラフィックを 94% 削減することに成功しました。
- スケーラビリティ: 負荷が単一の Postgres 書き込み者から、分散かつ独立して拡張可能なストレージ層へ移行します。プロジェクトブランチのイメージ生成は、バックグラウンドで複数の pageserver に共有されます。
- 最適な読み取り: イメージを生成するタイミングが、Postgres のチェックポイントプロセスとは無関係な「ページの実際の変更数」に基づいて決定されるためです。
影響の定量化：実験室から本番環境へ 我々は HammerDB TPROC-C（TPC-C を基にした OLTP ベンチマーク）を使用してこの最適化をベンチマークし、現実の本番環境でのワークロードでも結果を検証しました。
1. サーブレスコンピューティングのスケーリング スループットは「分あたりの新規注文数（NOPM）」で測定されます。ゲインはコンピューティングインスタンスのサイズに応じて劇的にスケールします：
- 4-vCPU: 以前 78,876 NOPM → 現在 94,891 NOPM（20% の改善）
- 16-vCPU: 以前 95,832 NOPM → 現在 269,189 NOPM（2.8 倍の改善）
- 32-vCPU: 以前 95,686 NOPM → 現在 439,300 NOPM（4.5 倍の改善）
32 vCPU のコンピューティング環境では、改善率は 450% を超えました。コンピューティング側でフルページイメージを生成する場合、トランザクションごとに平均 58Kb の WAL が生成されます。イメージ生成をストレージ層へプッシュダウンすると、これは 4Kb 以下まで減少します（94% の削減）。スループットの改善は直接的にこの結果に由来します：WAL が少ないことは、書き込みパス上の競合が減り、消費するネットワーク帯域が減り、ストレージ層による取り込み作業も軽くなります。Postgres の FPW ボトルネックを除去したことで、スループットをコンピューティングリソースに対して線形にスケールさせることが可能になりました。これは重負荷の書き込み下で単一構成の Postgres が苦手とする点です。
2. 本番環境での実証検証 高プロファイルの 56 vCPU プロジェクトを持つ本番環境において、イメージプッシュダウンを有効にすることで、定常状態での WAL 生成量を 30 MB/s からわずか 1 MB/s に削減することに成功しました。
- 本番顧客の WAL レート: ラット数が低いほど良いです。この体積の減少は、日常のピーク時のトランザクションスループットの増加と直接的な相関関係にあります。
- 読み取りレイテンシ: デルタ連鎖を最適化することで、1 つの読み取りごとに適用される必要がある WAL レコード数が大幅に減少しました。p99 レイテンシは 30% から 50% 低下し、p50 レイテンシも約 30% 低下する様子が見られました。
- リージョンレベルの影響: より広い視野で見た場合、リージョンレベルでは有効化後にコンピューティングからの全 WAL 生成量が最大 4 倍減少しました。ストレージエンジンからの読み取り p99 レイテンシも最大 3 倍改善し、非常に安定性を増しました。
3. Lakebase 同期テーブル データ集約型の Synced Tables（同期テーブル）においては、影響は即座に現れました。ある顧客では、イメージプッシュダウンを有効にするだけで、取り込みスループットが 1 秒あたり 17,000 行から 62,000 行へと跳ね上がり、3 倍の増加を実現しました。
シームレスな展開：中断なしのパフォーマンス向上 今年 3 月以降、我々はこの機能を実装した fleets（艦隊/全環境）全体へロールアウトしてまいりました。現在、世界中でのすべての Lakebase サーブレスおよび Neon データベースでアクティブになっています。この変更は、既存の Postgres XLOG_FPW_CHANGE WAL レコード機構を使用して実装されており、コントロールプレーンとストレージシステムが移行を自動調整しました。そのため、顧客に対して再起動や中断は必要ありませんでした。
今後の管理型 Postgres パフォーマンスへの展望 Lakebase アーキテクチャは柔軟性のために構築されましたが、同時にパフォーマンスの最適化も意図されています。フルページライトのプッシュダウンも、ストレージとコンピューティングの分離から得られる恩恵を収穫するための体系的な取り組みの一部です。ゼロダウンスライスのパッチ適用のためにキャッシュプレウォーミングを導入したように、我々は引き続き重いタスクをトランザクションから離脱させ、拡張可能なバックグラウンドストレージスタックへ移動させる活動を続けています。Postgres への書き込み課税（write tax）は、もはや過去の話となりました。