Postgresにおけるデータベースブランチング：Databricks LakebaseによるGitスタイルのワークフロー

Summary

Databricks Lakebase Postgres のデータベースブランチは、コピーオンライトストレージを使用して、データを複製することなく、数秒で分離された環境を作成します。
Lakebase ブランチは、各開発者、プルリクエスト、または CI テスト実行に独自の分離された環境を提供することで、共有ステージングデータベースと pg_dump ワークフローを置き換えます。
ブランチは、同じ API を通じて、AI エージェント向けのインスタントポイントインタイムリカバリとプログラム可能な一時データベースもサポートします。

データベースが開発ワークフローにおける最後のボトルネック

データベースのブランチングは、最新の開発ワークフローに欠けている基本的な機能です。スタックの他のすべての部分は、高速なイテレーションをサポートするように進化してきました。コードにはGitがあります。インフラストラクチャにはTerraformがあります。デプロイには数分で実行されるCI/CDパイプラインがあります。しかし、リレーショナルデータベースは依然として10年前と同じ方法で動作しています。

ほとんどのチームは、単一のステージングデータベースを共有しています。セットアップから数日以内に、そのデータベースは本番環境との同期が取れなくなります。開発者が異なる順序でマイグレーションを適用すると、スキーマが分岐します。シーケンス値が一致しなくなります。テストデータが蓄積され、結果を汚染します。最終的に誰かがすべてを再シードし、サイクルが繰り返されます。

新しい環境のセットアップはさらに悪いです。標準的なアプローチは、本番環境に対してpg_dumpを実行し、それが完了するのを待ち（データベースサイズに応じて数分から数時間）、新しいインスタンスにロードし、アクセスを設定し、その結果が本番環境で実行されているものを実際に反映していることを願うことです。500GBのデータベースの場合、これは500GBのコピー操作に加えて、それを実行し続けるためのコンピューティングとストレージを意味します。

結果は予測可能です。チームは、新しい環境を作成するのが高価で遅すぎるため、作成を避けます。開発者は、単一の変更可能なステージングデータベースを共有します。マイグレーションは古いデータに対してテストされるか、まったくテストされません。プレビューデプロイメントは、現実的なスキーマではなく、空のフィクスチャに対して実行されます。CIテストは状態を共有し、不安定な結果を生成します。

データベースは、開発者が触るのを恐れるスタックの部分になります。

Databricks Lakebase Postgresは、データベースブランチングでこれを変更します。

データベースブランチングとは何か

データベースブランチはデータベースのコピーではありません。この区別は、分離された環境の経済性を完全に変えるため重要です。

データベースをコピーすると、そのすべてのデータとスキーマを新しい独立したインスタンスに複製します。時間とコストはデータベースのサイズに比例して増加します。すべてのコピーは完全なクローンであり、すべてのクローンは作成された瞬間から古くなり始めます。

ブランチは異なる方法で機能します。Lakebaseでブランチを作成すると、完全に分離された新しいPostgres環境が得られます。この環境は次のとおりです。

特定の時点での親の正確なスキーマとデータから開始します
データを複製するのではなく、同じ基盤となるストレージを共有します
実際に変更を加えた場合にのみ新しいデータを書き込みます

これはコピーオンライトと呼ばれます。2つのブランチが分岐していない限り、それらは同じ保存済みデータを参照します。ブランチでマイグレーションを実行したり、行を挿入したり、テーブルを変更したりすると、その変更のみが個別に書き込まれます。それ以外はすべて親と共有されます。

データベースコピー対データベースブランチ

	データベースコピー（pg_dump、RDSスナップショット）	データベースブランチ（Lakebase）
作成時間	数分から数時間、データベースサイズに比例	数秒、データベースサイズに関係なく一定
ストレージコスト	全データの完全な複製	変更にのみ比例（コピーオンライト）
分離	完全ですが、維持するにはコストがかかります	完全、独立したコンピューティングと接続文字列付き
鮮度	作成された瞬間から古い	ブランチ作成時の親の正確な状態から開始
クリーンアップ	インスタンスとストレージの手動解体	ブランチを削除すると、コンピューティングとストレージが自動的に回収されます

実際には、これは次のことを意味します。

データベースサイズに関係なく、ブランチの作成は数秒で完了します。10GBのデータベースも2TBのデータベースも同じ時間でブランチ化されます。
ストレージコストは、総データサイズではなく、変更に比例します。500GBのデータベースで50MBのデータを変更するブランチは、約50MBの追加ストレージを使用します。
各ブランチには独自のPostgres接続文字列とコンピューティングエンドポイントがあります。ブランチは互いに、また親から完全に分離されています。
アイドル状態のブランチはコンピューティングをゼロに自動的にスケーリングします。ブランチが実際に使用されているときのコンピューティングに対してのみ支払います。

ブランチは、開発者、CIパイプライン、AIエージェント、自動化によって、自由に作成、使用、破棄できるように設計されています。それらは維持する必要のある貴重な環境ではありません。それらはGitブランチのように使い捨てです。

データベースブランチングを可能にするアーキテクチャ

従来のマネージドPostgres（RDS、Azure Database for PostgreSQL）は、コンピューティングとストレージを結合しています。データベースプロセスとそのデータは同じインスタンス上に存在し、データは単一の変更可能なファイルシステムとして保存されます。そのため、2番目の環境を作成するための唯一のオプションはコピーです。ファイルシステムを複製する必要があります。

