MPP アーキテクチャ データ ウェアハウスのマネージドからネイティブ、クラウド ネイティブのプラクティスへ

1. はじめに

ガーナーは、2022 年までにすべてのデータベースの 75% がクラウド プラットフォームに導入または移行されると予測しています。もう一つの権威ある組織である IDC も、2025 年までに 50% 以上のデータベースがパブリック クラウドに導入され、中国ではこの数字が驚異的な 70% に達すると予測しています。長年の開発を経て、クラウド データベースはクラウド ホスト型からクラウド ネイティブ型へと変化しました。

クラウド ホスト: 市場と業界のクラウド需要に基づいて、ほとんどのベンダーは進化の第一歩としてクラウド ホスティングを選択しました。このモデルでは、ユーザーがオフラインで独自の IDC を構築する必要がなくなります。代わりに、クラウド プロバイダーの標準化されたリソースに依存してデータ ウェアハウスを移行し、高度に管理されたサービスを提供するため、ユーザーは基盤となるハードウェア管理コストと柔軟な計画リソースの制約から解放されます。

クラウドネイティブ: ただし、クラウドに移行する企業が増えるにつれて、基盤となるコンピューティング リソースとストレージ リソースが結び付けられ、ユーザーは使用中に不要なリソースの浪費を考慮することになります。たとえば、コンピューティング リソースが増加すると、ストレージの関連付けも増加する必要があり、結果として非効率的なコストが発生します。ユーザーは、クラウド リソースがデータ ウェアハウス リソースをより細かいレベルで分解できること、つまり、コンピューティング機能とストレージ機能を分離し、ビジネス リソース オーケストレーションのニーズを満たすために販売可能な単位に分割できることを期待し始めています。この時点で、クラウド ネイティブの最大の価値が真に強調されます。当社は、ストレージとコンピューティングのバランスが取れたデータウェアハウスの構築に注力するのではなく、ユーザービジネスに焦点を合わせ、大規模なコンピューティングやストレージの傾向を許可し、ビジネスに必要なリソースを独立して展開し、最小単位で販売します。現時点では、データ ウェアハウスのクラウド ネイティブ時代が本格的に到来しています。

2021年のYunqiカンファレンスで、Alibaba Cloudは新しいクラウドネイティブアーキテクチャを備えたデータウェアハウスを発表しました[1]。この記事では、クラウドネイティブ データ ウェアハウス製品 AnalyticDB PostgreSQL (以下、ADB PG) のクラウドホストからクラウドネイティブへの進化を紹介し、真のリソース プーリングと柔軟な販売を実現するための基礎となる設計と考え方を探ります。内容は、製品のアーキテクチャ設計、主要技術、パフォーマンス結果、効果実現、フォローアップ計画などです。 （全文読了時間は約10分です）

2. ADB PGクラウドネイティブアーキテクチャ

ユーザーがクラウド データ ウェアハウスに迅速に適応できるようにするために、現在、クラウド上の MPP アーキテクチャの設計コンセプトを採用しています。コーディネーションノードとコンピューティングノードは独立して展開されますが、単一の ECS 上で実行され、コンピューティングノードのストレージとコンピューティングの統合の展開設計を実現します。設計アーキテクチャは顧客側自社構築との互換性が高いため、データウェアハウス業務を迅速かつロスレスにクラウドへ移行できます。クラウドへの早期適応に非常に適しており、リソースの並行拡張という主な要求を満たします。クラウド ネイティブのさらなる進化に伴い、製品をサービス層、コンピューティング層、共有ストレージ層にさらに分割する新しいストレージとコンピューティングの分離アーキテクチャを提供します。アーキテクチャ図は次のとおりです。

マスター調整ノード: グローバル スキーマ情報を保存し、グローバル トランザクション管理を実装します。行ストレージ エンジン: メタデータ情報を保存するために使用されます。ここでのメタデータ情報は主に共有ストレージ ファイルの可視性情報を指し、次の 2 つの部分で構成されます。

• 1つはファイルとテーブルの関係です
• もう1つは削除されたデータの削除ビットマップです

行ストレージに基づいて、PG のローカル トランザクション機能を継承し、追加、削除、変更、クエリの実行時に PG のトランザクション機能と完全に互換性を保つことができます。

