モノリスからLakebase、そしてLTAPへ：ストレージ起点でデータベースを再考する

16年前に私がUC Berkeleyで博士課程を始めたとき、指導教官から「OLTPデータベースはすでに解決済みの問題だ。問題なく動作している。アナリティクスに集中しなさい」と言われました。当時は、構造化データや非構造化データをより多く収集し、機械学習（現在「AI」と呼ばれているもの）を適用できるようになり始めた初期段階でした。そこで私はそのアドバイスに従い、後にApache Sparkとなる研究プロジェクトに共同創業者たちと参加し、その後Databricksを立ち上げました。

Databricksを構築していく中で、世の中のさまざまなデータベースを使い始めましたが、OLTPデータベースは解決済みどころではないことに気づきました。それらは使いにくく、スケールさせるのが難しく、非常に脆弱だったのです。ある時点でフラストレーションが溜まり、「もし今日OLTPデータベースを設計するとしたら、どのようなものになるだろうか」と自問自答しました。その問いから生まれたのが、当社のサーバーレスPostgresデータベースである Lakebaseです。

本ブログ記事では、LakebaseのOLTPアーキテクチャについて深く掘り下げます。まず、従来のモノリシックなデータベースのストレージレイヤーから見ていき、どこに課題があるのかを明らかにします。次に、Lakebaseがそれらと同じコンポーネントを、どのように独立した外部サービスへと再構成しているかを見ていきます。最後に、同じアーキテクチャによって、CDCや「ミラーリング」による遅延や余分なコストをかけることなく、単一のデータコピー上でトランザクションとアナリティクスをリアルタイムに実行できる LTAPについて説明します。

モノリスとしてのデータベース

今日、世界中で稼働しているデータベースの大部分はモノリスです。これには、MySQL、Postgres、従来のOracleなどが含まれます。LakebaseはPostgres（偶然にも、これも UC Berkeleyで誕生しました）をベースに構築されているため、ここではPostgresを主な例として使用しますが、ほとんどのデータベースは同様に動作します。つまり、データベースエンジンとストレージを実行するマシンを1台プロビジョニングするということです。これらのデータベースシステムにおいて、ディスク上で最も重要なものは、 write ahead log（WAL）と データファイルの2つです。

トランザクションをコミットするとき、データベースはすぐにデータファイルを書き換えるわけではありません。操作対象の行がファイル全体に分散しており、ランダムI/Oが必要になるため、それでは処理が遅くなってしまいます。代わりに、データベースはまず変更内容の説明をWAL（ディスク上のシーケンシャルなログ）に追加します。そのログエントリが永続的に書き込まれた時点で、トランザクションはコミットされたとみなされます。その後、非同期でデータベースが実際のデータファイルを更新し、変更を反映します。

これをシンプルに考えると、WALは 書き込みを高速（かつ安全）にするために存在し、データファイルは 読み取りを高速にするために存在します。ログを使用することで、分散したランダムI/Oを行う代わりに、1回のシーケンシャルな追記でトランザクションをコミットできます。データファイルを使用することで、データベースの全履歴を最初から再生することなく、現在の状態を直接読み取ってクエリに応答できます。（この設計の複雑な詳細をすべて理解したい場合は、69ページに及ぶ ARIESの論文をお読みください。これはコンピュータサイエンスにおいて最も複雑な論文の1つですので、覚悟してお読みください。）

この設計は事実上すべてのデータベースの基盤となっていますが、モノリシックなアーキテクチャは多くの課題も生み出します。

設定ミスによるデータ損失。コミットの永続性は、その背後にあるディスクへのフラッシュの確実性に依存します。もしデータベース、オペレーティングシステム、またはストレージレイヤーの設定により、WALへの書き込みが実際に永続メディアにフラッシュされる前にクライアントに完了通知が返されるようになっていると、停電やカーネルパニックの際にコミットが消失する可能性があります。これらの設定は複雑で間違いやすく、障害は気づかないうちに発生することがよくあります。オペレーティングシステムが フラッシュの完了について嘘をつくことさえあります！

ノードの喪失によるデータ損失。フラッシュが正しく設定されていても、WALとデータファイルは1台のマシン上に存在します。そのマシンのディスクが故障すると、その中のデータも失われます。ネットワーク接続ストレージやRAID-1/RAID-10のような冗長化技術によって耐久性は向上しますが、この問題が根本的に解決されるわけではありません。ストレージのマウントが切れると、データへのアクセスもできなくなります。

