メインコンテンツまでスキップ

データベースブランチ

備考

ベータ版

Lakebase Postgres (オートスケール Beta) は、 Lakebase の次のバージョンであり、評価のみに利用できます。 本番運用ワークロードの場合は、 Lakebase Public Previewを使用します。 どのバージョンが適しているかを判断するには、バージョンの選択を参照してください。

Lakebase のデータベース ブランチを使用すると、Git でコードをブランチするのと同様に、データ環境を安全にバージョン管理、テスト、進化させることができます。本番運用のワークロードに影響を与えることなく、開発、実験、またはスキーマ変更のテスト用に、分離された完全に機能するデータベース ブランチを即座に作成できます。

デフォルトでは、Lakebase は新しいプロジェクトを作成するときに 2 つのブランチを作成します。

production (default branch)
└── development (child branch)

productionブランチはルート ブランチであり、アプリケーションの本番運用データを格納することを目的としています。 developmentブランチはproductionの子であり、ビルドとテストにすぐに使用できる環境を提供します。ブランチ リセットを使用すると、データのシーディングやティアダウン スクリプトなしで、 productionからdevelopment即座に更新して最新のスキーマとデータを取得できます。

ワークフローに合わせて必要に応じて追加のブランチを作成できます。たとえば、本番運用前のテスト用にstagingブランチを追加するか、完全に分離するために開発者ごとのブランチを作成します。 各ブランチは独立して動作し、子ブランチの変更は親ブランチに影響を及ぼすことはありません。

データベースブランチの仕組み​

親子関係​

すべてのブランチ (ルート ブランチを除く) には親が存在します。これにより階層が作成されます。

production (root branch)
├── staging (child of production)
│   └── feature-test (child of staging)
└── development (child of production)
    └── bugfix-branch (child of development)

この階層により、重要な分離が実現します。子ブランチに加えた変更は親には影響せず、親への変更は子に自動的には反映されません。親から更新されたデータが必要な場合は、子ブランチをリセットできます。親の履歴の任意の時点からブランチを作成することもできます。これは、ポイントインタイムのリカバリ、履歴データに対するテスト、またはコンプライアンス シナリオに役立ちます。

ブランチを作成するときは、現在のデータから初期化するか、特定の時点から初期化するかを選択します。各オプションの詳細な手順と詳細については、 「ブランチの作成」を参照してください。

コピーオンライトストレージ​

Lakebase はコピーオンライト技術を使用して親子の分岐を効率化します。新しいブランチを作成すると、親からスキーマとデータの両方が継承されますが、同じデータへのポインターを通じて基礎となるストレージが共有されます。データが変更された場合にのみ、Lakebase は新しいデータを書き込みます。これはつまり：

  • ブランチは即座に表示されます。データベースのサイズはブランチの作成時間に影響しません。
  • ブランチ間で実際に変更されたデータに対してのみ料金が発生します
  • ブランチを作成しても本番運用ワークロードのパフォーマンスには影響しません
production branch          development branch (at creation)
┌─────────────────┐       ┌─────────────────┐
│  [Data A]       │◄──────│  → Data A       │  (shared)
│  [Data B]       │◄──────│  → Data B       │  (shared)
│  [Data C]       │◄──────│  → Data C       │  (shared)
└─────────────────┘       └─────────────────┘

