ライクベース：OLTP の再設計と LTAP アーキテクチャへようこそ

16 年前、カリフォルニア大学バークレー校での指導者から「OLTP データベースの問題は既に解決済み」「今後はアナリティクスに集中せよ」と言われました。 当時、大量データを機械学習に応用する時代の開拓期であり、その助言に従い Apache Spark のリサーチと Databricks の立ち上げに参加しました。

しかし、実際に Databricks を構築していく中で「OLTP データベースが『解決済み』ではなかった」ことに気づきました。

• 操作しにくい
• スケール性に乏しい
• 極めて脆弱である

この課題に直面し、「もし現代に OLTP データベースを再設計したら？」と問いかけ、サーバーレスの Postgres データベースである Lakebase が誕生しました。

今回は Lakebase のアーキテクチャについて詳しく解説します。従来の「モノリシック」なデータベースからどのような課題が生じているか、そして Lakebase がそれらをどのように解決しているかを探ります。最終的には、トランザクションとアナリティクスが単一のデータコピー上で実行可能な LTAP アーキテクチャへと辿り着きます。

---

モノリシックなデータベースにおける現状と課題

世界中で動作しているデータベースの過半数（MySQL、Postgres、Oracle など）は「モノリシック（一体型）」アーキテクチャを持っています。これらは基本的に Postgres の仕組みに近く、以下の構造から構成されています：

• データベースエンジンとストレージが単一のマシンのプロビジョニングで動作する

基本設計：WAL とデータファイル

ディスク上の重要な要素は以下の 2 つです：

1. Write Ahead Log (WAL)
2. データファイル

トランザクションのコミット時の動作プロセスは以下の通りです：

• まず、変更の詳細をシーケンシャルな WAL に追加します（即座にデータファイルを書き換えず、ランダム I/O を避ける）。
• WAL がディスクに書き込まれた瞬間にコミットとみなされます。
• その後、非同期で実際のデータファイルを反映させます。

WAL（書き込みの高速化・安全性） と データファイル（読み取りの高速化） という二重の仕組みが複雑さの源になっています（詳細は ARIES paper 参照）。

この設計には、以下の重大な課題があります：

❌ モノリシックアーキテクチャの課題

• 誤設定によるデータ喪失
  • データベースの設定によっては、WAL の書き込みがディスクにフラッシュされる前にクライアントから ACK が返されてしまい、停電などでデータが消えてしまうリスクがあります。
  • オペレーティングシステム自体がフラッシュ状態について嘘をつきやすいです。
• ノード喪失によるデータ喪失
  • WAL とデータファイルは 1 マシン内に存在するため、ディスク故障で両方が消失します。
  • RAID やネットワークストレージで耐久性は上がりますが、根本的な解決ではありません。
• 読み取りのスケーリングが物理的に困難
  • リードレプリカを追加する際、全データセットのコピーと WAL の追従が必要です。大規模な場合、データベース停止を伴います。
• 高可用性（HA）も物理複製が必要
  • 冗長化のためには追加のスタンバイノード（完全な物理コピー）を維持し、最低でも 2 倍のインフラコストがかかります。
• アナリティクスとトランザクションの競合
  • 同じハードウェアリソースを使い、重負荷のアナリティクスクエリが OLTP の性能を低下させます。
  • 別のレプリカを使うとコストが増え、さらにストレージの最適化も難しいです。

まとめ： これらの課題はすべて、「WAL とデータファイルを単一のマシン内に格納している」 ことによるものです。

---

Lakebase アーキテクチャ：計算とストレージの分離

Lakebase は現代クラウドのコンポーネントを利用し、Postgres コミュニティスタンシスを ステートレス に再設計しました。

核心的な動き

• ローカルディスク上の WAL とデータファイルを外部化します。
• それらを独立してスケーラブルなサービスへと移行させます。
• 計算層はデータを所有する必要がなくなり、起動・停止・レプリケーション可能なエンジンになります。

以下の 2 つのストレージサービスによって課題を解決します：

1. 書き込みのスケーリング：WAL は SafeKeeper へ

モノリシックでは WAL がローカルディスクへのフラッシュに依存していましたが、Lakebase では SafeKeeper という分散ストレージサービスを使います。