ローカル キャッシュ: ストレージ チームの DADI を使用して、高性能なローカル キャッシュを実装します。 DADI は、Alibaba Cloud Data Accelerator for Disaggregated Infrastructure の略です。オープンソース製品と比較すると、パフォーマンスが桁違いに向上します。

共有ストレージ: ClickHouse からいくつかの主要な設計を借用し、ストレージ層に MergeTree に基づく行と列のハイブリッド ストレージを実装しました。さらに、ファイルインターフェースをベースとした共有ストレージへの統一アクセスインターフェースを構築し、OSSとHDFSという2つの分散ファイルシステムに高度に適合させました。

アーキテクチャを設計する際には、同じく Greenplum から生まれた HAWQ と比較しました。 HAWQ はすべてのメタデータをマスターに保存します。書き込まれるたびに、変更されたメタデータがマスターに送られ、更新されます。読み取り時には、まず必要なメタデータがマスターから読み取られ、その後メタデータが実行プランに組み込まれます。このようにして、セグメントは対応するメタデータを取得でき、セグメントは完全にステートレスになります。しかし、この設計では 2 つの大きな問題が発生します。

1. メタデータの拡張により、マスターがボトルネックになります。

2. メタデータのパフォーマンスによって制限されるため、高同時実行のリアルタイム書き込みをサポートできません。このように設計しなかった理由は、将来的に高並行タスクをサポートしたいと考えているからです。 ADB PG は、Greenplum のシングルポイント マスター アーキテクチャをマルチマスターに拡張するために 2 年以上を費やしました。主な目的は、高並行性のリアルタイム書き込みの問題を解決することです。すべてのメタデータがマスターに保存されると、次の問題が発生します。1. マスター上のメタデータの保存とアクセスによって、単一ポイントのボトルネックが発生しやすくなります。2. 実行プランにメタデータを実装するには、ADB PG の実行レイヤーを大量に再構築する必要があります。これにより、クエリ プラン自体の帯域幅が大幅に増加し、同時実行性の高い小さなクエリには非常に不向きになります。そこで、アーキテクチャを改善し、メタデータをセグメントに分散して、次の問題を回避および実装しました。

1. マスターのストレージと読み取り/書き込みがボトルネックにならない

2. 実行層を再構築する必要はありません。メタデータを配布すると、単一のクエリの帯域幅の負荷を軽減できます。

3. 分散 KV 上のセグメントにメタデータを配置して、拡張と縮小のメタデータ移行問題を解決します。

共有ストレージで OSS が使用される理由は、単一ユーザーのビジネス データが増大し続けるにつれて、持続可能なストレージ ソリューションが必要となり、OSS の低いストレージ コスト、高い可用性、およびデータの永続性が最適な選択肢となるためです。

OSS を使用するもう 1 つの利点は、従量課金制であることです。ユーザーはストレージスペースのサイズを事前に設定する必要はありません。保存されたデータの量に応じてのみ支払います。データが削除されると料金は発生しません。 ESSD クラウド ディスクは通常、データに基づいてストレージ レベルを計算する必要があり、オンデマンドでストレージ リソースを実際に供給することはできず、容量を自動的に縮小することもできません。これらはすべて、当社のクラウドネイティブ設計コンセプトに違反しています。しかし同時に、OSS の欠点は RT です。

OSS の RT 問題を解決するために、コンピューティング ノードに一定の割合のローカル ディスクを構成してアクセスを高速化しました。さらに、ClickHouse マージツリー ストレージのコアアイデアに基づいて、順序を中核とし、ファイル内の絶対順序とファイル間の相対順序を考慮した、高性能な行と列のハイブリッド ストレージを設計しました。マージの非同期操作により、ファイルのマージとソートを実現します。順序に基づいて、ファイル内に 3 層の統計情報を設計し、多くの IO トリミング最適化を行いました。

以下、それぞれの技術的なポイントについてさらに紹介します。

3つの主要技術

1. 弾性スケーリング

高速で弾力的なスケーリングを実現するために、共有ストレージ上のハッシュ バケットにデータを整理し、スケーリング後に一貫したハッシュを通じてコン​​ピューティング ノードとバケットを再マップします。バケットとセグメントの割り当ての均一性を確保し、スケーリング後のキャッシュ障害の影響を軽減するために、従来の一貫性のあるハッシュ アルゴリズムを改良し、スケーリング中の動的マッピングをサポートしました。