読み取りのスケールには物理的なクローンが必要。1台のマシンでトラフィックを処理できなくなった場合の標準的な解決策は、リードレプリカを追加することです。しかし、リードレプリカはデータベース全体の完全な物理コピーであり、プライマリからWALをストリーミングして再生します。レプリカをプロビジョニングするということは、データセット全体をコピーした上で、ログの同期を追いつかせることを意味します。大規模なデータベースの場合、これは迅速に行える処理ではなく、データベース自体がダウンする原因になることさえあります。

高可用性の実現にも物理的なクローンが必要。プライマリの喪失に耐えるには、少なくとも1つの追加のスタンバイノードを実行する必要があります。これは、WALから同期されるデータベース自体の完全な物理コピーです。少なくとも2倍のインフラコストがかかり、スタンバイをオンラインにするまでに長い時間がかかります。また、プライマリがダウンしたときにデータを失わないようにするために、同期レプリケーションを設定する必要があります。（実際には、多くの人が 3つ以上のノードを推奨しています。）

アナリティクスがトランザクションのトラフィックと競合する。重い分析クエリは、レイテンシーに敏感なトランザクションワークロードと同じハードウェアリソースに対して実行されます。1つの大規模なレポートクエリや1つのGDPRクリーンアップ処理が、メインのOLTPクエリのパフォーマンスを低下させる可能性があります。分析クエリを別のレプリカで実行することもできますが、そのレプリカのコストを支払う必要があり、さらにOLTPストレージが行指向であるため、最適なパフォーマンスは得られません（高いパフォーマンスを得るには、アナリティクスには列指向ストレージが必要です）。

これらの問題のほぼすべては、モノリシックアーキテクチャの同じ根本原因にたどり着きます。それは、WALとデータファイルが1台のマシン内に保存されていることです。耐久性はそのマシンのディスクに依存します。スケーリングと可用性の確保には、そのマシンを物理的にクローンする必要があります。また、ワークロードがそのマシンを共有するため、互いに干渉し合います。

Lakebaseのアーキテクチャ

もし今日OLTPデータベースを再設計するとしたら、最新のクラウドコンポーネント、つまり安価で耐久性の高いクラウドオブジェクトストレージと、伸縮自在な（エラスティックな）コンピューティングの組み合わせから始めるでしょう。これこそがNeonチームが歩んだ道であり、後のLakebaseの基盤となったものです。

最大のポイントは、Postgresのコンピューティングインスタンスを ステートレスにすることです。ローカルディスク上のWALとデータファイルを、専用に構築された独立してスケーリング可能なサービスへと外部化することで、これを実現します。コンピューティングレイヤーはデータを保持しなくなるため、自由に起動、停止、レプリケーションができるステートレスなPostgresエンジンになります。

これら2つのストレージサービスがどのように連携し、パフォーマンスを犠牲にすることなく前述の課題を解決できるかを見ていきましょう。

書き込みのスケール：WALからSafeKeeperへ

モノリスでは、ローカルディスクにフラッシュすることで書き込みの耐久性を確保します。Lakebaseでは、WALは SafeKeeperと呼ばれる分散ストレージサービスに外部化されます。耐久性をディスクフラッシュに依存する代わりに、Paxosベースのネットワークレプリケーションを使用して、SafeKeeperノードのクォーラム（過半数）全体にログレコードを複製することで、コミットの耐久性を確保します。ディスクの故障によってデータが失われることはもうありません。また、設定ミスによるフラッシュが気づかないうちに耐久性の保証を損なうこともありません。

ここで、「コミットをローカルディスク上のWALからSafeKeeper上のWALに移行すると、余分なネットワークホップが発生して書き込みレイテンシーが増加するのではないか」という疑問が生じるのは当然です。答えは「いいえ」です。耐久性と可用性を重視する本格的なPostgresのデプロイでは、いずれにせよ余分なネットワークホップを必要とする同期レプリケーションを設定する必要があるため、WALをSafeKeeperに外部化しても追加のオーバーヘッドは発生しません。実際、Postgresの内部動作の仕組みにより、SafeKeeperとPageServerを組み合わせることで、 5倍高速な書き込みスループットと2倍低い読み取りレイテンシーを実現できます。

読み取りのスケール：データファイルからPageServerへ

