PostgresデータをS3上のParquetに保存：LTAPアーキテクチャの説明

要約 ほぼ全ての従来のデータベースは、書き込み先行ログ（WAL）とデータファイルを単一のマシンディスクに保存しており、これがデータ損失のリスク、高価なリードレプリカや高可用性クローン、トランザクションを遅延させる分析クエリの根本原因となっています。Lakebaseは、ログとデータファイルを独立したクラウドサービス（SafeKeeperとPageServer）に外部化することでPostgresコンピュートをステートレスにし、実質的な遅延の増加なしに、無制限のストレージ、弾力的なコンピュート、耐久性の高い書き込み、シンプルな高可用性、インスタントブランチングを可能にします。LTAPはさらに一歩進んで、運用データをオープンなカラムナフォーマットで一度だけ保存し、PostgresとLakehouseエンジンの両方が読み取れるようにします。これにより、CDCパイプライン、二重コピー、トランザクションワークロードの減速なしに、トランザクションが書き込んだばかりの最新データで分析を実行できます。HTAPが単一のエンジンで両方のワークロードを統合しようとするのとは異なり、LTAPはストレージレイヤーで統合し、それぞれのジョブに最適なエンジンを維持します。 16年前にUC Berkeleyで博士課程を開始したとき、私の指導教官はこう言いました。「OLTPデータベースは解決済みの問題だ。うまく機能する。分析に集中しなさい。」私たちは、構造化データと非構造化データをはるかに多く収集し、機械学習（現在「AI」と呼んでいるもの）を適用できる初期段階にいました。そこで私はそのアドバイスに従い、Apache Sparkとなった共同創業者たちの研究プロジェクトに参加し、後にDatabricksを設立しました。 Databricksを構築する中で、私たちは様々なデータベースを使用し、OLTPデータベースが解決済みどころか、扱いにくく、スケーリングが難しく、信じられないほど壊れやすいものであることに気づきました。ある時点で私たちは十分に不満を感じ、もし今日OLTPデータベースを設計するとしたらどのようなものになるだろうかと考えました。その問いが、私たちのサーバーレスPostgresデータベースであるLakebaseにつながりました。 この記事では、Lakebase OLTPアーキテクチャを深く掘り下げます。まず、従来のモノリシックデータベースのストレージレイヤーから始めて、問題がどこから生じるかを見ていきます。次に、Lakebaseがそれらの同じピースを独立した外部化されたサービスにどのように再編成するかを見ていきます。最後に、同じアーキテクチャが、CDCや「ミラーリング」の遅延や追加コストなしに、リアルタイムで単一のデータコピー上でトランザクションと分析を実行できるようにするLTAPについて説明します。 モノリスとしてのデータベース 今日世界中で稼働しているデータベースの大多数はモノリスです。これにはMySQL、Postgres、従来のOracleが含まれます。LakebaseはPostgres（偶然ですが、これもBerkeleyで生まれました）上に構築されているため、ここではPostgresを主な例として使用しますが、ほとんどのデータベースは同様に機能します。データベースエンジンとストレージを実行する1台のマシンをプロビジョニングします。これらのデータベースシステムでは、ディスク上で最も重要な2つのものがあります。それは書き込み先行ログ（WAL）とデータファイルです。 トランザクションをコミットするとき、データベースはすぐにデータファイルを書き換えるわけではありません。それは遅いからです。なぜなら、アクセスしている行はファイル内のランダムI/Oを必要とする場所に散らばっているからです。代わりに、データベースはまず、ディスク上のシーケンシャルログであるWALに変更の説明を追記します。トランザクションは、そのログエントリが耐久性を持って書き込まれた瞬間にコミットされたと見なされます。その後、非同期的に、データベースは変更を反映するために実際のデータファイルを更新します。 これを理解する簡単な方法は、WALは書き込みを高速（かつ安全）にするために存在し、データファイルは読み取りを高速にするために存在すると考えることです。ログにより、ランダムI/Oの散らばりの代わりに、単一のシーケンシャルアペンドでトランザクションをコミットできます。データファイルにより、データベースの最初からの履歴全体を再生するのではなく、現在の状態を直接読み取ることでクエリに答えることができます。（この設計のすべての複雑な詳細を理解したい場合は、69ページのARIES論文を読んでください。これはコンピュータサイエンスで最も複雑な論文の1つであることを警告しておきます。） この設計が事実上すべてのデータベースの基盤となっているため、モノリシックアーキテクチャは多くの課題も生み出します。 設定ミスによるデータ損失。コミットは、その背後にあるディスクフラッシュと同じくらい耐久性があります。データベース、オペレーティングシステム、またはストレージレイヤーが、WALへの書き込みが実際に耐久性のあるメディアにフラッシュされる前にクライアントに確認されるように設定されている場合、コミットは電源喪失やカーネルパニックで消えてしまう可能性があります。これらの設定は微妙で、間違いやすく、失敗はしばしばサイレントです。オペレーティングシステムは、フラッシュについて嘘をつくことさえあります！ ノード損失によるデータ損失。フラッシュが正しく設定されていても、WALとデータファイルは1台のマシン上に存在します。そのマシンのディスクが故障すると、その上のデータも失われます。ネットワーク接続ストレージやRAID-1/RAID-10のような冗長化技術は耐久性を向上させるかもしれませんが、この問題を根本的に解決するものではありません。ストレージマウントがダウンすると、データアクセスも失われます。 読み取りのスケーリングには物理的なクローンが必要。1台のボックスがトラフィックを処理できなくなったとき、標準的な解決策はリードレプリカを追加することです。しかし、リードレプリカはデータベース全体の完全な物理コピーであり、プライマリからWALをストリーミングして再生します。1つをプロビジョニングすることは、データセット全体をコピーし、その後ログでキャッチアップすることを意味します。大規模なデータベースの場合、これは迅速な操作ではなく、データベースをダウンさせることさえあります。 高可用性も物理的なクローンが必要です。プライマリの損失を乗り越えるには、少なくとも1つの追加のスタンバイノードを実行する必要があります。これはそれ自体がデータベースの完全な物理コピーであり、WALから同期を保たれています。インフラストラクチャの少なくとも2倍のコストがかかり、スタンバイをオンラインにするのに長い時間がかかり、プライマリがダウンしたときにデータを失わないように同期レプリケーションを設定する必要があります。（実際には、3ノード以上が推奨されることが多いです。） 分析がトランザクショントラフィックと競合する。重い分析クエリは、レイテンシに敏感なトランザクションワークロードと同じハードウェアリソースに対して実行されます。1つの大きなレポートクエリや1つのGDPRクリーンアップは、メインのOLTPクエリを低下させる可能性があります。別のレプリカで分析クエリを実行することもできますが、レプリカのコストを支払い、OLTPストレージの行指向の性質（分析は高性能のためにカラム指向ストレージを必要とします）のために最適なパフォーマンスを得られないままです。 これらの問題のほぼ全ては、モノリシックアーキテクチャの同じ根本原因に起因します。WALとデータファイルが単一のマシン内に保存されていることです。耐久性は、そのマシンのディスクに依存します。スケーリングと可用性には、そのマシンの物理的なクローンが必要です。ワークロードは、そのマシンを共有するため干渉します。 Lakebaseアーキテクチャ もし今日OLTPデータベースを再設計するとしたら、最新のクラウドのコンポーネント、つまり安価で耐久性の高いクラウドオブジェクトストレージと弾力的なコンピュートの組み合わせから始めるでしょう。これがNeonチームが取った道であり、Lakebaseとなったものの基盤です。 中心的な変更は、Postgresコンピュートインスタンスをステートレスにすることです。これは、WALとローカルディスク上のデータファイルを、目的に特化した独立してスケーラブルなサービスに外部化することによって行います。コンピュートレイヤーはステートレスなPostgresエンジンとなり、データを所有しなくなるため、自由に開始、停止、複製できます。これらの2つのストレージサービスがどのように連携して、パフォーマンスを犠牲にすることなく前述の課題を解決できるかを見てみましょう。 書き込みのスケーリング：WALがSafeKeeperになる モノリスでは、書き込みはローカルディスクへのフラッシュによって耐久性のあるものになります。Lakebaseでは、WALはSafeKeeperと呼ばれる分散ストレージサービスに外部化されます。耐久性のためにディスクフラッシュに依存するのではなく、コミットはPaxosベースのネットワークレプリケーションを使用して、SafeKeeperノードのクォーラム全体にログレコードをレプリケートすることによって耐久性のあるものになります。もはやデータを失うディスクはなく、設定ミスによる耐久性保証の静かな侵害もありません。 ここで自然に疑問が生じます。コミットをローカルディスク上のWALからSafeKeeper上のWALに移動すると、追加のネットワークホップにより書き込みレイテンシが増加するのでしょうか？答えはいいえです。任意の