ハッシュ バケットに従ってデータを複数のシャードに分割し、スケールアップまたはスケールダウン時にシャードの粒度に応じてオブジェクト ストレージ上のデータを再マップします。拡張されたコンピューティング ノードの数がシャードの数を超える場合、唯一のオプションはデータを再配布することです。この問題を解決するために、データの再配布を避けるために、バックグラウンドでのハッシュ バケットの分割とマージをサポートしています。

上記はスケールアップまたはスケールダウン時の「データ」の再マッピングです。データ ファイルの可視性を記述するメタデータは行テーブルに保存されるため、Greenplum のデータ再配布戦略を引き続き使用します。違いは、メタデータの再配布を高速化するために、並列配布などの最適化を行ったことです。容量拡張プロセスをさらに改善するために、容量拡張を例に挙げてみましょう。

ECS リソース プーリング、並列ネットワーク カードのロード、Docker イメージの予熱テクノロジを組み合わせることで、16 ノードのエンドツーエンドの時間は 1 分に近くなります。

2 階層ストレージ

階層型ストレージの実装は次のとおりです。

上図に示すように、ストレージ リソースは、メモリ、ローカル ディスク、共有ストレージの 3 つのレイヤーに分割されます。メモリ: 主に行ストレージ アクセスの高速化とファイル統計のキャッシュを担当します。ローカル ディスク: 行ストレージの永続ストレージとして、またリモート共有ストレージのローカル アクセラレータとして機能します。リモート共有ストレージ: データの永続ストレージとして機能します。

3 読み書きのプロセス

執筆プロセスは次のとおりです。

• ユーザーがデータを書き込む場合、データ バッチ処理を通じて OSS に直接書き込み、メタデータの一部がローカル ディスクに記録されます。このメタデータは、ファイルとデータ テーブル間の対応を記録します。メタデータは PG の行ストレージ テーブルを使用して実装され、この情報を保存するにはファイル メタデータ テーブルを使用します。
• 更新や削除の際に、OSS 上のデータを直接変更する必要はありません。削除をマークすることでこれを実現します。削除対象としてマークされた情報は、ローカル行ストレージ テーブルにも保存されます。この情報は可視性ビットマップを通じて保存されます。削除対象としてマークすると、読み取りパフォーマンスが低下します。削除による読み取りパフォーマンスへの影響を軽減するために、バックグラウンド マージを通じてファイルに削除情報を適用します。

書き込み時に、セグメント上のデータをバケットごとにさらに分割すると、ファイルが小さくなるという問題が発生します。小さなファイルの問題を解決するために、次の最適化を行いました。

1. グループ フラッシュ: 書き込まれたデータのバッチは、グループ フラッシュを通じて同じ OSS ファイルに書き込むことができます。当社の OSS ファイルは ORC 形式を使用しており、異なるバケットが対応するストリップに書き込まれます。

2. パイプラインの非同期並列化: バッチのエンコードとソートは典型的な CPU 集中型タスクであり、OSS へのアップロードは典型的なネットワーク IO 集中型タスクです。これら2種類のタスクを並列化し、OSSへのアップロードタスクを非同期タスクとして実行し、次のデータのバッチを同時にエンコードおよびソートすることで、書き込みパフォーマンスを高速化します。

リモート永続ストレージは 12 ナインの永続性を提供するため、信頼性を確保するために、メタデータを保存する行ストレージにのみ WAL ログと二重コピーが存在します。データ自体は、WAL ログや複数のコピーを必要とせずに共有ストレージに書き込まれます。 WAL ログの削減と WAL ログのマスター/スレーブ同期、および非同期並列化とバッチ処理により、バッチ書き込みシナリオでは、書き込みパフォーマンスは基本的に ECS エラスティック ストレージ バージョンのパフォーマンスと同等になります。

読み取りプロセスは次のとおりです。

• ファイル メタデータ テーブルを読み取ることで、スキャンする必要がある OSS ファイルを取得します。
• OSS ファイルに従って対応するファイルを読み取ります。
• 読み取られたファイルは、メタデータ テーブルの可視性ビットマップを通じて削除されたデータを除外します。