• 仕組み： Paxos ベースのネットワークレプリケーションで SafeKeeper ノード間へログを複製し、コミットの永続性を確保します。
• 効果： ディスクフラッシュに依存せず、故障するディスクがもはや存在しません。
• パフォーマンス： 追加のネットワークオーバーヘッドが発生せず、書き込みスループットは 5 倍増、読み取りレイテンシは半分（2/1） に改善します。（同期レプリケーションが必要だったため、WAL 外部化も同様のネットワーク処理となります。）

2. リードのスケーリング：データファイルは PageServer へ

データファイルは PageServer という分散ストレージサービスに移動し、非同期で変更を適用してクラウドオブジェクトストレージ（湖/Lake）にマテリアライズします。

• 仕組み： PageServer はライトスルーキャッシュとして機能し、要求されたページがない場合、SafeKeeper のログを読み込み最新状態を再構築します。
• 効果： 読み取りレイテンシは増加しません。Postgres ノードはまずローカルメモリとディスクのキャッシュを検索するため、キャッシュミス時の PageServer アクセスだけが遅延の要因ですが、実用的な観点ではモノリシックシステムとの見分けがつかないレベルです。
• 恩恵： 解耦されたアーキテクチャにより、仮想無限のストレージを利用できます。

---

これがもたらす解放：機能の新境地

WAL とデータファイルの外部化により、以下のような新しい能力が自然に実現します：

• 依然として Postgres
  • 真の Postgres です。ワイヤプロトコル、SQL、ドライバ、拡張機能はすべてそのまま動作します。
• 無限のストレージ
  • データはローカルディスクではなく、クラウドオブジェクトストレージ上に存在するため、容量天井を超えずに拡張可能です。
• サーバーレスで弾力的なコンピューティング
  • ステートレスであるため、負荷に合わせて即座にスケーリングでき、アイドル時はゼロコストで停止できます。
• 永続的な書き込みとデータ損失ゼロ
  • コミットは「ディスクフラッシュ完了時」ではなく、Paxos によるレプリケーション完了時点で永続的です。個々のノードが死んでもデータは消えません。
• シンプルで高可用性（HA）
  • HA を保つための物理複製コストや、スイッチオーバー時のリスクがありません。ステートレスなストレージ層上でのフェイルオーバーのみです。
• 瞬間的なブランチング、クローニング、復旧
  • 大規模データベースの物理コピーを数秒で作成でき、実験やマイグレーションを行ってから廃棄できます。データベースもソフトウェア開発のように「コミット」スピードで操作可能です。

⚡ LTAP への道筋

Lakebase のキーは、機能的データを オープンフォーマットの商用オブジェクトストレージ に格納することにあります。これにより、他のエンジンが直接読み取れるようになり、以下の LTAP アーキテクチャが可能になります。

---

LTAP：トランザクションとアナリティクス用の一本のコピー

これまでのアーキテクチャ変更は「運用データベースを良くする」ためのものですが、データを外部ストレージに置くことでさらに革命的なことが可能になります。トランザクション系（OLTP）とアナリティクス系（Analytic） を 2 つの別々の世界として扱わなくてよくなります。

LTAP の核となる概念

これまでの課題は「データのコピーがある」ことでした：

1. トランザクション用データベースにあり、読み取るには変換が必要（コンバージョンコスト）。
2. アナリティクス用に別途 ETL や CDC で同期されたコピーを作らなければならず、そのパイプラインが脆弱です。

LTAP (Lake Transactional/Analytical Processing) はこの問題を解決します：

• ストレージ層での統合： エンジンを変更するのではなく、下位のデータ形式を変えます。
• 最適ツールの併用： トランザクションには Postgres（ACID）、アナリティクスには Lakehouse エンジンを使い分けながら、単一のデータコピーで動作します。

列指向形式でのマテリアライゼーション

PageServer がデータをオブジェクトストレージに保存する際、行形式を Parquet の列指向レイアウトへトランスコードしています。

• Postgres 互換性の保持： 元のビット単位の正確な表現を保持するため、Postgres エンジンも情報損失なく読み込めます。
• CDC との違い： CDC は物理的/トランザクションセマンティクスを捨てていますが、LTAP ではそれを保持しています。

