分散 SQL データベース開発における 6 つの技術的課題

今年 2 月に YugaByte DB の 3 年間の開発フェーズが終了しました。これまでのところ、非常に刺激的な道のりではありますが、技術的な課題がなかったわけではありません。手元にあるものよりも良い解決策を見つけるために、時には白紙に戻ったり、学術研究を精査したりしなければならないこともあります。この記事では、オープンソースでクラウドネイティブな高性能分散 SQL データベースを構築する過程で解決しなければならなかった、最も困難なアーキテクチャ上の問題のいくつかについて概説します。

さて、まずは最も簡単なものから最も難しいものへと進めていきましょう。

1. アーキテクチャ: Amazon Aurora か Google Spanner か?

私たちが早い段階で下した決定の 1 つは、YugaByte DB アーキテクチャのインスピレーションとして使用できるデータベースを見つけることでした。私たちは、Amazon Aurora と Google Spanner という 2 つのシステムを注意深く追跡しています。

Amazon Aurora は、高可用性を提供する SQL データベースです。 MySQL や PostgreSQL などの一般的な RDBMS データベースと互換性があるため、さまざまなアプリケーションを簡単に開始して実行できます。 Amazon Aurora は、AWS 史上最も急速に成長しているサービスの 1 つでもあります。

MySQL および PostgreSQL と互換性のあるサービスである Amazon Aurora は、AWS 史上最も急速に成長しているサービスです。

Amazon Aurora にはスケーラブルなデータ ストレージ レイヤーがありますが、クエリ レイヤーはありません。 Amazon Aurora で発見された主なスケーラビリティの制限は次のとおりです。

• 書き込みは水平方向にスケーラブルではありません。書き込みスループットを拡張する唯一の方法は、すべての書き込みを処理するノード (マスター ノードと呼ばれる) を垂直に拡張することです。このスケーリング スキームには限界があるため、データベースが処理できる書き込み IOPS の数には固有の制限があります。
• 書き込みはグローバルに一貫していません。最新のクラウドネイティブ アプリケーションの多くは本質的にグローバルであり、基盤となるデータベースを複数のリージョンに展開する必要があります。ただし、Aurora はマルチマスター デプロイメントのみをサポートしており、競合が発生した場合は最後のライター (最新のタイムスタンプを持つ) が優先されます。これにより矛盾が生じる可能性があります。
• 読み取りスケーリングは、一貫性を犠牲にするスレーブレプリカを使用することで実現されます。読み取りをスケーリングするには、アプリケーションはスレーブ ノードに接続して読み取りを実行する必要があります。これらのスレーブを使用して読み取りを実装する場合、アプリケーションは一貫性のセマンティクスが低下し、接続エンドポイントが別々になるという問題に直面します。これにより、アプリケーション アーキテクチャが非常に複雑になります。

さらに、Google Spanner は、大規模にスケーラブルで地理的に分散されたアプリケーション向けに構築された、水平方向にスケーラブルな SQL データベースです。

Cloud Spanner は、クラウド向けに構築された唯一のエンタープライズ グレードでグローバルに分散され、強力な一貫性を備えたデータベース サービスであり、リレーショナル データベース構造の利点と非リレーショナルの水平スケーリングを組み合わせるように特別に設計されています。

つまり、Spanner は読み取りと書き込みをシームレスにスケーリングし、グローバルな一貫性を必要とする地理的に分散したアプリケーションをサポートし、正確性を犠牲にすることなく複数のノードから読み取りを実行できます。

ただし、開発者が RDBMS データベースに期待する一般的な機能セットの多くは省略されています。たとえば、外部キー制約やトリガーがサポートされていないという事実は、Google Spanner のドキュメントで強調されています。

私たちはハイブリッドアプローチを採用することにしました。

• YugaByte DB のコア ストレージ アーキテクチャは、水平スケーラビリティと地理的に分散されたアプリケーション向けに構築された Google Spanner にヒントを得ています。
• YugaByte DB は、Amazon Aurora に似た PostgreSQL 互換のクエリレイヤーを保持しており、豊富な機能セットをサポートし、幅広いユースケースをサポートできます。

2. SQL プロトコル: PostgreSQL または MySQL?

広く採用されている SQL 方言を標準化したいと考えています。また、オープンソースであり、データベースを中心に成熟したエコシステムを持つことも望んでいました。トレードオフの自然な選択は PostgreSQL と MySQL でしょうか?

次の理由により、MySQL ではなく PostgreSQL を選択しました。

• PostgreSQL は、YugaByte DB のオープン ソースの精神に沿った、より寛容なライセンスを持っています。
• PostgreSQL は、他の SQL データベースと比較して、ここ数年で人気が急上昇しており、これは間違いなくプラスに働いています。