OSS の読み取りによって発生する遅延を解決するために、キャッシュ管理を実装し、共有ファイルへのアクセスをカプセル化する DADI も導入しました。ファイルを読み取るときは、まずローカル キャッシュがあるかどうかを判断します。その場合は、ローカル ディスクから直接読み取られます。そうでない場合は、OSS に読み込まれ、読み取った後にローカルにキャッシュされます。書き込み時には、データは直接 OSS に書き込まれ、ローカル ディスクに書き戻されます。書き戻しは非同期操作です。また、DADI を通じてローカル キャッシュ データの削除も管理します。DADI は、LRU/LFU 戦略に基づいてコールド データを自動的に削除します。

トランザクションは PG 行ストレージを使用して実装されるため、ADB PG トランザクションと完全に互換性があります。問題は、スケールアップまたはスケールダウンするときにこのデータを再配布する必要があることです。データ再配分メカニズムを再設計し、事前パーティショニング、並列コピー、ポイントツーポイントコピーなどのテクノロジーによりスケーリング時間を大幅に短縮しました。

パフォーマンス最適化のポイントをまとめると、次のようになります。• ローカル行ストレージ テーブルを通じてトランザクション ACID を実装し、データ ブロック レベルで同時実行性をサポートします。

• バッチおよびパイプラインの並列化により書き込みスループットが向上します。
• DADI に基づいて、メモリとローカル SSD のマルチレベル キャッシュを使用してアクセスを高速化します。

4 可視性テーブル

共有ストレージ ファイルに関連する情報はファイル メタデータに保存され、その構造は次のとおりです。

ハッシュ バケット: 拡張または縮小時にデータを再配置するときにバケットでスキャンするために使用されます。クエリを実行する場合、別のバケットに続くバケットでもあります。レベル: マージ ツリーのレベルです。レベル 0 はリアルタイムで書き込まれるデータを表します。この部分のデータは、マージ時に重みが高くなります。物理ファイル ID: ファイルに対応する ID です。セグメントに関連付けられなくなったため、64 バイトになります。セグメント内のテーブルの一意性を保証する必要はなくなりましたが、グローバルに一意であることは必要になりました。ストライプ ID: OSS ファイルには複数のバケット内のファイルを含めることができるためです。ストライプは、セグメントに一度に書き込まれた複数のバケットを 1 つの oss ファイルにマージしやすくするためのユニットとして使用されます。パフォーマンスの低下や OSS の小さなファイルの爆発につながる OSS の小さなファイルを回避します。合計数: ファイル行数であり、バックグラウンド マージの重みでもあります。数値が大きいほど、マージの重みは低くなります。

可視性ビットマップは削除されたファイルの情報を記録します

Start_row は 32k に対応し、削除ビットマップに対応します。行ストレージで使用されるこの 32000 4k、32k ページには、7 つのレコードを格納できます。削除数は削除されたアイテムの数です。 OSS にアクセスする必要がなく、マージする必要があるファイルを直接取得できるため、OSS へのアクセスによって発生する遅延を回避できます。さらに、OSS にはアクセススループットの制限もあるため、OSS の現在の制限をトリガーする頻繁なアクセスを回避することができます。

5. 行と列の混合ストレージ

Mergetree の構造は上図の左側に示されています。中核となるのは、バックグラウンド マージを通じて小さなファイルを順序付けられた大きなファイルにマージすることです。マージするときに、データの順序付けられた特性をさらに最適化するなど、データを再配置できます。後続の順序知覚最適化を参照してください。 leveldb との違いは次のとおりです。

1. レイヤー 0 でのリアルタイム書き込みがマージされます。異なるバケット内のファイルは 1 つの大きなファイルにマージされ、異なるバケットは対応するストライプに分類されます。

2. マージは、複数のレイヤーにわたって適切なファイルをマージします。ファイルは厳密に順序付けられていますが、ファイルは大まかに順序付けられています。レイヤーの数が多くなるほど、ファイルは大きくなり、ファイル間の重なりは小さくなります。

各ファイルには行と列の混合形式を使用します。右側は、行と列が混在するストレージの具体的なストレージ形式を示しています。 ORC に基づいて多くの最適化を行いました。

ORC ファイル: ORC ファイルには複数のストライプを含めることができ、各ストライプには複数の行グループが含まれ、各行グループには固定数のレコードが含まれ、これらのレコードは列ごとに個別に保存されます。

PostScript: ファイル記述情報 PostScript、ファイル メタ情報 (ファイル全体の統計、データ ディクショナリなどを含む)、すべてのストライプ情報、およびファイル スキーマ情報が含まれます。