しかし、Lakebaseは異なって構築されています。コンピューティングとストレージを完全に分離しています。すべてのデータは、既存のデータを上書きするのではなく、すべての変更を新しいバージョンとして記録する、分散されたバージョン管理されたストレージエンジンに書き込まれます。このログ構造アーキテクチャにより、データベースブランチングが機能としてではなく、基本的な機能として可能になります。

ストレージはバージョン管理されているため、複数のブランチは競合のリスクなしに同じ基盤となるデータを参照できます。コンピューティングは独立しているため、各ブランチは独自のPostgresプロセスを実行し、独自にスケーリングします。アイドル状態の非本番ブランチは自動的にゼロにスケールダウンし、接続が入るとミリ秒単位で再起動します。

すべてのデータベースブランチング実装が同等ではありません。一部のプラットフォームは完全なインスタンスコピーを作成してブランチと呼びます。他のプラットフォームはデータなしでスキーマのみをブランチ化します。Lakebaseブランチにはスキーマとデータの両方が含まれ、ストレージレイヤーでコピーオンライトを使用して重複を回避し、ブランチごとに独立した自動スケーリングコンピューティングを提供します。これにより、追加のインフラストラクチャをプロビジョニングすることなく、ブランチを自由に大規模に作成することが実用的になります。

このアーキテクチャはタイムトラベルも可能にします。すべてのデータバージョンが設定可能な復元ウィンドウ内に保持されるため、現在の状態だけでなく、過去の任意の時点からブランチを作成できます。これはインスタントポイントインタイムリカバリを可能にします。WALログを再生したりバックアップを復元したりする代わりに、必要なタイムスタンプでブランチを作成し、そこから直接読み取ります。

データベースブランチングがチームにもたらすもの

データベースブランチングが、高価なコピー操作ではなく、高速で安価な基本的な機能になれば、新しいワークフローが実用的になります。以下は、最も一般的なパターンの概要です。（次の記事でそれぞれを詳細に説明します。）

開発者ごとのブランチ。 すべてのエンジニアは、本番環境のようなデータを持つ独自の分離された環境を取得します。共有開発データベースでの互いの変更を踏みつけ合うことはもうありません。ブランチが本番環境からかけ離れすぎると、1つのコマンドでリセットして最新のスキーマとデータをプルします。ブランチはアイドル時にゼロにスケールするため、このパターンは大規模なチームでも手頃な価格のままです。

プルリクエストごとのブランチ。 PRが開かれたときにブランチ作成を自動化し、マージまたはクローズされたときに削除します。VercelまたはNetlifyのプレビューデプロイメントはそれぞれ独自のデータベースブランチを取得するため、フロントエンドプレビューは現実的で分離されたデータによってバックアップされます。マイグレーションは、空のテストフィクスチャではなく、実際のデータ形状と制約に対して実行されます。これはチームが最初に採用するワークフローであり、データベースブランチングを全面的に採用するよう説得するのに役立ちます。

テスト実行ごとのブランチ。 CIパイプラインは、各実行に対して新しい分離されたデータベースを取得します。以前のテストからの残存状態はありません。空のコンテナイメージが起動してから偽のデータでシードされるのを待つ必要はありません。共有データやテスト順序の依存関係によって引き起こされる不安定な結果はありません。各実行は同じベースラインから開始します。決定論的なデータが必要なテストの場合、特定の時点または特定のログシーケンス番号（LSN）からブランチを作成できます。

インスタントリカバリ。復元ウィンドウ内の任意の時点からブランチを作成します。テーブルの削除、移行の失敗のデバッグ、または履歴データの監査を、本番環境に影響を与えることなく行えます。スキーマ差分を使用して、変更前後の状態を比較します。リカバリブランチから必要なものをエクスポートしてから、削除します。従来のPITRに必要な時間ではなく、プロセス全体で数秒しかかかりません。

AIエージェント向けの短時間環境。AIエージェントは、Lakebase APIを介してプログラムでデータベースをプロビジョニングし、タスクの実行中に使用し、完了したらシャットダウンできます。プラットフォームはスナップショットの上にバージョニングを構築できます。各エージェントアクションはチェックポイントを作成し、ユーザーはバージョン間を即座にジャンプできます。エージェントが悪意のある移行を実行したり、データを破損したりした場合、ロールバックは単一のAPI呼び出しで済みます。

はじめに

Databricks Lakebase のデータベースブランチングは、Postgres データベースを開発ワークフローの最も遅い部分から最も速い部分へと変えます。

コンソール、CLI、または API を使用して、1 分以内に最初のブランチを作成できます。CLI からは次のようになります。

これで完了です。本番環境のスキーマとデータ全体を含む、分離された Postgres 環境が用意され、使用する準備が整いました。

Postgres 上に構築していて、データベース環境の管理に伴うオーバーヘッドにうんざりしている場合は、単一の開発ブランチから始めます。次に、PR ごとに 1 つ試します。1 つのデータベースブランチングワークフローから始めたほとんどのチームは、すぐに残りのワークフローを採用します。

Databricks Lakebase は、エージェントとアプリケーション向けに構築されたサーバーレス Postgres です。詳細については、 databricks.com/product/lakebase を参照してください。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事