高性能、多階層高可用性、クラウドネイティブデータベースGaiaDBのアーキテクチャ設計の分析

1 クラウドネイティブデータベースとGaiaDB

現在、クラウドネイティブデータベースはさまざまな業界で大規模に実運用されており、最終的な目標は「スタンドアロン＋分散統合」です。しかし、進化という点では、現在、わずかに異なる 2 つの主要な道があります。

1 つは、主要なパブリック クラウド ベンダーがクラウドの互換性を優先するために選択した方法です。ストレージとコンピューティングの分離アーキテクチャに基づいて従来のデータベースを変換します。代表的な製品としては、AWS Aurora、Alibaba Cloud PolarDB、Tencent Cloud TDSQL-C、Baidu Smart Cloud GaiaDB などがあります。

パブリック クラウドのコア インフラストラクチャとして、データベースの最優先事項は、ユーザーのスムーズなクラウド移行を保証することです。現在、クラウド ネットワーク、クラウド ホスト、クラウド ディスクは完全な透過的な互換性を実現しています。クラウドネイティブ データベースは、構文、使用習慣、エコロジーの面でも完全な互換性を実現する必要があります。したがって、既存のエコシステムに基づく分散型変革が、好ましい進化の道筋となっています。ストレージとコンピューティングの分離ルートを使用するクラウドネイティブ データベースは、従来の使用習慣と完全に互換性があり、トランザクション シナリオに低レイテンシの書き込みトランザクション機能を提供します。同時に、分散ストレージのプーリング機能の助けにより、読み取りのスケーラビリティとストレージのスケーラビリティが大幅に向上します。

もう 1 つの方法は、最初に分散フレームワークを構築し、次にそれをデータベース ロジックで埋め込むことです。代表的な製品としては、OceanBase と TiDB があります。トランザクション サブシステムとロック サブシステムを別々のモジュールに分割します。コンピューティング層はこれらのモジュールと対話して、複数のノードが書き込み要求をサポートできるようにします。その後、統合された新しいトランザクション + ロック センター ノードが仲裁に使用されます。この方法により、より多くのコンピューティング リソースを必要とする書き込み負荷シナリオが大幅に改善されます。トランザクションとロックの両方がネットワークを介して相互作用する必要があるため、トランザクションの待ち時間が比較的長くなり、ロックの負荷が大きい場合にボトルネックになる可能性があります。

現時点では、これら 2 つのルートは明確に定義されておらず、独立して開発されており、全員が統一された目標に向かって進化しています。したがって、ストレージとコンピューティングの分離ルートにより、SQL のマルチレベル並列機能が徐々に強化されると同時に、ライブラリ テーブル レベル/行レベルでの複数の書き込みノードのマルチ書き込み機能が検討され、サポートされることがわかります。同時に、分散トランザクションルートでは、小規模なデータ規模での単一マシン展開アーキテクチャも積極的に検討されています。

したがって、将来的には、これら 2 つのルートは統合され続けることになります。ビジネス データの規模がどんなに大きくても、パーティション、インデックス、トランザクション モデルなどの情報にユーザーがあまり注意を払うことなく、データベース システム上でスムーズかつ迅速に実行できます。 10 年前、バックエンドの R&D エンジニアにとって、マシン間で大量の小さなファイルを保存することが必須科目であったのと同様に、S3 ストレージの登場により、ユーザーはハッシュやその他の方法を使用して 1 つのフォルダーに保存されるファイルが多すぎないようにする必要がなくなりました。

写真

GaiaDB は、Baidu Smart Cloud の長年にわたるデータベース研究開発の経験に基づいて徐々に改良されています。 GaiaDBは2020年に最初のバージョンをリリースし、ストレージとコンピューティングの分離に基づく大容量ストレージと迅速な弾力性を初めて実現し、Baiduの内部履歴ライブラリ、アーカイブライブラリなどの大容量ストレージのニーズを解決しました。