ストライプ: ストライプは行の分割です。行はグループ化されてストライプを形成します。ファイルが読み取られるたびに行グループ単位で、各列のインデックスとデータが保存されます。インデックス データ、行データ、ストライプ フッターで構成されます。

ファイル フッター: ストライプの位置、ストライプ内の各列の統計、およびすべてのストリームの種類と位置を保存します。

インデックス データ: 行グループ レベルで統計情報を保存します。

データ ストリーム: ストリームは、インデックスやデータを含むファイル内の有効なデータ セグメントを表します。インデックス ストリームには、各行グループの場所と統計が格納されます。データ ストリームには複数の種類のデータが含まれます。具体的なタイプは、列タイプとエンコード方法によって決まります。次の例では、整数と文字列を例として使用します。

整数フィールドの場合、ビット ストリームと整数ストリームの両方が使用されます。ビット ストリームは値が null であるかどうかを識別するために使用され、整数ストリームは整数フィールドの null 以外のレコードの整数値を保存するために使用されます。

文字列型フィールドの場合、ORC ライターは最初に、フィールド値内の異なるコンテンツの割合が空でないレコードの合計数の 0.8 を超えないことをチェックし、辞書エンコーディングが使用され、フィールド値がビット ストリーム、バイト ストリーム、および 2 つの整数ストリームに格納されます。ビット ストリームは null 値の識別にも使用され、バイト ストリームは辞書の値を格納するために使用され、整数ストリームは辞書内の各エントリの長さを格納するために使用され、別の整数ストリームはフィールド値を記録するために使用されます。辞書エンコーディングを使用できない場合、ORC ライターはこのフィールドに繰り返し値が少なすぎることを認識し、辞書エンコーディングは効率的ではありません。 ORC ライターは、バイト ストリームを使用して文字列フィールドの値を保存し、整数ストリームを使用して各フィールドのバイト長を保存します。

ORC ファイルには、ファイル レベル、ストライプ レベル、行グループ レベルの 3 つのレベルの統計情報が保存されます。ストレージ パフォーマンスを向上させる鍵は、IO を削減することです。 IO トリミングを実現するために、ORC 統計とインデックスに基づいてさまざまなプッシュダウンを実装します。たとえば、Projection プッシュダウンでは、マテリアライズする必要がある列のみをスキャンします。 Agg プッシュダウンでは、データ ストリームの解凍を回避し、統計情報またはインデックスから必要な最小値、最大値、合計値、一意の値を直接読み取り、返します。述語については、フィルターのプッシュダウン、統計情報による直接フィルタリング、条件を満たさないストライプの直接スキップもサポートしています。さまざまな演算子、in/not in、式の等価変換をサポートしています。

さらに、ストレージ形式に対して次のパフォーマンス最適化を行いました。1. ゼロコピー: ORC データ型を PG データ型に変換するために、固定長型の値をコピーし、可変長型をポインタ参照の PG データに直接変換します。 2. バッチスキャン: 列にはバッチスキャンが使用されます。システムは、行を 1 つずつアクセスするのではなく、最初に 1 つの列をスキャンし、次に次の列をスキャンします。これは CPU キャッシュにとってより優しいものです。 3. シーク読み取りをサポート: ヒットをフィルタリングするときにジャンプするのに便利です。

6 ローカルキャッシュ

DADI は、効率的なキャッシュ管理と統合ストレージ アクセスという 2 つの機能の実現に役立ちます。 DADI を理解する前に、まず RT とスループットの 2 つの側面から DADI とオープン ソース ソリューションの比較テストを見てみましょう。

DADI は、オープン ソース ソリューション alluxio と比較して、メモリ ヒット シナリオでの RT が桁違いに向上し、スループットでも明らかな優位性があることがわかります。ディスクがヒットしたシナリオでも、明らかなパフォーマンス上の利点があります。一部の分析シナリオでは、ファイル統計を少量ずつ頻繁に読み取り、これらの統計をローカルにキャッシュします。この利点により、全体的なパフォーマンスが大幅に向上します。

キャッシュ ヒット シナリオにおける DADI のパフォーマンス上の利点は、次のアーキテクチャで確認できます。