データファイルは、 PageServerと呼ばれる別の分散ストレージサービスに移行します。WALはSafeKeeperからPageServerにストリーミングされ、PageServerはその変更を自身のバージョンのデータに非同期で適用し、低コストのクラウドオブジェクトストレージ（レイク）にページを実体化（マテリアライズ）します。PageServerは、基盤となるオブジェクトストレージのライトスルーキャッシュと考えることができます。

これはモノリスにおける「WALの後にデータファイル」という関係に似ていますが、2つの部分が同じディスク上に存在するのではなく、ネットワークで接続された、個別に拡張可能な別々のサービスに分かれて存在している点が異なります。PageServerにページがリクエストされた際、PageServerにまだ最新バージョンがない場合（変更はPageServerに届く前に、まずSafeKeeperに書き込まれることに注意してください）、PageServerはSafeKeeperからのログを適用して最新の状態を再構築します。

同様の疑問として、「データファイルをローカルディスクからPageServerに移動すると、ネットワークホップが追加されるため、読み取りレイテンシーが増加するのではないか？」というものがあります。実用上のあらゆる目的において、その答えも「ノー」です。このシステムは、積極的な多層キャッシングを通じて、レイテンシーの影響を隔離し、最小限に抑えるように設計されています。ページを取得するために、Postgresはまずノードのローカルメモリにあるバッファプールを検索します。ページが存在しない場合は、ローカルディスクキャッシュを検索します。PageServerにアクセスする必要があるのは、キャッシュミスが発生した場合のみです。コンピュートノードはモノリシックな構成と同一のローカルメモリおよびディスク容量で構成できるため、ローカルキャッシュのヒット率は変わりません。ほとんどの操作において、読み取りレイテンシーはモノリスと区別がつかないほどですが、切り離された実質的に無限のストレージというメリットを得ることができます。

これによって可能になること

WALがSafeKeeperに、データファイルがPageServerに配置されると、モノリスでは困難または不可能だった多くの機能が、このアーキテクチャの自然な結果として実現可能になります。以下は、DatabricksとNeonの両方で、Lakebase製品の一部としてすでに広く利用可能です。

変わらないPostgres。これは本物のPostgresであるため、ワイヤプロトコル、SQL、ドライバー、拡張機能はすべてそのまま動作します。

無制限のストレージ。データは、プロビジョニングされたローカルディスクではなく、クラウドオブジェクトストレージに保存されます。容量の上限に合わせてサーバーのサイズを決定する必要はもうありません。実用上、ストレージは無限です。

サーバーレスで弾力性のあるコンピュート。コンピュートはステートレスであるため、負荷に応じて即座にスケールアップし、アイドル時にはゼロまでスケールダウンできます。トラフィックを待つだけの大型マシンのために無駄なコストを支払う必要はなくなります。

耐久性のある書き込みとデータ損失ゼロ。コミットは、単一のローカルディスクがフラッシュを完了したと報告したときではなく、Paxosを介してSafeKeeperノード間で複製された時点で永続化されます。個々のノードが失われても、コミットされたデータが失われることはありません。

よりシンプルな高可用性。モノリスにおいて、HA（高可用性）とは、2つ目の完全な物理クローンを維持し、2倍のコストを支払い、さらに切り替え時にデータ損失のリスクを負うことを意味していました。ここでは、永続的な状態は、単一のコンピュートインスタンスから独立した、複製されたストレージレイヤーにすでに存在しています。フェイルオーバーは、データベースの別の物理コピーを昇格させ、ログの最後のセグメントが正常に転送されたことを祈るような作業ではなくなります。

即時のブランチ作成、クローン作成、およびリカバリ。これは私のお気に入りです。コードの場合、ブランチの作成は1秒未満で完了する、コードベース全体の完全に隔離されたコピーであり、私たちは意識することなく1日に何度もこれを行っています。モノリシックなデータベースの場合、クローン作成とはデータセット全体を物理的にコピーすることを意味し、これには時間がかかり、コストが高く、本番システムにとってリスクを伴います。データが外部化され、バージョン管理されたストレージレイヤーにある場合、ブランチやクローンの作成は物理的なコピーではなく、メタデータ操作になります。大規模な本番データベースのブランチを数秒で作成し、そのブランチに対して実験やリスクの高いマイグレーションを実行して、不要になったら破棄することができます。特定の時点へのリカバリ（PITR）も同様に機能します。データベースがついに、コードと同じ速さで動くようになります。