その後、グループ内のほとんどのコアビジネスのクロスリージョンホットアクティビティエントリしきい値とローカル読み取りパフォーマンス要件を満たすために、GaiaDB は 2021 年にリージョンホットアクティビティ機能をリリースしました。クロスリージョンホットアクティベーションでは、引き続きストレージレイヤー同期ソリューションが使用されます。論理同期に比べて、同期遅延とスループットが大幅に改善されます。スレーブ領域は、マスター領域とほぼ同じ同期機能を実現できます。システム全体の速度を低下させる欠点にはなりませんし、論理同期などの大規模なトランザクションなどのシナリオで遅延が急増することもありません。

そのため、バージョン 2.0 のリリース後、GaiaDB は Sogou、Tieba、Wenku などの複数のコア製品ラインに徐々に統合され、地域間シナリオにおけるビジネスのレイテンシとパフォーマンスの問題点を解決しました。

企業が徐々にクラウドに移行するにつれて、複数の可用性ゾーンでの高可用性の需要が徐々に顕著になってきました。単一のコンピュータ ルームの障害がサービスに影響を与えないようにする方法は、クラウドに移行する多くの企業にとって焦点となっています。この目的のために、GaiaDB は、クロスアベイラビリティゾーンのホットアクティビティをサポートするバージョン 3.0 を作成しました。各アベイラビリティーゾーンは、追加のストレージコストをかけずにリアルタイムでサービスを提供できます。今年、GaiaDB は、パフォーマンスのさらなる向上と機能の完全性の継続的な拡張を備えた、よりインテリジェントな 4.0 アーキテクチャを発表しました。

写真

次に、GaiaDB の全体的な紹介をします。現在、GaiaDB はあらゆる業界のシナリオをオンラインでカバーしており、最大のインスタンスは数百 TB に達します。オープンソースエコシステムとの互換性があるだけでなく、RPO=0 による高い信頼性も実現します。コスト面では、アーキテクチャ設計に統合された技術コンセプトを採用しているため、GaiaDB は特別なハードウェアやネットワーク環境に依存せずにパフォーマンスを保証し、クラウドベースかつクラウドネイティブなアーキテクチャを実現できます。

写真

2 GaiaDBの高性能とマルチレベルの高可用性設計

次に、GaiaDB のパフォーマンスの中核となる設計コンセプトを紹介します。融合と調整により、データベースと分散ストレージが深く統合され、リンク全体の同期から非同期への変換の条件が提供され、究極のパフォーマンスと汎用性が実現されます。

左の図に示すように、データベースが一般的な分散プロトコルと単一マシンのストレージ エンジンのみを使用する場合、データベースはマスターとスレーブの同期を処理する必要があり、CrashSafe に必要な物理ログが必要になることがわかります。同時に、一貫性プロトコルにはマスターとスレーブの同期、独自の WAL と永続的なスナップショットの書き込みも必要です。スタンドアロン エンジンには、CrashSafe に加えて、ログ システムとデータ ストレージ ロジックも必要です。

複数層のログのネストにより、複数層のレイテンシと書き込み増幅が発生することがわかりました。さらに複雑なのは、データ フローに複数のロジック レイヤーがネストされている場合、システム全体のデータ セキュリティにも一定の課題が生じることです。同時に、複数のレイヤー間でシリアル待機が必要になるため、ネットワーク遅延が追加されると、データベースのパフォーマンスが大幅に低下します。カスタマイズされたハードウェアとネットワークを使用してネットワークとディスクの待ち時間を短縮し、リンク時間を短縮することはできますが、これにより新たな不確実性が生じ、コストが高くなります。

GaiaDB のソリューションは、トランザクションとマスター/スレーブ同期ロジック、ログ ロジック、スナップショット、およびストレージ永続ロジックを再結合して配置することです。

最初のステップは、分散プロトコルのマスター/スレーブ同期ロジックをデータベース コンピューティング ノードに統合することです。コンピューティング層自体がマスターとスレーブの同期、トランザクション、一貫性の問題に対処する必要があるため、関連するワークロードは大幅に増加しません。この方法の最も直接的な利点は、2 ホップのネットワークと I/O を 1 ホップに削減し、リンク遅延を直接削減できることです。

次に、GaiaDB は多層増分ログをデータベース Redo 物理ログに統合し、LogService ログ サービスがその可用性と信頼性を担います。