DADI SDK: 標準の読み取りおよび書き込みインターフェースを介してストレージにアクセスします。キャッシュがヒットするかどうかに応じて、ショート サーキット読み取り、IPC プロセス通信を選択してローカル DADI サービスにアクセスするか、リモート DADI サービスにアクセスします。分散キャッシュ サービスに対応しており、ADB PG の読み取りおよび書き込みプロセスに lib ライブラリとして組み込まれています。キャッシュインスタンス: ローカルキャッシュを管理します。キャッシュ ファイルは、アクセスのために仮想ブロック デバイスに抽象化されます。メモリとディスク内のホット データとコールド データはブロック単位で管理されます。

ここでのコアとなる設計は次のとおりです。

• 短絡読み取り、共有メモリの直接読み取り、IPC を介した読み取りの回避。
• キャッシュヒットするかどうかのデータ構造も共有メモリにあります。参照カウントと堅牢なミューテックスを使用して、共有メモリ データのマルチスレッドの安全性を確保します。
• ディスク読み取り、100us、+ 27us は、ディスク読み取り RT 自体とほぼ等しくなります。 IPC は shm 通信を使用し、ローカル ソケット通信は使用しません。

4. リソース使用量が非常に少ない。メモリ: DADI サービスで使用されるメモリは 100 ～ 200 MB です。その理由は、IPC 実装が共有メモリに基づいており、ハッシュ テーブルなどのデータ構造により、マルチプロセス アーキテクチャでのメモリ拡張が回避されるためです。合理化されたコーディング方法では、16k の 1 つのメモリ ページが 4 バイトの管理構造に対応します。 CPU: ディスクがいっぱいになると、ローカル DADI サービスのシングルコア CPU が約 20% を使用します。 CPU は SDK によって使用され、SDK とローカル DADI サービス間の通信はほとんどありません。

さらに、メモリヒットにおける DADI の利点をより有効に活用するために、行と列の混合ストレージと組み合わせて次の最適化を行いました。

• キャッシュ優先度は、メモリ内に存在する統計情報と、ローカル ディスク内に存在するインデックス情報に対して高い優先度をサポートします。ディメンション テーブル データの高優先度キャッシュをローカルでサポートします。
• きめ細かなキャッシュ戦略 ローカルのホット データがすべて置き換えられる可能性がある大規模なテーブルでのコールド データ アクセスを回避するために、大規模なテーブルでは専用のキャッシュ領域が使用されます。
• ファイル非同期プリフェッチは、クエリ状況に基づいて、解析されたデータ ファイルをローカル マシンに事前に読み取ります。このプロセスは現在のファイルの読み取りと書き込みには影響せず、非同期です。

7 ベクトル化された実行

ADB PG のクラウド ネイティブ バージョンは、ベクトル化された実行エンジンもサポートします。このエンジンの核となるのは、バッチ処理によって CPU キャッシュ内のデータのヒット率を向上させ、コード生成を使用して関数呼び出しと複雑な計算命令のジャンプの数を減らし、SIMD 命令を使用して計算を高速化し、メモリ プール管理を使用して演算子間のメモリ コピーを減らすことです。詳細については[3]を参照してください。

8 秩序ある知覚

データの順序付けは主に 2 つの側面で使用されます。1 つは順序付けに基づく IO プルーニングであり、もう 1 つは計算プロセスでのソートを最小限に抑えることです。行と列が混在するストレージでの IO プルーニングについては多くの議論があります。ここでは主に2番目の点について説明します。ここで私たちが行う主な仕事は次のとおりです。

• 冗長なソート操作を排除します。データ自体が順序付けられており、ソート要件を満たしている場合は、ソート操作を追加する必要はありません。
• 並べ替える必要がある列の数を最小限に抑えます。たとえば、{c1、c2、..cn} を並べ替える場合、述語 c1=5 があると、余分なフィールドの並べ替えを避けるために順序は {c2、..cn} に簡略化されます。
• 順序が押し下げられます。初期化フェーズでは、降順の意図ソート操作が可能な限り押し下げられます。

ソートスキャン演算子を生成するには、次の方法を使用します。 SQL をクエリして解析し、AST を生成した後、一連のヒューリスティック ルールに従って AST を変換し、物理的な実行プランを生成します。

