Lakebase で分岐すると、Git でのコードの分岐と同様に、データ環境のバージョン管理、テスト、および進化を安全に行うことができます。 運用環境のワークロードに影響を与えることなく、スキーマの変更を開発、実験、またはテストするために、分離された完全に機能するブランチを即座に作成できます。
既定では、Lakebase では、新しいプロジェクトを作成するときに 1 つの production ブランチが作成されます。 これは、アプリケーションの運用データを格納するための既定のブランチです。
必要に応じて、ワークフローに合わせて追加のブランチを作成できます。 たとえば、ビルドとテスト用の development ブランチ、実稼働前テスト用の staging ブランチを追加したり、完全な分離のために開発者ごとのブランチを作成したりします。 各枝は独立して動作するため、子の変化が親に影響することはない。 ブランチ リセットを使用すると、親から子ブランチを更新して、データ シード処理や破棄スクリプトを使用せずに、最新のスキーマとデータを取得できます。
ブランチの動作
親子リレーションシップ
すべてのブランチ (ルート ブランチを除く) には親があります。 これにより、階層が作成されます。
production (root branch)
├── staging (child of production)
│ └── feature-test (child of staging)
└── development (child of production)
└── bugfix-branch (child of development)
この階層により、重要な分離が提供されます。子ブランチに加えた変更は親に影響を与えません。親に対する変更は子に自動的に表示されません。 この隔離はPostgresのロールの状態やデータベースにも及びます。つまり、あるブランチで作成されたロールやデータベース、適用されたGRANTやREVOKE、変更されたロール属性は、他のブランチには影響しません。 親からデータを更新する必要がある場合は、子分岐をリセットできます。 親の履歴の任意の時点からブランチを作成することもできます。これは、ポイントインタイム リカバリー、履歴データに対するテスト、またはコンプライアンス シナリオに役立ちます。
ブランチを作成するときは、現在のデータから初期化するか、特定の時点から初期化するかを選択します。 各オプションの詳しい手順と詳細については、「 ブランチの作成 」を参照してください。
コピーオンライト ストレージ
Lakebase では、書き込み時のコピー テクノロジを使用して、親子分岐を効率的にします。 新しいブランチを作成すると、その親からスキーマとデータの両方が継承されますが、基になるストレージは同じデータへのポインターを介して共有されます。 データを変更した場合にのみ、Lakebase は新しいデータを書き込みます。 これは、以下のようなことを意味します。
- ブランチはすぐに表示されます。データベースのサイズがブランチの作成時間に影響しない
- ブランチの作成は、運用環境のワークロードにパフォーマンスに影響しません
コピーオンライトはブランチの保存方法を決定しますが、ブランチの請求方法はブランチが失効するかどうかに依存します。 分岐が資源消費に与える影響をご参照ください。
production branch child branch (at creation)
┌─────────────────┐ ┌─────────────────┐
│ [Data A] │◄──────│ → Data A │ (shared)
│ [Data B] │◄──────│ → Data B │ (shared)
│ [Data C] │◄──────│ → Data C │ (shared)
└─────────────────┘ └─────────────────┘
After modifying data in child branch:
┌─────────────────┐ ┌─────────────────┐
│ [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という既定のブランチで作成されますが、任意のブランチを既定として指定できます。 既定のブランチは 同時にアクティブなコンピューティング制限から除外され、常に使用可能な状態が維持されます。
保護されたブランチ
保護されたブランチには、偶発的な変更を防ぐためのセーフガードがあります。 親から削除またはリセットすることはできず、非アクティブのため自動アーカイブから除外されます。 また、保護されたブランチでは、プロジェクトの削除が存在する間もブロックされるため、重要なインフラストラクチャを誤って削除できなくなります。 さらに、Lakebase は、ストレージ キャッシュ内の保護されたブランチのデータに優先順位を付け、保護されたブランチのパフォーマンスを他のブランチよりも優先します。 各プロジェクトは、1 つの保護されたブランチをサポートします。 運用環境などの重要なデータには、保護されたブランチを使用します。 詳細については、 保護されたブランチを 参照してください。
分岐がリソースの消費に与える影響
ブランチの場合は、コンピュートとストレージを別々に支払います。
コンピューティング: 各ブランチには、個別にスケーリングできる独自のコンピューティングがあります。 アクティブなコンピューティング時間に対してのみ支払います。 アイドル時にスケールを 0 に計算します。 つまり、使用する開発ブランチのコストは、専用開発サーバーを 24 時間 365 日実行するよりもはるかに少なくなります。
保管:支店の保管料金の請求方法は、保管期限があるかどうかによって異なります:
- 期限切れになるブランチは、そのブランチで変更されたデータ分のみ請求されます。 コピーオンライトを通じて、親の未変更データを共有します。 例えば、100GBのデータベースの期限切れ間近のブランチで1GBのデータを修正した場合、約1GBのストレージ分を支払うのであって、100GBの完全なコピー分ではありません。
- 有効期限のない 恒久 的なブランチは、親とわずかに異なるデータでも独立したデータベースのように、その全データサイズで請求されます。
Warning
ブランチを恒久的にするということは、その分岐上の変更データだけでなく、その全データサイズに対して支払うことを意味します。 ブランチを期限切れにしない設定は常に意図的な選択です。ブランチを作成する際に [削除しない] を [自動削除] に対して選択するか、既存のブランチの有効期限を解除するだけです。 短命のコピーだけが必要な場合は、期限を設けて、そのブランチでの変更分に対してのみ課金されるようにしてください。 ブランチの有効期限を参照してください。
ブランチ戦略
チームがブランチを編成する一般的な方法を次に示します。
シンプル (個人および小規模チーム)
1つの開発ブランチを備えた既定のブランチを使用します。
production
└── development
development ブランチでは、新しい機能を安全に構築できます。 スキーマの変更、テスト データの追加、運用ブランチへのリスクなしで実験を行うことができます。 準備ができたら、(移行ツールを使用して) production に対してテスト済みのスキーマ移行を実行し、 development をリセットして、新しいデータで次の機能を開始します。
ステージングあり
実稼働前テスト用のステージング ブランチを追加します。
production
├── staging
└── development
実稼働前テストが必要な場合は、運用ブランチ データをミラーリングする staging ブランチを維持します。 アプリケーションをそこにデプロイし、現実的なデータに対して統合テストとパフォーマンス テストを実行し、稼働する前に信頼を得ることができます。
stagingからproductionを定期的にリセットして、テスト データを更新します。
開発者ごとのブランチ
各開発者は完全に分離して動作します。
production
└── development
├── dev-alice
├── dev-bob
└── dev-charlie
このパターンにより、開発者がお互いの作業に干渉するのを防ぎ、すべてのユーザーがスキーマの変更を個別にテストできます。 各開発者は、他のユーザーに影響を与えずに独自のスキーマ変更とデータ変更を試し、準備ができたら、テストされた移行を共有 development または production ブランチに適用できます。
Note
ステージングや開発者ごとのパターンは長寿命のブランチを使用します。 有効期限が設定されていないブランチは、その全データサイズで請求されます。 「ブランチ作成がリソース消費に与える影響」を参照してください。
その他のリソース
- ブランチの管理では、ブランチの作成、リセット、削除の方法を学びます。
- 重要なブランチを守るための保護ブランチ