さらに、GaiaDB は永続性、スナップショット、データベース再生機能もストレージ ノードに統合します。ストレージ層はデータベース再生機能をサポートしているため、データ ページ レベルでの MVCC を簡単に実装できます。この方法では、リンク全体にデータベースのセマンティクスのみが残り、データ フローはシンプルで信頼性が高くなり、ロジックが大幅に簡素化されます。

写真

コンセンサスモデルの変更点を見てみましょう。

たとえば、Raft プロトコルでは、コミット確認を実現するために 2 ホップのネットワークが必要です。右上隅は Raft のデータ フロー アーキテクチャです。CN ノードがリーダーに書き込みを送信した後、成功する前にリーダーがそれをフォロワーに送信し、少なくとも 1 つの戻り値を受信するまで待機する必要があります。

これにより、2 ホップ ネットワークと I/O の同期待機の問題が発生します。一方、GaiaDB は、コンピューティング ノードを複数のログ サービスに直接送信し、大多数が戻るまで待機するため、特別なハードウェアやネットワークに依存せずにレイテンシが短縮されます。このようにして、システム内のトランザクションの一貫性とマルチコピーの一貫性の両方がコンピューティング ノードによって均一に維持され、すべての増分ログがデータベースの物理ログとして統合されるため、全体的なデータ フローがシンプルで制御可能になります。

データリスクが最も高いクラッシュリカバリシナリオでは、データベースセマンティクスを統一的に使用することで、プロセス全体がより堅牢になり、データの信頼性が向上し、複数のログロジック間のデータ変換と同期によってもたらされる複雑さのリスクが軽減されます。パフォーマンス面では、ストレージ層自体に再生機能があるため、LogService 層のログ キャッシュ機能を最大限に活用できます。書き込み操作の場合、変更が行われるたびにディスクをフラッシュする必要はありません。ディスクをバッチでフラッシュできるため、ディスクのスループットと I/O が大幅に節約されます。

上記の変換後、オンライン スループット パフォーマンスは 40% 向上します。同時に、リンクの簡素化により、ロングテール遅延も大幅に最適化されます。コンピューティング ノードと分散マスター ノード間でネットワーク ジッターが発生するようなシナリオは、多数決機能によって最適化されます。

写真

一貫性プロトコル層の最適化について説明した後、リンク層の最適化について説明します。

総スループットは同時実行性に比例し、レイテンシに反比例することが分かっています。一貫性プロトコル層はデータ リンクを変換して短縮し、レイテンシを削減することでスループットを向上させることができます。では、データ ストリームの同時実行性を高めることでスループットを向上させる方法はあるのでしょうか?答えはイエスです。データベースの物理ログには独自のバージョン番号とデータ長があるため、一般的なストレージのようにブロックレベルのシリアルコミットを実装する必要はありません。一般的なストレージを使用する場合にシリアル送信が必要な理由は、ストレージ側ではリクエストが到着した順序に基づいてのみデータ バージョンを決定できるためです。順序が逆の場合、最終的な有効バージョンは不明になります。

GaiaDB の場合、LogService はデータベースのセマンティクスを認識する機能があるため、コンピューティング ノードは非同期で書き込むだけで済みます。ログ サービスは、データ バージョンに基づいて最新のデータを自動的に選択し、書き込みステータスに基づいて成功をバッチで返します。このようにして、リンクはレイテンシとスループットの分離を実現できます。

もちろん、コンピューティング レイヤーは、トランザクションの送信が成功するまで、ログ レイヤーからバッチで返される最新のディスク バージョンを待機するため、正常に送信されたトランザクションの一貫性と永続性の要件は依然として満たされます。

さらに、高負荷時にI/O要求とデータベース業務要求がCPUを奪い合う問題に対処するため、I/Oスレッド分離技術を使用し、リソース分離によってI/Oスレッドをデータベース業務スレッドから分離しました。この方法により、複雑な負荷シナリオでも I/O レイテンシを低く抑えることができます。

写真