タイポシステムとマルチバージョン管理

列指向形式で Postgres セマンティクスを実現するには以下の要素が必要です：

1. タイポシステム
   • Postgres の大半のタイプが Parquet に直接マッピングします。
   • 浮動小数点や特殊な数値はそのまま保持され、構造化されたオーバーフローフィールドに格納されます。
2. マルチバージョン管理
   • Postgres 側： スナップショット分離と時点での復旧（PITR）のための全行バージョンを保持します。
   • Lakehouse エンジン側： 中間の行バージョンは不要なため、クリーンでスナップショット一貫性のテーブルしか見ません。
   • 物理的なヒープアドレスを追跡し、Postgres のキャッシュ加速とオブジェクトストレージの両方で動作します。

追加メリット：

• 圧縮率の向上： 列指向データは行指向データの 10 倍以上圧縮可能です。これによりキャッシュ層とストア間の帯域幅を節約できます。

ポストGRES に影響を与えず最新データをリードする（鮮度）

アナリティクスが「Lake への単一指向」として遅れているデータを取得することは避け、リアルタイムな最新データを読み取る仕組みです：

1. アナリティクスクエリが開始され、Postgres に現在の LSN (Log Sequence Number) を要求します。
2. その LSN を用いて、すでにマテリアライズされたデータを直接オブジェクトストレージから読み取ります。
3. Lake へマテリアライズされていないごく最近の変更分だけを PageServer からフェッチし、マージして一貫性を確保します。

• 結果： Postgres は単一の数字（LSN）を返すだけであり、重いクエリを処理しません。トランザクションワークロードは影響を受けません。
• 小さなテーブルの場合： 変換コストが合わないため、行形式のまま使用しても性能劣化はありません。

全テーブルに対して自動的に

従来の「ミラーリング」や「CDC（ゼロ ETL）」では、どのテーブルを複製するか選定する必要があり、遅延やコストが発生しました。

LTAP はその必要がありません：

• Opt-in な複製なし： 構築上すでにデータは Lake 上にあり、クエリ可能です。
• 単一コピー： 複製されたリストもありません。
• ゼロドリフト： アプリケーションが直接書き込んだ同じデータを、アナリティクスとトランザクションの両方が常に読み取ります。

---

HTAP とは何か？

業界では「HTAP（ハイブリッドトランザクション/アナリティクス処理）」という言葉がよく使われます。これは単一のエンジンで OLTP とアナリティクスを両立させることを目指しますが、現時点では広く成功しているシステムはありません。なぜでしょうか？

既存の HTAP システムの弱点

1. 機能セットの不備： 単一のエンジンに複数の役割を持たせるため、特定の機能（例：外部キー、クエリオプティマイザ）が遅れがちになります。
2. エコシステムの不在： Postgres や Spark のような成熟したエコシステム（ドライバ、ツール、知識）から独立しており、有用性が制限されます。
3. パフォーマンス隔離の不在： 同じハードウェア上で動作するため、アナリティクスクエリがトランザクションワークロードを奪ってしまいます（ノイズ）。

Lakebase と LTAP の解決策

Lakebase と LTAP は、これらを以下のように回避しています：

• 計算エンジンの多様化： ワークロードに合わせて最適なエンジンを選びます。
• ストレージ層での統合： データを一つにしつつ、各ワークロードが全機能とエコシステムを活用可能にします。
• 完全なパフォーマンス隔離： 物理的なリソース争いを排除し、両方のワークロードが最大効率で動きます。

---

結びの想い

Lakebase アーキテクチャは、無制限なストレージ、弾力的なコンピューティング、永続的な書き込み、シンプルな HA、瞬間的なブランチング を実現し、OLTP の未来を切り開きました。

さらに進化して生まれた LTAP は、トランザクション最新データに対するアナリティクス実行という長年の課題を解決しました。

• 全テーブルが Lakehouse データと同じ高パフォーマンスで利用可能になります。
• 自然な次のステップでありながら、さらなるコアワークロードの分離や最適化の機会を開きます。

私たちは LTAP の設計を探求し始め、何が次に来るかも共有していく予定です。Lakebase チームおよびレビューにご協力いただいた皆さんに感謝いたします。