• まず、(結合/グループ化/個別/順序付け) などのさまざまな演算子の順序要件に従って、演算子の対象となる順序 (つまり、この演算子によって期待される順序付けされた入力) を確立します。
• 次に、ソート スキャン プロセス中に生成された興味深い順序は、順序プロパティの要件をできるだけ早く満たすために、可能な限り下位レベルの演算子 (先行ソート) にプッシュダウンされます。
• オペレーターに複数の興味深い順序がある場合、1 つの順序が複数の順序プロパティの要件を満たすように、それらをマージしようとします。

さらに、ソートスキャン演算子の実装もあります。ストレージ レベルでは、ファイル内の厳密な順序とファイルの大まかな順序のみが保証されます。私たちはこれを多方向マージアルゴリズムを通じて実現します。ここでの問題は、ソート スキャンのマルチウェイ マージではデータを 1 つずつ読み取る必要があるため、ベクトル化されたバッチ スキャンやファイルのバッチ読み取りと競合することです。最適な実行プランを選択するために CBO を使用します。

9 細粒度並列処理

ADB PG は、ノード間の並列コンピューティング機能を最大限に活用できる MPP アーキテクチャを使用します。クラウド ネイティブ バージョンでは、データをバケットに分割するため、ノード内でよりきめ細かい並列処理を実現できます。例として join を見てみましょう。

左側は、ノード内並列処理なしの結合の実行プランを示しています。ハッシュ結合ビルド用とプローブ用の 2 つのプロセスが開始されます。右側はノード内並列性を示しています。セグメントに割り当てられたバケットに基づいて並列処理を実行します。例えば、上図の各バケット内のデータは並列に計算できます。データはバケットごとに分割されるため、結合キーが分散キーの場合、ノード内並列処理によってローカル結合の最適化も完全に実行できます。

4つのパフォーマンス結果

1. パフォーマンスのスケーリング

コンピューティングリソースの拡張（ノード数）：2->44->88->1616->128

時間<1分<1分<1分<7分

2 読み取りおよび書き込みパフォーマンス

パフォーマンスをテストするために、4*4C インスタンスを使用し、ADB PG の新しいクラウド ネイティブ バージョンとストレージ エラスティック バージョンのパフォーマンスを比較しました。

パフォーマンステストを書く

使用したテストテーブルは、スケール係数 500 の TPC-H ラインアイテムテーブルです。同時実行数の異なるコピーコマンドを同時に実行することで、コマンド実行時間を測定し、総データ量をコマンド実行時間で割ることでスループットを算出します。

単一同時実行モードでは、主にリソースがいっぱいではないため、新しいバージョンのパフォーマンスはストレージ エラスティック バージョンのパフォーマンスと同様になります。

4 同時実行の場合、新しいバージョンのスループットはエラスティック ストレージの 2 倍になります。その理由は、ソート キーが lineitem テーブルで定義されているためです。新しいバージョンでは、データを書き込むときに WAL ログを書き込む必要はありません。さらに、バッチ処理とパイプラインの並列処理を組み合わせると、最初に書き込みを行ってからマージするエラスティック ストレージ バージョンに比べていくつかの利点があります。マージする場合、追加の WAL を書き込む必要があります。

同時実行数が 8 の場合、新しいバージョンは同時実行数が 4 の場合とほぼ同じです。主な理由は、4C 4 同時実行ではすでに CPU が完全に使用されているため、同時実行数を増やしても何も改善されないからです。

読み取りパフォーマンステスト

読み取りパフォーマンスを総合的にテストするために、次の 3 つのシナリオでテストを実施しました。フル メモリ: TPCH sf が 10 のデータ セットが使用され、10G のテスト データ セットが生成されました。完全なローカル ディスク キャッシュ: TPCH sf が 500 のデータ セットが使用され、500 GB のテスト データ セットが生成されます。半分キャッシュ、半分 OSS: TPCH sf が 2000 のデータ セットが使用され、2000 GB のテスト データ セットが生成されます。 (ローカルディスクキャッシュ 960GB) テスト結果は次のとおりです (縦軸は RT (ミリ秒))

メモリがいっぱい

完全なローカルディスクキャッシュ

半分はローカルキャッシュ、半分はOSS

上記のテスト結果から:

• クラウド ネイティブ バージョンは、きめ細かい並列処理によってもたらされる加速効果により、従来のエラスティック ストレージ バージョンと比較してパフォーマンスが 2 倍以上向上しています。
• TPCH などの計算集約型のジョブの場合、データの半分がキャッシュされ、残りの半分が OSS に保存されている場合でも、パフォーマンスは良好です。 SF 2000 のデータ量は SF 500 の 4 倍、RT は 2.8 倍に増加します。主な理由は、4*4C インスタンスには OSS に対する帯域幅のボトルネックがなく、独自の読み取りプリフェッチが最適化されているためです。