DB-Engines ランキング サイトで現在トップ 10 にランクされている 5 つの SQL データベースのうち、2014 年以降人気が高まっているのは PostgreSQL のみで、他のデータベースは停滞しているか人気が低下しています。

さらに、多くのアプリケーションにとって、PostgreSQL は Oracle の優れた代替手段となります。組織が PostgreSQL に惹かれる理由は、オープンソースであり、ベンダー中立であり (MySQL は Oracle が所有)、熱心な開発者コミュニティがあり、ベンダーのエコシステムが活発で、機能セットが強力であり、20 年を超える厳しい使用によって鍛え上げられた成熟したコード ベースを備えているためです。

3. 分散トランザクション: Google Spanner か Percolator か?

分散トランザクションをどのように設計すべきかについては、Google Spanner と Percolator を参考にしました。

要約すると、Google Percolator は高いスループットを提供しますが、単一のタイムスタンプを使用します。このアプローチは本質的にスケーラブルではなく、単一のデータ センター、リアルタイム分析 (HTAP と呼ばれる) 指向のアプリケーションにのみ適しており、OLTP アプリケーションには適していません。一方、Google Spanner の分散型時間追跡アプローチは、地理的に分散された OLTP アプリケーションと単一データセンターの HTAP アプリケーションの両方に適したソリューションです。

Google Spanner は Google Percolator を基に構築されており、水平方向のスケーラビリティと地理的に分散されたユースケースのために、広告バックエンドで手動で分割された MySQL デプロイメントを置き換えるために使用されます。ただし、Google Spanner は、その真の分散性とクロック スキュー追跡の必要性を考えると、構築が桁違いに困難です。

このトピックの詳細については、Percolator と Spanner のトレードオフについての詳細をお読みください。

Google Spanner アプローチを採用することにしました。その理由は、次の点をサポートしているためです。

• 水平スケーラビリティの向上
• パフォーマンスが向上した、可用性の高いマルチリージョン展開。

私たちは、ほとんどの最新のクラウド アプリケーションにはこれら両方の機能が必要であると確信しています。実際、GDPR などのコンプライアンス要件や、合計 100 のリージョンを提供するパブリック クラウドにより、これはすでに現実のものとなっています。

4. Raft は地理的に分散されたワークロードに適していますか?

Raft と Paxos はよく知られた分散コンセンサス アルゴリズムであり、正式に安全性が証明されています。 Spanner は Paxos を使用しますが、次の理由から Raft を選択しました。

• 開発者や運用チームにとって、Raft は Paxos よりも理解しやすいです。
• メンバーシップを動的に変更する機能を提供します。これは非常に重要です (例: パフォーマンスに影響を与えずにマシン タイプを変更する)。 (注: Raft と Paxos の主な違いは、Raft の候補は任意のサーバー ノードにすることができ、候補を指定する必要がないことです。そうでない場合、すべての候補がダウンしたらどうなるでしょうか。一部の TCC 分散トランザクションのトランザクション コーディネーターと同様に、単一ポイントのリスクがあります。)

ただし、線形化可能な読み取りを保証するために、Raft では、読み取りクエリを受信する各 *** が、読み取りクエリを実際に処理する前に、まず Raft グループ内の大多数のノードにハートビート メッセージを伝播する必要があります。場合によっては、読み取りパフォーマンスが著しく低下する可能性があります。このような状況の一例として、地理的に分散された展開が挙げられます。この展開では、一時的なネットワーク パーティションなどのイベントが発生した場合、ラウンド トリップによってレイテンシが大幅に増加し、失敗するクエリの数が増える可能性があります。

Raft の高レイテンシを回避するために、安全なリース メカニズムを実装しました。これにより、Raft の線形化特性を維持しながら、ラウンドトリップなしで安全なサービスを実装できます。さらに、クロックのスキューを許容するために、リアルタイム クロックではなく単調クロックを使用します。

5. ソフトウェア定義の原子時計を構築できますか?

分散データベースである YugaByte DB は、障害が発生した場合でも、複数のノードにわたるマルチキー ACID トランザクション (スナップショットおよびシリアル化可能な分離レベル) をサポートします。これには、ノード間で時間を同期できるクロックが必要です。

Google Spanner は、厳密な誤差制限を備えた、可用性の高いグローバル同期クロックの例である TrueTime を使用します。ただし、多くの展開では、そのようなクロックは利用できません。