コンピュートとストレージの分離自体は新しいものではありません。前回の記事では、これを実現した第2世代のクラウドデータベースについて説明しました。しかし、Lakebaseの鍵は、運用データを汎用オブジェクトストレージにオープンなフォーマットで保存することにあります。これにより、他のエンジンがデータを直接読み取る機会が開かれ、LTAPへとつながります。

LTAP：トランザクションと分析のための単一のコピー

ここまでは、単一の運用データベースを改善すること（耐久性の向上、弾力性の強化、実行コストの削減、ブランチ作成の高速化など）について説明してきました。しかし、データが外部化されたストレージレイヤーに存在すると、さらに興味深いことが可能になります。トランザクションデータベースと分析システムを、2つの異なる世界として扱うのをやめることができるのです。

ここで一度、PageServerに戻ってみましょう。PageServerはすでにWALからの変更ストリームを受け取り、オブジェクトストレージにページを非同期でマテリアライズ（実体化）しています。データがレイクに到達するそのマテリアライズのステップこそが、はるか昔からの課題を解決するのに最適な場所であることがわかります。

Lakebaseを使用している場合でも、オブジェクトストレージ内のデータは依然としてPostgres固有のページフォーマットで書き込まれ、行ごとに配置されていました。このフォーマットはトランザクションには最適ですが、分析には適していません。そのため、これを読み取ろうとする分析エンジンは、読み取りのたびに変換コストを支払うか、より一般的には、パイプラインによって同期されたデータの別コピーに依存する必要がありました。パイプラインは壊れやすく、2つのデータコピーは、権限の不一致によるガバナンスの悪夢を引き起こす可能性があります。

私たちは最近、データの2重コピー問題を解消するLake Transactional/Analytical Processing（LTAP）を発表しました。主なアイデアは、エンジンレイヤーではなく、ストレージレイヤーで2つの世界を統合することです。トランザクションと分析の両方に優れた単一のエンジンを構築しようとするのではありません。それぞれのタスクに最適なツールを維持します。トランザクションには完全なACIDセマンティクスを備えたPostgresを、分析にはLakehouseエンジンを使用します。変わるのは、その下にあるデータです。2つのフォーマットによる2つのコピーの代わりに、Parquetとして保存されたDeltaやIcebergのようなオープンな列指向フォーマットの、永続的な1つのコピーが存在し、双方がそれを読み取ります（パフォーマンス向上のためのさまざまなレベルのキャッシュも備えています）。

列指向形式でのマテリアライズ

注意：このセクションを理解するには、他のセクションよりもPostgresの内部知識が必要になります。

PageServerがページをオブジェクトストレージにマテリアライズする際、データがレイクに到達すると同時に、Postgresのデータを行フォーマットからParquetの列指向レイアウトにトランスコードします。すべての値の正確なPostgres表現をビット単位まで保持するため、Postgres互換のエンジンであれば、情報を失うことなく再解釈できます。これは、CDC（変更データキャプチャ）ベースのアプローチとは異なります。CDCは論理的な変更イベントのストリームを外部のスキーマに送信し、Postgresの物理的およびトランザクション的なセマンティクスを残しませんが、ここではそれらを保持します。高度に最適化されたエンジンにより、PageServerレイヤーの余剰CPUが、データをオブジェクトストレージにマテリアライズする一環として行から列指向へのトランスコードを行うため、トランザクションを処理するPostgresコンピュートに負荷をかけることはありません。 トランザクションの読み取りを効率的に処理するために、PageServerは依然として従来の行ベースのページをローカルキャッシュにマテリアライズしますが、これは厳密にはパフォーマンス向上のためのキャッシュです。基盤となる永続ストレージはレイク内で統合されたままであり、双方向からアクセス可能です。

列指向形式でPostgresのセマンティクスを保持することは、型システムとマルチバージョニングの2つの要素に集約されます。

型システム。Postgresの型の大部分は、ネイティブのParquet型に直接マッピングされます。ロスレスな列指向の対応物がない少数の値（例：NaNや±Infinity、十進数の範囲を超えるNUMERIC、特殊な型や拡張型など）は、ドロップされたり強制変換されたりしません。これらは、同じテーブル内の構造化されたオーバーフローフィールドで元の列と並行して保持され、それらの値の標準的なPostgresテキストを保持します。そのフィールドは、どのエンジンからでも直接クエリ可能であり、戻る際に元のPostgresバイトを正確に再構築するのに十分な情報を備えています。

