Lakebase は、ストレージとコンピューティングを分離します。 クエリを実行するPostgresエンジンはステートレスで、データは独立して永続する耐久性のあるストレージ層に存在します。 この分離こそが、オートスケーリング、ゼロへのスケール、即時ブランチ、リードレプリカ、迅速なフェイルオーバーを可能にします。
Lakebaseが何を変えているかを示すために、このページでは従来のシングルマシンデータベース設計から始まり、その後Lakebaseが同じ設計を独立したレイヤーに分割し、それぞれの部分が何をしているかを説明します。
従来のデータベースの構築方法
Lakebaseを見る前に、そのモデルに置き換えられていることを考えてみてください。 従来のPostgresデータベースはモノリスです。 単一のマシンがクエリエンジンを実行し、 書き込み先行ログ(WAL) とデータファイルの両方をローカルマウントポイントに接続されたディスクに書き込みます。 従来、これらのディスクは同じマシンの一部であるローカルなものでしたが、インフラの発展に伴い、ネットワーク接続型ストレージデバイスとなることが多いです。
WALとデータファイルは、二つの補完的な役割を果たします。
- WALは書き込みを高速化します。 Postgresはコミットを承認する前に、各変更をログに順次追加するため、1枚のディスク上で高速かつ持続性があります。
- データファイルは読み込みを高速化します。 Postgresは各ページの最新バージョンをデータファイルに変換するため、クエリはログを再生することなく行を読み取ることができます。
すべてのデータに一台のマシンでアクセスすることには欠点があります:
- 耐久性はその機械の物理的インフラに直接結びついています。 また、ストレージの事前プロビジョニングや、どれだけワークロードが増加するか予測する必要があり、コスト管理とレジリエンス計画の両方が複雑になります。
- 高可用性や多様な水平スケーリングには、データベース全体の物理的なクローンが必要です。
- もしそのマシンが故障すると、データを失う可能性があります。 RAIDストレージのような技術はこのリスクを軽減しますが、冗長性が増えることでシステム運用コストが大幅に増加します。
レイクベースの建築
レイクベースは同じ責任を保持しますが、それらを2つの独立した層に分けています。
- 標準的なステートレスPostgresを実行する 計算層 です。
- セーフキーパー、ページサーバー、クラウドオブジェクトストレージからなる ストレージ層 です。
モノリスの2つの役割は新しいコンポーネントに直接反映されます。 書き込みを高速化したWALは セーフキーパーとなり、書き込みをスケールします。 読み取りを高速化するデータファイルがページサーバーとなり、読み取り をスケールさせます。
データは単一のマシンではなくクラウドオブジェクトストレージに存在するため、Lakebaseは可用性ゾーンを越えてレプリケートされる、弾力的でスケーラブルな計算と耐久性のある書き込みを提供します。 ストレージを供給する必要はなく、消費したストレージ分だけ支払う必要があり、ディスク不足のような故障モードを計画する必要もありません。
このモデルは性能も向上させます。 Lakebaseは各変更を複数の場所に直接書き込むため、従来のトーンライト保護やブロックアライメントのオーバーヘッドを回避できます。 すべての書き込みがすでに複数の場所に送られているため、高可用性が有効かどうかにかかわらずパフォーマンスは一貫します。
以下の表は、モノリスの各部分をレイクベースの対応部分にマッピングしています。
| 伝統的なモノリス | Lakebase | 役割 |
|---|---|---|
| 1 台のマシン | ステートレス計算 | Postgresクエリエンジンを動かします |
| ローカルWALディスク | セーフキーパー | Durably Recordsのすべてのコミット済み変更 |
| ローカルデータファイル | ページサーバーとオブジェクトストレージ | ページバージョンの具現化と保存 |
コンピューティング レイヤー
コンピュート層はPostgresを実行します。 これは一時的な状態のみを保持しており、Postgresはメモリ内のバッファを共有し、高速ローカルディスクに支えられたローカル計算キャッシュを持っています。 持続的なデータを所有していません。
なぜなら、計算は持続状態を所有しないからです:
- データの移動や損失なしに、置き換え、再起動、自動スケール、ゼロへのスケーリングが可能です。
- ローカルファイルシステムに書き込みする代わりに、WALをストレージ層にストリーミングします。
- 複数のコンピュートインスタンスは同じストレージ層に接続でき、これがLakebaseの リードレプリカ や 高速フェイルオーバー の仕組みです。
ストレージ レイヤー
ストレージ層は耐久性があり、計算とは独立して動作します。 それは三つの要素から成り立っています。
セーフキーパー
セーフキーパーはWALであり、単一の機械から引き出され、非常に利用可能にされています。 PostgresがWALレコードを作成する際、それをセーフキーパーのグループにストリームし、Paxosベースのコンセンサスプロトコルを使って定足数全体でログを複製します。
トランザクションは、単一のマシンがローカル fsyncを完了したときではなく、定足数のセーフキーパーがWALレコードを承認したときにコミットします。 耐久性は1つのディスクからではなく、ノード間のレプリケーションから生まれます。
ページサーバー
ページサーバーはWALから取り出して再構築されたデータファイルです。 ページサーバーはセーフキーパーからのWALストリームを消費し、必要に応じてページバージョンを具現化します。 計算が特定のログシーケンス番号(LSN)でページをリクエストすると、ページサーバーはそれを再構築して返します。
ページサーバーはオブジェクトストレージ上の書き込みキャッシュとして機能します。 非同期でマテリア化されたページをクラウドオブジェクトストレージに永続化し、ページ再構築はトランザクションコミットをブロックしません。
クラウド オブジェクト ストレージ
クラウドオブジェクトストレージは、ストレージ層全体の耐久性の基盤です。 ページサーバーが永続するページデータを保持しています。
Azure 上では、Lakebase はデータを Azure Blob Storage に永続化します。
オブジェクトストレージはホットクエリパスから外れます。 ページサーバーだけが読み込みます。 ストレージ冗長性がどのように機能し、なぜ計算高可用性設定に依存しないのかの詳細については、 ストレージアーキテクチャを参照してください。
書き方の仕組み
書き込みは計算からストレージ層を経由して流れます:
- Postgresは影響を受けたページをメモリ上で修正し、WALレコードを生成します。
- ComputeはWALレコードをセーフキーパーにストリームします。
- セーフキーパーの定足数がレコードを認めると、トランザクションはコミットされ、クライアントは成功を得ます。
- ページサーバーは非同期にWALを適用し、更新されたページをオブジェクトストレージに永続化します。
取引は、セーフキーパーの定足数がWALレコードを手に入れた時点で耐久的です。なぜなら、ログだけでデータを再構築するのに十分だからです。 ページサーバーはコミットパスの外でデータページを再構築・保存するため、書き込みが高速でコミットされた変更を避けられます。
読み物の仕組み
読み取りはキャッシュの階層を最速から遅い順にチェックし、ページが入っている最初の層で停止します。
- バッファプール(メモリ) Postgresは計算RAM上でバッファを共有していました。
- ローカル計算キャッシュ: 計算ノード上のディスクバックアップキャッシュで、計算のメモリに対してサイズが設定されます。
- ページサーバー: キャッシュミス時には、計算がページサーバーからページを要求し、そのサーバーが要求されたLSNで再構成します。
- オブジェクトストレージ: ページサーバーは必要に応じて内部のオブジェクトストレージから読み込みを行います。 クエリは直接オブジェクトストレージに届きません。
このアーキテクチャが可能にすること
ステートレス計算と耐久性ストレージを分離することが、Lakebaseのいくつかの機能を可能にする理由です:
| 特徴 | それが可能にするもの |
|---|---|
| 自動スケーリング | 計算はステートレスであるため、Lakebaseはデータを移動せずにワークロードに応じて計算サイズを拡大・縮小します。 |
| ゼロへのスケール | ストレージが残っている間はコンピュートが完全に一時停止でき、コンピュート再開時にデータは即座に利用可能になります。 |
| 即時分店 | 数秒でデータベースの孤立した書き込み可能なコピーを作成できます。 分岐は共有ストレージに対するコピーオンライトのメタデータ操作であるため、データの重複はありません。 |
| レプリカの読み取り | 複数の計算インスタンスが同じストレージ層から読み取れるため、レプリカはデータコピーを必要とせず数秒で開始できます。 |
| ポイントインタイムクエリ | ストレージ層は履歴を保持するため、コンピュートは過去の時点にアタッチし、その時点で存在したデータベースを読み取ることができ、データを元の位置に戻す必要はなくなります。 |
| 高速フェイルオーバー | フェイルオーバーは、データを移動させることなく、既存のストレージに接続するセカンダリの計算インスタンスをプロモートします。 |
| RPO = 0(コミットされたデータ損失なし) | Lakebaseはコミットされたトランザクションを認識する前に永続的に記録するため、計算が失敗したり再起動したり、ゼロにスケーリングしてもコミットされたデータを失うことはありません。 |
このアーキテクチャがLTAPをサポートする方法
Lakebaseはコミットされたすべての変更をクラウドオブジェクトストレージに永続的に保存するため、同じデータがトランザクションと並行して分析ワークロードを処理し、別個のレプリケーションパイプラインを介さずに提供できます。 これがLake Transactional and Analytical Processing(LTAP)の基盤であり、単一のデータコピーがトランザクションエンジンと分析エンジンの両方をサポートする仕組みです。 LTAPがこのアーキテクチャをどのように構築しているかについては、 LTAPアーキテクチャをご覧ください。
次のステップ
- ストレージアーキテクチャ: ストレージ冗長性がどのように機能し、なぜ計算の高可用性設定に依存しないのかを学びましょう。 ストレージ アーキテクチャを参照してください。
- データベースのブランチ: ブランチがコピーオンライトストレージを使って即時かつ隔離された環境を作り出す様子をご覧ください。 ブランチを参照してください。
- レプリカを読む: 同じストレージ層を共有する読み取り専用の計算インスタンスを追加しましょう。 「 レプリカの読み取り」を参照してください。
- 基本概念: Lakebaseをユニークにしているコンセプトの全セットを振り返ってみましょう。 詳細は コアコンセプトを参照してください。