物理クロック（またはウォールクロック）はノード間で完全に同期することはできません。したがって、ノード間でイベントを順序付ける（因果関係を確立する）ことはできません。 Lamport クロックやベクトル クロックなどの論理クロックは、中央のタイムスタンプ機関がない限り物理時間を追跡しないため、スケーラビリティのボトルネックになります。

私たちのソリューションであるハイブリッド論理クロック (HLC) は、NTP を使用して大まかに同期された物理クロックと因果関係を追跡する Lamport クロックを組み合わせることでこの問題を解決します。

YugaByte DB は、ユーザーが指定した最大クロック スキュー キャップを持つ、可用性の高いクラスター全体のクロックとして HLC を使用します。 HLC 値は、Raft グループ内の更新を相関させる方法として、また MVCC 読み取りポイントとしても使用されます。結果は、Jepsen テストに示されているように、ACID 準拠の分散データベースになります。

6. PostgreSQL クエリ レイヤーを書き直すか、再利用しますか?

*** しかし、同じくらい重要なのは、PostgreSQL クエリ レイヤーを書き直すか、再利用するかを決定する必要があったことです。

私たちの最初の決断

YugaByte データベース クエリ レイヤーは、スケーラビリティを考慮して設計されています。このクエリ レイヤー フレームワークでは、API サーバーを C++ で書き直すことですでに 2 つの API (YCQL と YEDIS) を構築していたため、最初に PostgreSQL API を書き直す方が簡単で自然に思えました。

最終決定

私たちはこの道を約 5 か月間歩みましたが、それが理想的な道ではないことに気付きました。成熟した完全なデータベースである PostgreSQL と比較すると、他の API ははるかにシンプルです。その後、私たちはすべての作業をやり直し、白紙に戻って、PostgreSQL のクエリ レイヤー コードを最初からやり直しました。最初は苦痛でしたが、振り返ってみると、これははるかに優れた戦略でした。

このアプローチにも独自の課題があります。私たちの計画は、まず PostgreSQL システム テーブルを DocDB (YugaByte DB のストレージ レイヤー) に移動し、最初はいくつかのデータ型といくつかの簡単なクエリをサポートし、徐々にデータ型とクエリのサポートを追加していくことです。

残念ながら、この計画はうまくいきませんでした。 psql から一見単純なエンドユーザー コマンドを実行するには、実際には多数の SQL 機能のサポートが必要です。たとえば、すべてのテーブルを一覧表示する \d コマンドは、内部的に次のクエリを実行します。

 c.relname を"Name"として、
  ケース c.relkind
    'r'のときは'table'  
    'v' の後に'view'  
    'm'の場合、 'マテリアライズド ビュー'  
    'i'のとき'index'  
    'S'の場合 'シーケンス'  
    's' の場合、 'special'の場合 
    'f'の場合'外部テーブル'  
  ENDを「タイプ」として、
  pg_catalog.pg_get_userbyid(c.relowner) を「所有者」として 
 pg_catalog.pg_class c から
     pg_catalog.pg_namespace n を n.oid = c.relnamespace に左結合します。
 c.relkind IN ( 'r' , '' )の場合
  かつ n.nspname <> 'pg_catalog'  
  AND n.nspname <> 'information_schema'  
  そして n.nspname !~ '^pg_toast'  
  かつ、pg_catalog.pg_table_is_visible(c.oid)
 1 , 2で順序付けします。

WHERE は、IN、等しくない、正規表現の一致などの演算子をサポートします。上記のクエリを満たすには、次の機能をサポートする必要があります。

• CASE 句
• 結合、特にLEFT JOIN
• 注文する
• pg_table_is_visible() などの組み込み

明らかに、これはさまざまな SQL 機能を表しているため、単一のユーザー テーブルを作成する前に、これらすべての機能を利用できるようにする必要があります。弊社のリリース「Google Spanner 上の分散 PostgreSQL アーキテクチャ - クエリ レイヤー」では、クエリ レイヤーがどのように機能するかを詳しく説明しています。

結論は

熟練したユーザーであっても、市場に出回っている多数のデータベースの中から選択しなければならないのは、最初は大変に思えるかもしれません。これは、特定の種類のアプリケーションに適したデータベースの選択が、そのデータベースのアーキテクチャにおけるトレードオフによって決まるためです。

YugaByte DB では、一連の非常に実用的なアーキテクチャ上の決定を斬新な方法で組み合わせて、独自のオープン ソース分散 SQL データベースを作成しました。データ損失ゼロ、水平書き込みスケーラビリティ、低読み取りレイテンシ、パブリック クラウドまたは Kubernetes でネイティブに実行する機能を備えた PostgreSQL の強力な SQL 機能が利用できるようになりました。