5. 結論

AnalyticDB PostgreSQL の新しいクラウドネイティブ バージョンは、物理リソースを完全にプールし、ストレージとコンピューティング能力をユニット単位で割り当て、柔軟な展開を実現します。この機能により、ユーザーは究極のコスト効率を実現し、コンピューティング能力の最適な割り当てを実現します。同時に、ユーザーが使用するための敷居を下げることで、ユーザーはコンピューティング能力やストレージ計画に多大な労力を費やすことなくビジネスに集中できるようになり、アップグレードされたエクスペリエンスを実現できます。

• ストレージとコンピューティングを分離することで、ユーザーはビジネス負荷モデルに応じてコンピューティング集約型またはストレージ集約型のサービスを簡単に適応させ、使用量に基づいて保存および課金し、ストレージとコンピューティングの厳格な統合によって生じるリソースの浪費を回避できます。
• ビジネス負荷のピークと谷に動的に適応するために、クラウドネイティブ MPP アーキテクチャは、コンピューティング側でシェアードナッシング アーキテクチャを使用します。これにより、数秒以内の柔軟なスケーリングがサポートされ、共有ストレージによって基盤となるストレージが独立し、コンピューティングの影響を受けなくなります。これにより、初期段階でユーザーが仕様を選択する際のハードルが下がり、後期段階ではビジネスニーズに基づいて動的に調整する余地が生まれます。
• ストレージとコンピューティングの分離に基づいて、データ共有機能が提供されます。これにより、物理マシンの境界を真に壊し、クラウド上のデータが真に流れるようになります。たとえば、インスタンス全体でデータをリアルタイムで共有すると、1階建てのマルチプレーション使用モデルをサポートし、データアクセスを最初にインポートしてからアクセスする必要がある従来のデータウェアハウスインスタンスの分離を破り、操作を簡素化し、効率を改善し、コストを削減できます。

6。フォローアップ計画

上記のストレージ分離アーキテクチャに基づいて、将来の3つの主要な方向に焦点を当てます。

• 機能の完了：これは主に、プライマリキー、インデックス、マテリアルビュー、書き込み機能など、現在のバージョンの制限を完了するためです。
• パフォーマンスを継続的に最適化し、主にキャッシュミスシナリオを最適化します。
• クラウドネイティブアーキテクチャは、主に現在のストレージおよびコンピューティング分離アーキテクチャの下でユーザーエクスペリエンスをさらに向上させるために、引き続きアップグレードされています。

クラウドネイティブのアップグレードには、2つの主要な重点領域があります。

• ストレージとコンピューティングの分離は、サーバーレスに向かってさらに一歩進んでおり、容量の拡大と収縮をシームレスにします。さらに、メタデータとステータスをコンピューティングノードからサービスレイヤーに分離し、セグメントをステートレスにします。これの利点は、容量の拡大と削減をユーザーに気付かずに実行できることです。もう1つの利点は、セグメントのステートレス性がシステムの高可用性を改善するのに役立つことです。現在、マスタースレーブモードを介して高可用性を提供しています。ノードが失敗すると、マスタースレーブスイッチングのキャッシュ無効性パフォーマンスが急激に低下します。セグメントがステートレスになった後、クラスターから直接削除し、「容量の削減」によりサービスを改善し続けます。
• アプリケーションインスタンス全体でデータの共有。さらに、分析ビジネスの場合、データスケールはTBから始まります。従来のデータ倉庫では、データの冗長性と高いデータ同期コストを備えた煙突スタイルのアーキテクチャを使用しています。インスタンスクロスデータ共有機能を提供し、データウェアハウスアーキテクチャを再構築したいと考えています。

クラウドネイティブ版は2022年2月に正式に商業化されます。詳細については、製品Webサイトhttps://www.aliyun.com/product/gpdbをご覧ください。

7。参照

【1】http://click.aliyun.com/m/1000307639/

【2】https://developer.aliyun.com/article/838806？groupcode = analyticdb4postgresql&share_source=wechat_qr

【3】https://developer.aliyun.com/article/783182