マルチバージョニング。Postgresでは、トランザクションが監視できる可能性のあるすべての行バージョンが保持されます。これこそが、スナップショット分離とポイントインタイムリカバリ（PITR）を可能にしている理由です。対照的に、オープンテーブルフォーマットは、中間の行バージョンなしでテーブル全体の整合性のあるスナップショットを公開します。私たちは、耐久性と可視性を分離することで、両方のアプローチのメリットを享受しています。列指向にマテリアライズされたすべての行は、物理ヒープアドレス（ブロックとオフセット）を保持しているため、ヒープページは完全に再構築可能です。従来のPostgresヒープページは、ポイント読み取りを高速化するキャッシュとなり、永続的な信頼できる情報源（Source of Truth）はオブジェクトストレージ内の列指向ファイルに存在します。Postgresのインデックスは列にトランスコードされず、そのホットキャッシュ層から提供および再構築されます。中間の行バージョンは、PostgresのMVCCセマンティクスとPITRを維持するために保持されますが、IcebergやDeltaのリーダーからは見えず、最終的にはガベージコレクションされます。その結果、分析エンジンはクリーンでスナップショット整合性のあるテーブルを参照でき、その下にあるPostgresシステムは、タイムトラベル可能な完全なバージョン履歴を維持できます。

嬉しい副次効果もあります。列指向（カラムナ）データは行データよりも圧縮率が非常に高く、多くの場合10倍以上になります。そのため、列指向ストレージに変換することで、キャッシュ層とオブジェクトストアの間でネットワークを通過するデータ量が大幅に削減され、無視できるレベルになることも珍しくありません。分析を高速化するフォーマットは、ストレージパスの低コスト化にもつながります。私たちはこの利点を活かし、LTAPの移行ロールアウト段階におけるデータ検証のために、オブジェクトストアに行フォーマットと列指向フォーマットの両方を二重書き込みしています（ストレージの変更には細心の注意を払いたいためです）。

Postgresに影響を与えずに最新データを読み込む

大きな課題の1つは、データの鮮度（フレッシュネス）です。分析処理がレイク内のコピーからデータを読み取る場合、直前にコミットされ、オブジェクトストアにまだマテリアライズ（実体化）されていないデータをどのようにして確認するのでしょうか？これこそが、「分析エンジンをレイクに向ければいいだけ」という設計のほとんどを頓挫させる疑問であり、LTAPがこれにどう答えるかを詳しく見ていく価値があります。

分析クエリが開始されると（例えば、発表されたばかりの Lakehouse//RT製品などから）、まずPostgresに対して現在のLSN（読み取り開始時点のWAL内の正確な位置を示すログシーケンス番号）を問い合わせます。これは負荷の低いメタデータ検索です。そのLSNを使用して、分析エンジンは、その時点までにすでにマテリアライズされているすべてのデータを含む、データの大部分をオブジェクトストレージから直接読み取ります。残るは、レイクにまだマテリアライズされていないごく最近の小さな変更セットのみであり、これらはPageServerから取得してマージされます。

その結果、そのLSN時点における一貫した、完全に最新のデータ読み取りが可能になります。処理のほぼすべてが、安価でスケーラブルなオブジェクトストレージ上で行われます。そして極めて重要なことに、Postgres自体は単一の数値（LSN）を返すだけで、分析の読み取りトラフィックを一切処理しません。誰かが大規模な分析クエリを実行したからといって、トランザクションのワークロードが低下することはありません。

ここで言及しておくべき実用的な最適化が1つあります。わずか数行しか保持していない非常に小さなテーブルについては、わざわざ列指向フォーマットに変換したり、関連するIcebergメタデータを作成したりはしません。管理コストが削減効果を上回ってしまいますし、それほど小さなテーブルであれば、どのように配置されていても分析パフォーマンスに測定可能な影響を与えることはないからです。これらのテーブルも引き続き存在し、単一コピーの一部としてクエリ可能です。

すべてのテーブルを自動的に

この問題が非常に重要であるため、市場ではOLTPと分析の統合について多くの議論がなされてきました。古典的なアプローチはCDCであり、これはOLTPストレージから別の分析ストレージ層にデータを効果的にレプリケート（複製）するものです。「ミラーリング」や「ゼロCDC」、「ゼロETL」といった別の名前で耳にしたことがあるかもしれません。

CDCや「ミラーリング」では、データレプリケーションのパイプラインにコストがかかるため、すべてのテーブルに適用することはできません。対象とするテーブルを明示的に選択する必要があり、通常、このレプリケーションには遅延が伴います。

