PolarDB:HTAPの実践と最適化

背景情報

PolarDB-X HTAPアーキテクチャの詳細については、「HTAP」をご参照ください。

HTAPクラスター

購入するPolarDB-Xプライマリインスタンスは、オンラインの汎用ビジネスシナリオで一般的に使用されます。 ビジネスシナリオで分析、オフラインデータのエクスポート、および同じデータセットに対するバッチ処理が必要な場合は、PolarDB-Xプライマリインスタンス用に複数の読み取り専用インスタンスを購入できます。 詳細については、「読み取り専用インスタンス」をご参照ください。

オンラインHTAPリクエストが存在する場合、またはビジネスシナリオで読み書き分離が必要な場合は、クラスターエンドポイントを使用することを推奨します。 PolarDB-Xは、インテリジェントルーティングまたは読み書きの重みに基づいて、一部のリクエストを読み取り専用インスタンスに転送します。 ビジネスシナリオでオフラインデータ分析のみが必要な場合は、読み取り専用のルーティングエンドポイントを使用することを推奨します。 読み取り専用ルーティングエンドポイントを使用して、読み取り専用インスタンスに直接アクセスできます。 読み取り専用ルーティングエンドポイントを使用してルーティングされるリクエストは、マルチノード並列処理 (MPP) モードを使用して高速化されます。 エンドポイントの詳細については、「読み書き分離の設定」をご参照ください。

ルーティング

インテリジェントルーティング

PolarDB-Xオプティマイザは、コストに基づいて、スキャンされた行の数と、CPU、メモリ、I/O、ネットワークなどのコアリソースの消費量を分析します。 次に、オプティマイザは、要求をトランザクション処理 (TP) および分析処理 (AP) ロードにグループ化する。 クラスターエンドポイントのインテリジェントルーティングを有効にすると、SQLクエリのワークロードタイプを自動的に識別して、SQLクエリをルーティングできます。 たとえば、APロードとして識別されたSQLクエリは、読み取り専用インスタンスにルーティングされます。 cost文の説明を実行して、SQLクエリ用に識別されたワークロードの種類を表示できます。 たとえば、次のクエリでは、少数の行がスキャンされ、少数のコンピューティングリソース (CPUとメモリ) が消費されます。 返された結果で、rowcountはスキャンされた行の数を示し、memoryは消費されたメモリリソースを示し、cpuは消費されたCPUリソースを示します。 このクエリは、TP負荷として識別される。

mysql> cost select a.k、count(*) cnt from sbtest1a、sbtest1bここでa.id = b.kおよびa.id> cntを持つkによる1000グループ> cntによる1300順序5、10; |
+ ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- +
| TopN(sort="cnt ASC" 、offset=?2、fetch=?3): rowcount = 1.0、累積コスト=value = 2.8765038E7、cpu = 37.0、memory = 64.0、io = 3.0、net = 5.75、id = 163602178 |
| フィルター (条件="cnt > ?1"): rowcount = 1.0、累積コスト=value = 2.8765026E7、cpu = 26.0、メモリ=47.0、io = 3.0、net = 5.75、id = 163602177 |
| HashAgg(group="k" 、cnt="COUNT()"): rowcount = 1.0、累積コスト=value = 2.8765025E7、cpu = 25.0、メモリ=47.0、io = 3.0、net = 5.75、id = 163602171 |
| BKAJoin(condition="k = id", type="inner"): rowcount = 1.0, 累積コスト=value = 2.8765012E7, cpu = 12.0, memory = 18.0, io = 3.0, net = 5.75, id = 163602169 |
| 収集 (同時=true): rowcount = 1.0、累積コスト=value = 2.3755003E7、cpu = 3.0、メモリ=0.0、io = 1.0、net = 4.75、id = 163602164 |
| LogicalView(tables="[000000-000003].sbtest1_[00-15]", shardCount=16, sql="SELECT 'id', 'k' FROM 'sbtest1' WHERE ('id' > ?)")
| 収集 (同時=true): rowcount = 1.0、累積コスト=値=5003.0、cpu = 3.0、メモリ=0.0、io = 1.0、net = 0.0、id = 163602167 |
| LogicalView(tables="[000000-000003].sbtest1_[00-15]", shardCount=16, sql="SELECT 'k' FROM 'sbtest1' AS 'sbtest1' WHERE (('k' > ?)) AND ('k' IN (...))"): rowcount = 1.0、累積コスト=値=5002.0、cpu = 2.0、メモリ=0.0、io = 1.0、net = 0.0、id = 163601377 | |
| WorkloadType: TP | |
+ ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- + 