前の 2 つの部分を分析した後、一部の学生は次のような疑問を持つかもしれません。ログ レイヤーはストレージ レイヤーに同期して書き込まれないため、最終的なシステムの一貫性は低下するのでしょうか。データの損失や不整合が発生する可能性はありますか?答えはノーです。 GaiaDB のストレージは MVCC をサポートするマルチバージョン システムだからです。したがって、再生の実装が非同期であっても、要求側が必要なデータ バージョンを提供するため、ストレージ レイヤーは対応するバージョンの強力に一貫性のあるデータ ビューを提供できます。

GaiaDB のストレージ ノードは、データ ページの再生機能をサポートしており、任意のターゲット バージョンに動的に再生して返すことができます。以前のバージョンでは、非同期要因により増分ログのこの部分が取得されなかった場合、ストレージ ノードは優先プル戦略を有効にして、ログをリアルタイムで 1 回プルしてから再生し、より適時性を高めていました。 GaiaDB の最新バージョンでは、コンピューティング層にも同じ再生機能が追加されました。ストレージ ノードが最善を尽くして再生しても要求を満たすことができない場合は、コンピューティング ノードが残りのタスクを実行します。

これにより、低速ストレージ ノードとの互換性が大幅に向上します。同時に、ストレージノードは最大限の再生を試みることになるため、ストレージ層の計算能力リソースも最大化されます。ダーティ フラッシュ ロジックは、ストレージ レイヤーに完全に移動されました。ストレージ ノードは、フラッシュ戦略とタイミングを独立して制御し、複数の書き込みをディスクに書き込む前にマージしようとします。これにより、ディスク I/O 負荷が大幅に軽減され、平均 I/O レイテンシが 50% 削減されます。

写真

下の図からわかるように、複数の最適化を組み合わせることで、読み取りと書き込みのパフォーマンスが最大 89% 向上し、特に書き込みリンクの改善が顕著になりました。これらの結果は、一般的なストレージ メディアとネットワーク環境を使用したテストによって得られたもので、主にデータ リンクの短縮と、同期から非同期への変換の適応型高スループット機能によるものです。

写真

パフォーマンスについて議論した後、高可用性に関する GaiaDB の考えと設計コンセプトを共有しましょう。

基盤となるデータ ストレージ リンクとして、データベースの可用性と信頼性はシステム全体に直接影響します。しかし、オンラインの状況は複雑かつ変化しやすいものです。コンピュータ ルームでは、小さな単一回線の停電からコンピュータ ルーム レベルの大規模なネットワーク異常に至るまで、いつでも異常な状況が発生する可能性があり、常にデータの可用性に潜在的な危険をもたらします。

商用データベースとして、マルチレベルの高可用性は最も重要な機能です。これは、さまざまなレベルでの異常事態に抵抗し、顧客ビジネスの円滑な運営を効果的に確保する唯一の方法です。 GaiaDB は、複数のレプリカ、クロス可用性ゾーン、クロスリージョンの 3 つのレベルの高可用性をサポートしています。複数のアベイラビリティーゾーンでホットアクティブ高可用性を革新的に実装し、単一インスタンスのクロスアベイラビリティーゾーン展開をサポートします。各アベイラビリティーゾーンはコストを増やすことなくオンライン サービスを提供でき、アベイラビリティーゾーンに障害が発生してもストレージの一貫性には影響しません。次に、各レベルでの高可用性機能の実装について見てみましょう。

写真

1 つ目は、インスタンスの複数のコピーによる高可用性機能です。

GaiaDB は全体的な分散アーキテクチャを再設計しました。システムは、コンピューティング層、ロギング層、ストレージ層の 3 つの層に分かれています。

コンピューティング層自体はステートレスであり、トランザクション処理と一貫性維持のみを担当するため、弾力性が強く、第 2 レベルのスイッチングとマルチノードの災害復旧を実現します。同時に、拡張と縮小にはメモリの起動のみが必要です。

ログ レイヤーは、システムの増分ログ部分の永続性を維持し、大部分の高可用性を実現します。同時に、一貫性調整の役割がコンピューティング層に移行されたため、この層は完全に対称的になります。ノード障害が発生した場合にマスター ノードの選出を待つ必要はなく、マスター ノードの再選出によって発生する混乱や業務の中断も発生しません。