LTAPには、オプトイン（選択）するような設定はありません。存在するテーブルは、その仕組み上、すでにレイク内にあり、クエリ可能です。レプリケーションが存在しないため、レプリケートまたはミラーリングされたテーブルのリストもありません。オープンフォーマットによるガバナンスの効いた単一のデータコピーが存在するだけで、構築、監視、修復が必要なETLパイプラインは（お客様にとっても、私たちにとっても）存在しません。トランザクションエンジンと分析エンジンはそれぞれ独立してスケールし、独自のワークロードに合わせてサイズ調整されます。また、データの移動や2つ目のコピーが存在しないため、2つのビューが乖離することは決してありません。分析は常に、アプリケーションが書き込んだばかりの同じデータを読み取ります。

LTAPがどのように機能するかについては、Data and AI Summitのこちらの デモをご覧ください。

HTAPについてはどうでしょうか？

この分野に詳しい方なら、LTAPがHTAP（ハイブリッドトランザクション/分析処理：hybrid transactional/analytical processing）を意識したネーミングであることにすでにお気づきでしょう。HTAPはデータベースエンジニアリングの「聖杯（究極の目標）」であり、トランザクションと分析の両方のワークロードを実行できる単一のエンジンの構築に焦点を当ててきました。

実際には、広く普及しているHTAPデータベースシステムは存在しません。なぜでしょうか？私の考えでは、HTAPシステムは以下の1つ以上の問題に悩まされているからです。

不完全な機能セット。単一のタスクを実行する新しい独自のエンジンを一から設計することは、数年にわたる投資となります。複数のエンジンの役割を果たせる単一のエンジンを構築しようとすると、成熟したデータベースでエンジニアが当然と考えている機能セットに到達するために必要な投資が膨れ上がります。これらのシステムは、広範なSQLサポート（外部キーのサポートなど）からクエリオプティマイザの成熟度に至るまで、当然備わっていると思われる機能で遅れをとることがよくあります。

エコシステムがない。PostgresとSparkはそれぞれ、ドライバー、拡張機能、ツール、そして数十年にわたり蓄積された運用知識という広大なエコシステムの中央に位置しています。まったく新しいエンジンは、そのすべてから外れた状態でスタートすることになり、エンジンがどれほど有用であるかは、チームが実際に構築できるエコシステムにかかっています。

パフォーマンスの隔離がない。多くのHTAPシステムは、同じハードウェア上でトランザクションと分析を実行するため、2つのワークロードが同じCPUとメモリを奪い合うことになります。これは、モノリスで最初に発生したのと同じ失敗であり、分析クエリがトランザクションワークロードのリソースを枯渇させてしまいます。

これら3つの問題はすべて、2つのワークロードを1つのエンジンに統合するという同じ決定に起因しています。LakebaseとLTAPは、ストレージ層で統合する一方で、異なるワークロードに対して異なるコンピュートエンジンを使用することでこれらの課題を回避し、完全なパフォーマンス隔離を実現しながら、それぞれの全機能セットとエコシステムサポートを活用します。

おわりに

昨年、私たちが最初にLakebaseアーキテクチャを提案したとき、Neonプラットフォームでの経験に基づき、それが無制限のストレージ、エラスティックなコンピュート、耐久性のある書き込み、よりシンプルなHA、そして即時のブランチングを可能にすることをすでに確信していました。WALがSafeKeeperに、データファイルがPageServerに配置されれば、これらはほぼ自動的に実現されました。

LTAPのアイデアはその後、NeonとDatabricksのチームが協力し、最新のトランザクションデータに対して分析を実行するという数十年来の課題を解決するために生まれました。今後数か月かけてLTAPの細かな問題を解消し、ロールアウトを進めることで、すべてのLakebaseテーブルが、Lakehouseデータと同等の高いパフォーマンスで分析に利用できるようになります。

私が最も期待しているのは、この先に待ち受けている未来です。LTAPは自然な次のステップですが、同じ設計によって、他の高負荷なメンテナンス操作とコアとなるトランザクションワークロードを分離するための、多くの最適化の機会も開かれます。私たちは、このアーキテクチャが何をもたらすかを探求し始めたばかりであり、今後の展開を皆様にお伝えできることを楽しみにしています。

謝辞：このブログで議論したすべてを現実のものにし、ブログをレビューし、技術的な詳細について正確さを保ってくれたLakebaseチームに感謝いたします。

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