クエリのワークロード・タイプの識別は、HTAP要求ルーティングにとって重要である。 WORKLOAD_TYPEヒントを使用して、クエリのワークロードタイプを指定できます。 次の例では、上記のクエリも使用され、クエリのワークロードタイプがAPロードとして強制的に指定されます。

mysql> cost /* + TDDLを説明する: WORKLOAD_TYPE=AP */ select a.k、count(*) cnt from sbtest1a、sbtest1bここでa.id = b.kおよびa.id > 1000 group by k having cnt > 1300 order by cnt limit 5、10 |
+ ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- +
| TopN(sort="cnt ASC" 、offset=?2、fetch=?3): rowcount = 1.0、累積コスト=value = 2.8765038E7、cpu = 37.0、memory = 64.0、io = 3.0、net = 5.75、id = 163602178 |
| フィルター (条件="cnt > ?1"): rowcount = 1.0、累積コスト=value = 2.8765026E7、cpu = 26.0、メモリ=47.0、io = 3.0、net = 5.75、id = 163602177 |
| HashAgg(group="k" 、cnt="COUNT()"): rowcount = 1.0、累積コスト=value = 2.8765025E7、cpu = 25.0、メモリ=47.0、io = 3.0、net = 5.75、id = 163602171 |
| BKAJoin(condition="k = id", type="inner"): rowcount = 1.0, 累積コスト=value = 2.8765012E7, cpu = 12.0, memory = 18.0, io = 3.0, net = 5.75, id = 163602169 |
| 収集 (同時=true): rowcount = 1.0、累積コスト=value = 2.3755003E7、cpu = 3.0、メモリ=0.0、io = 1.0、net = 4.75、id = 163602164 |
| LogicalView(tables="[000000-000003].sbtest1_[00-15]", shardCount=16, sql="SELECT 'id', 'k' FROM 'sbtest1' WHERE ('id' > ?)")
| 収集 (同時=true): rowcount = 1.0、累積コスト=値=5003.0、cpu = 3.0、メモリ=0.0、io = 1.0、net = 0.0、id = 163602167 |
| LogicalView(tables="[000000-000003].sbtest1_[00-15]", shardCount=16, sql="SELECT 'k' FROM 'sbtest1' AS 'sbtest1' WHERE (('k' > ?)) AND ('k' IN (...))"): rowcount = 1.0、累積コスト=値=5002.0、cpu = 2.0、メモリ=0.0、io = 1.0、net = 0.0、id = 163601377 | |
| WorkloadType: AP | |
+ ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- + 

ルールベースのルーティング

コストベースのインテリジェントルーティングに加えて、読み取りおよび書き込み重みに基づいて実行されるルールベースのルーティングがサポートされます。 マスター_READ_WEIGHTパラメーターを設定して、コンソールの [パラメーター設定] ページで読み書き分離の読み取りおよび書き込み重みを指定できます。 このパラメーターのデフォルト値は100です。 値の範囲は0から100です。 値が60に設定されている場合、60% のリクエストがプライマリインスタンスで処理されます。 残りの40% リクエストは、1つ以上の読み取り専用インスタンスにルーティングされます。 複数の読み取り専用インスタンスが利用可能な場合、残りの40% リクエストは自動的に読み取り専用インスタンスに割り当てられます。