After modifying data in development:
┌─────────────────┐       ┌─────────────────┐
│  [Data A]       │◄──────│  → Data A       │  (shared)
│  [Data B]       │       │  [Data B']      │  (changed)
│  [Data C]       │◄──────│  → Data C       │  (shared)
└─────────────────┘       └─────────────────┘
                          Only changed data is stored separately

ブランチの操作​

ブランチリセット​

ブランチをリセットすると、子ブランチが親の現在の状態と一致するように即座に更新されます。これは、開発またはステージング ブランチを最新の本番運用データで更新する場合に便利です。 コピーオンライト技術を使用して操作は即座に完了し、接続の詳細は変わりません。

ブランチリセットは一方向（親 → 子）にのみ機能します。変更を子から親に移動するには、標準の移行ツールを使用してスキーマの変更を適用します。詳細なステップとシナリオについては、ブランチのリセットを参照してください。

ポイントインタイムリカバリ​

復元ウィンドウ内の特定の時点からブランチを作成できます。これは、誤った削除などのデータ エラーから回復したり、過去の問題を調査したり、監査やコンプライアンスの目的で履歴データにアクセスしたりする場合に役立ちます。 たとえば、重要なテーブルが昨日の午前 10 時 23 分に削除された場合、午前 10 時 22 分に設定されたブランチを作成して、不足しているデータを抽出できます。同様に、財務調整、規制監査、またはフォレンジック分析のために、特定の日付におけるデータベースの状態を反映するブランチを作成することもできます。ブランチ リセット (既存のブランチを更新する) とは異なり、ポイントインタイム リカバリでは履歴データから新しいブランチが作成されます。 詳細については、 「ポイントインタイム リストア」を参照してください。

特殊なブランチタイプ​

デフォルトブランチ​

Lakebase プロジェクトを作成すると、 production (安全ブランチ) とdevelopment (本番運用の子) の 2 つのブランチが自動的に取得されます。 どちらも最初は空で、データの入力待ち状態です。このセットアップにより、安全なワークフローで開始できるようになります。つまり、 developmentでスキーマの変更をテストし、動作を確認したらproductionに対して同じ移行を実行します。

あなたのブランチはゼロにスケールされることはなく、アイドル期間中に他のブランチ コンピュートがスケールダウンした場合でも、ブランチは利用可能な状態を維持します。

保護されたブランチ​

保護されたブランチには、偶発的な変更を防ぐための安全装置が備わっています。親から削除またはリセットすることはできず、非アクティブであるため自動アーカイブの対象から除外されます。保護されたブランチは、存在する間はプロジェクトの削除もブロックするため、重要なインフラストラクチャを誤って削除してしまうことがありません。本番運用などの重要なデータには保護されたブランチを使用します。 詳細については、保護されたブランチを参照してください。

分岐がリソース消費に与える影響​

データベース ブランチでは、実際に使用した分に対してのみ料金を支払います。

ストレージ : 変更されたデータに対してのみ料金をお支払いいただきます。開発ブランチを作成し、100 GB のデータベース内の 1 GB のデータを変更する場合、200 GB ではなく、約 1 GB のストレージに対して料金を支払うことになります。変更されない 99GB はブランチ間で共有されます。

コンピュート : 各ブランチには、個別にスケーリングできる独自のコンピュートがあります。 料金はアクティブなコンピュート時間に対してのみお支払いいただきます。 コンピュートはアイドル時にゼロにスケールします。 つまり、ときどき使用する開発ブランチのコストは、専用の開発サーバーを 24 時間 365 日実行するよりもはるかに低くなります。

大丈夫 ブランチ コンピュートは決してゼロにスケールせず、本番運用ワークロードが利用可能なままであることを保証します。

支店戦略​

チームがブランチを編成する一般的な方法は次のとおりです。

シンプル（個人および小規模チーム）​

すべての作業にデフォルトのブランチを使用します。

production
└── development

developmentブランチは、新しい機能を安全に構築する場所です。本番運用に対するリスクを負うことなく、スキーマの変更、テスト データの追加、およびエクスペリメントを行うことができます。 準備ができたら、移行ツールを使用してproductionに対してテスト済みのスキーマ移行を実行し、 developmentリセットして、新しいデータで次の機能を開始します。

ステージング付き​

本番運用前のテスト用にステージング ブランチを追加します。

production
├── staging
└── development

本番運用前のテストが必要な場合は、本番運用データをミラーリングするstagingブランチを維持します。 そこでアプリケーションをデプロイし、現実的なデータに対して統合テストとパフォーマンス テストを実行し、稼働前に信頼を得ます。テストデータを更新するために、定期的にstaging productionからリセットしてください。

開発者ごとのブランチ​

各開発者は完全に独立して作業します。

production
└── development
    ├── dev-alice
    ├── dev-bob
    └── dev-charlie

このパターンにより、開発者が互いの作業を妨害することがなくなり、全員がスキーマの変更を独立してテストできるようになります。各開発者は、他の開発者に影響を与えることなく独自のスキーマ変更とデータ修正を実験し、準備ができたらテスト済みの移行を共有developmentまたはproductionブランチに適用できます。

次のステップ​

に最終更新