その下にはストレージ層があり、データ ページ自体の永続性と更新を担当します。上位層は増分ログを保持するため、ストレージ層は n-1 個のレプリカ障害を許容できます。簡単に言えば、完全なコピーが 1 つある限り、上位層によって提供される増分ログと組み合わせることで、すべてのバージョンの完全なデータを再生でき、従来の多数決プロトコルよりも高い信頼性機能を実現できます。

写真

2 つ目は、可用性ゾーンとリージョン全体にわたる高可用性です。

GaiaDB のマルチレベルの高可用性は、ストレージ層での物理ログの直接レプリケーションに基づいています。論理レプリケーションと比較して、データリンクが大幅に短縮され、同期遅延が上位レベルの大規模トランザクションや DDL 操作の影響を受けなくなるため、マスター スレーブ同期遅延に大きな利点があります。

ゾーン間の高可用性を実現するために、GaiaDB は対称的なデプロイメント アーキテクチャを備えているため、ゾーン間で簡単にデプロイできます。これにより、ストレージ コストを増やすことなくマルチゾーンのホット アクティビティを実現でき、いずれかのゾーンで障害が発生してもデータの信頼性に影響はありません。

書き込みデータ ストリームは、最短のコンピュータ ルーム間ネットワーク上で 1 ホップのみを適応的に通過できます。分散マスター ノードが同じコンピュータ ルーム内にないことによって発生する 2 ホップのコンピュータ ルーム間ネットワークやリモート コンピュータ ルーム間の問題について心配する必要はありません。読み取りは引き続きローカルで実行されるため、単一のコンピューター ルーム展開に近いレイテンシ エクスペリエンスが実現します。データセンター間の伝送のネットワーク環境はより複雑であるため、GaiaDB はデータ ストリームのチェーン セルフ チェック メカニズムを追加し、データ エラーをプロアクティブに検出して、複雑なネットワーク環境でもデータの信頼性を確保できるようにしました。

クロスリージョンの高可用性のために、非同期並列アクセラレーションは物理的な同期にも使用されるため、長距離伝送の場合でもスループットはメインクラスターに追いつくことができ、スループットのボトルネックにはなりません。ネットワーク遅延を考慮すると、国内では数十ミリ秒の同期遅延を実現できます。これは、非同期並列書き込みアクセラレーションをリージョン間で使用して、レイテンシとスループットの関係に自動的に適応できるためです。同時に、領域間でのアクティブかつ高速な切り替えとデフォルトの近接読み取りを実現できます。

したがって、GaiaDB を使用すると、企業は複雑なデータ同期ロジックを使用せずに、低コストのクロス可用性ゾーンとクロスリージョンの高可用性を実現できます。

写真

高パフォーマンスと高可用性の設計コンセプトを紹介した後、現在取り組んでいる新機能について紹介します。

• 並列クエリ: 並列クエリは、同時実行性を高速化する並列クエリ機能です。これにより、大規模なデータ規模での複数行クエリに非常に優れた高速化効果が得られ、コンピューティング ノードの CPU およびメモリ リソースと、分散ストレージ層の並列 I/O 機能を最大限に活用できます。
• 分析スレーブ (HTAP): 分析スレーブには、数百 TB レベルのデータ計算をサポートする分析ノード ソリューションや、100 万行を超える取得の高速化をサポートする列インデックス エンジンなど、さまざまな行と列の高速化機能があります。列インデックス エンジンは物理ログ同期も使用します。これにより、ビジネスでデータの一貫性を維持する必要がなくなり、現在のトランザクション負荷のトランザクション分離レベルと互換性が確保されます。
• サーバーレス: 社内の潮汐コンピューティング能力を最大限に活用するリソース最適化およびスケジューリング ソリューションも検討しています。日中のビジネスピーク時には、よりリアルタイムな取引関連のビジネスにリソースが集中します。オフピーク期間中は、容量が自動的に削減され、オフライン コンピューティング ビジネスでリソースが再利用されます。これにより、顧客の運用・保守コストとリソースコストが節約されるだけでなく、アイドル状態や無駄なリソースが回避され、リソース使用率が向上します。

上記の機能は、近い将来グレースケールの試用版として利用可能になる予定です。

写真

本日お伝えしたいことは以上です。