インテリジェントルーティングは、ルールベースのルーティングから切り離されています。 次の表に、インテリジェントルーティングとルールベースのルーティングの関係を示します。

実行モード

EXPLAIN PHYSICALステートメントは、元のEXPLAINステートメントの拡張として提供されるため、正確な実行モードを取得できます。 たとえば、次のクエリでは、EXPLAIN PHYSICALステートメントが実行されます。 結果は、クエリがMPP実行モードを使用することを示しています。 実行プランの各フラグメントの並列度も返されます。

mysql> explain physical select a.k, count(*) cnt from sbtest1a, sbtest1bここでa.id = b.kおよびa.id > 1000 group by k hing cnt > 1300または
der by cnt limit 5, 10;
+ ------------------------------------------------------------------------------------------------------------------------------------------------------------------- +
| プラン |
+ ------------------------------------------------------------------------------------------------------------------------------------------------------------------- +
| ExecutorType: MPP |
| クエリのMaxConcurrentParallelism: 2 |
| フラグメント1 |
| シャッフル出力レイアウト: [BIGINT, BIGINT] 出力レイアウト: [BIGINT, BIGINT] |
| 出力パーティショニング: SINGLE [] Parallelism: 1 |
| TopN(sort="cnt ASC" 、offset=?2、fetch=?3) |
| フィルター (condition="cnt > ?1") |
| HashAgg(group="k", cnt="COUNT()") |
| BKAJoin(condition="k = id", type="inner") |
| RemoteSource(sourceFragmentIds=[0], type=RecordType(INTEGER_UNSIGNED id, INTEGER_UNSIGNED k)) |
| 収集 (同時=true) |
| LogicalView(tables="[000000-000003].sbtest1_[00-15]" 、shardCount=16、sql="SELECT 'k' FROM 'sbtest1' AS 'sbtest1' WHERE (('k' > ?)) AND ('k' IN (...)))) |
| フラグメント0 |
| シャッフル出力レイアウト: [BIGINT, BIGINT] 出力レイアウト: [BIGINT, BIGINT] |
| 出力パーティショニング: SINGLE [] Parallelism: 1 Splits: 16 |
| LogicalView(tables="[000000-000003].sbtest1_[00-15]", shardCount=16, sql="SELECT 'id', 'k' FROM 'sbtest1' AS 'sbtest1' WHERE ('id' > ?)") |
+ ------------------------------------------------------------------------------------------------------------------------------------------------------------------- + 

ワークロードと実行モードは結合されています。 MPP実行モードは、APロードに使用されます。 EXECUTOR_MODEヒントを使用して実行モードを指定できます。 プライマリインスタンスに多数のアイドルリソースがある場合、実行モードをシングルノードまたはマルチノード並列処理モードとして強制的に指定して、クエリを高速化できます。

mysql> explain physical /* + TDDL:EXECUTOR_MODE=AP_LOCAL */select a.k、count(*) cnt from sbtest1a、sbtest1bここでa.id = b.kおよびa.id > 1000 group by k having cnt > 1300 order by cnt limit 5、10; |
+ ------------------------------------------------------------------------------------------------------------------------------------------------------------- +
| ExecutorMode: AP_LOCAL |
| フラグメント0の依存関係: [] parallelism: 4 |
| BKAJoin(condition="k = id", type="inner") |
| 収集 (同時=true) |
| LogicalView(tables="[000000-000003].sbtest1_[00-15]", shardCount=16, sql="SELECT 'id', 'k' FROM 'sbtest1' AS 'sbtest1' WHERE ('id' > ?)") |
| 収集 (同時=true) |
| LogicalView(tables="[000000-000003].sbtest1_[00-15]" 、shardCount=16、sql="SELECT 'k' FROM 'sbtest1' AS 'sbtest1' WHERE (('k' > ?)) AND ('k' IN (...)))) |
| フラグメント1の依存関係: [] parallelism: 8 |
| LocalBuffer |
| RemoteSource(sourceFragmentIds=[0], type=RecordType(INTEGER_UNSIGNED id, INTEGER_UNSIGNED k, INTEGER_UNSIGNED k0)) |
| フラグメント2の依存関係: [0, 1] parallelism: 8 |
| フィルター (condition="cnt > ?1") |
| HashAgg(group="k", cnt="COUNT()") |
| RemoteSource(sourceFragmentIds=[1], type=RecordType(INTEGER_UNSIGNED id, INTEGER_UNSIGNED k, INTEGER_UNSIGNED k0)) |
| フラグメント3の依存関係: [0, 1] parallelism: 1 |
| LocalBuffer |
| RemoteSource(sourceFragmentIds=[2], type=RecordType(INTEGER_UNSIGNED k, BIGINT cnt)) |
| フラグメント4の依存関係: [2, 3] parallelism: 1 |
| TopN(sort="cnt ASC" 、offset=?2、fetch=?3) |
| RemoteSource(sourceFragmentIds=[3], type=RecordType(INTEGER_UNSIGNED k, BIGINT cnt)) |
+ ------------------------------------------------------------------------------------------------------------------------------------------------------------- + 

MPP実行モードの場合、並列度は、スキャンされた行の数、インスタンスの仕様、およびコンピューティングプロセスに含まれるテーブルシャードの数に基づいて計算されます。 並行性の高いシナリオを考慮する必要があるため、全体的な並列性は控えめに計算されます。 EXPLAIN PHYSICALステートメントを実行して、並列処理の程度を表示できます。 MPP_PARALLELISMヒントを使用すると、並列度を強制的に指定できます。

/* + TDDL:EXECUTOR_MODE=MPP MPP_PARALLELISM=8 */select a.k, count(*) cnt from sbtest1a, sbtest1bここでa.id = b.kおよびa.id > 1000 group by k having cnt > 1300 order by cnt limit 5, 10;

スケジューリングポリシー

複数の読み取り専用インスタンスを購入し、それらをクラスターエンドポイントに関連付ける場合、クラスターエンドポイントを使用して読み取り専用インスタンスにルーティングされるSQLクエリは、読み取り専用インスタンスの複数のノードに均等にスケジュールされます。 クエリは、各ノードのリソース負荷に基づいてスケジュールされ、負荷がノード間で均等に分散されるようにします。 たとえば、PolarDB-Xは、読み取り専用インスタンスのレイテンシをスケジューリングの参照メトリックとして使用します。 これにより、レイテンシの高い読み取り専用インスタンスにクエリがスケジュールされなくなります。

フィードバックメカニズム

統計に基づいてワークロードがインテリジェントに識別されると、エラーが発生する可能性があります。 ワークロード識別エラーの場合、PolarDB-Xは、スキャンされた行の数とクエリの実行時間に基づいてワークロードの種類を変更できます。 このプロセスは、ワークロードの適応フィードバックと呼ばれます。 PolarDB-Xでは、実行計画とそのワークロードが管理されます。 詳細については、「実行プランの管理」をご参照ください。 次のステートメントを実行して、プラン管理で各プランのワークロードを表示できます。

ベースライン [Select Statemtnt]

TP負荷と識別されたシンプルクエリで、クエリの実行時間とスキャン行数がしきい値より大きい場合、クエリはAP負荷に変更され、プラン管理でAP負荷として管理されます。 同様のルールは、AP負荷として識別されるクエリに適用される。 アダプティブフィードバック機能に加えて、次のステートメントを実行して、プラン管理でワークロードの種類を手動で変更できます。

ベースライン修正sql /* + TDDL:WORKLOAD_TYPE=AP */ [Select Statemnt]

実行計画のワークロードタイプが計画管理で適切に変更された後、計画管理で同じワークロードタイプを持つクエリに正しいワークロードマークが割り当てられます。

読み取り整合性

ビジネストラフィックは、読み取り専用ルーティングエンドポイントを使用してルーティングされます。 これにより、グローバルな読み取り一貫性を設定できます。 詳細については、「読み書き分離の設定」をご参照ください。 ビジネストラフィックは、クラスターエンドポイントを使用して読み取り専用インスタンスにルーティングされます。 デフォルトでは、グローバル読み取り整合性が有効になっています。 グローバル読み取り一貫性メカニズムにより、データがプライマリインスタンスに書き込まれた後に読み取り専用データベースからデータを読み取ることができます。 これは、従来のリード /ライト分割アーキテクチャにおける複製遅延によるリードデータとライトデータとの間の不整合を防止する。

サービスがクラスターエンドポイントを使用していて、読み取りデータと書き込みデータの一貫性が必要ない場合は、[パラメーター設定] ページでENABLE_CONSISTENT_REPLICA_READを指定するか、ヒントを使用してクエリの読み取り一貫性を無効にできます。 たとえば、現在の読み取り専用インスタンスのレプリケーション遅延によって引き起こされるデータの不整合を無視できる場合は、上記の方法を使用して読み取りの整合性を無効にできます。

/* + TDDL:ENABLE_CONSISTENT_REPLICA_READ=false */ [ステータスの選択]

よくある質問

• クラスターエンドポイントでインテリジェントルーティングを有効にした後、ルールベースのルーティングを有効にするには、MASTER_READ_WEIGHTを指定する必要がありますか。

  PolarDB-Xインテリジェントルーティングを使用して、APロードとして識別された複雑なSQLクエリを読み取り専用インスタンスにルーティングし、プライマリインスタンスのワークロードを減らします。 TPロードとして識別された単純なクエリの同時並行性が高く、プライマリインスタンスの多数のリソースを消費する場合、ルールベースのルーティングを有効にして、一部のTPロードを読み取り専用インスタンスに割り当てることもできます。

• クラスターエンドポイントに基づく読み書き分離は、従来の読み書き分離と比例的に互換性がありますか? 違いと利点は何ですか?

  PolarDB-Xは、インテリジェントルーティングとルールベースのルーティングの2つのモードをサポートしています。 ルールベースのルーティングは、従来の読み書き分割モードと互換性があります。 PolarDB-Xの読み書き分離の利点は、読み取り同時実行メカニズムがサポートされていることです。 これにより、読み取り専用インスタンスのレプリケーション遅延による読み取りデータと書き込みデータの不整合が防止されます。

• SQLクエリのインテリジェントルーティングに基づいて識別されたワークロードタイプをクエリできますか。 識別が正しくない場合の影響と、ワークロードの種類を変更するにはどうすればよいですか?

  PolarDB-Xは、プラン管理機能を使用して、実行に使用されたSQLテンプレートと実行プランを照会できます。 インテリジェントルーティングの場合、SQLクエリのワークロードタイプは、実行に関するフィードバックに基づいて自動的に変更できます。 また、ヒントを使用してワークロードタイプを強制的に指定し、プラン管理でワークロードタイプを変更することもできます。

• OLTP、データ伝送サービス (DTS) 、およびOLAPを組み合わせた従来のソリューションに対する、クラスターエンドポイントに基づくHTAPモードの特徴と利点は何ですか?

  PolarDB-XのHTAPモードでは、データベースのネイティブマルチレプリカ機能を使用してO&Mを簡素化し、データのエクスポートとDTSへのデータのインポートによるデータ同期のコストを削減します。 さらに、HTAPモードは読み取り整合性メカニズムを提供し、MPPをサポートします。 HTAPモードは、リアルタイムでスケーラブルなオンラインコンピューティングのためのサービスの要件を満たすことができます。