行ストアノードと列ストアノード間の自動リクエスト配信のソリューション - PolarDB

アプリケーションがOLAPサービスとOLTPサービスの両方にアクセスするリクエストを送信し、実行コストに基づいてリクエストを自動的に配布する場合は、クラスターエンドポイントの読み取り /書き込みモードを設定し、自動リクエスト配布機能を有効にする必要があります。自動リクエスト配信機能が有効になっている場合、データベースプロキシは、スキャンされた行の推定数に基づいてリクエストを自動的に配信し、リクエスト処理を高速化します。 SQLリクエストによってスキャンされた行の推定数がしきい値を超えると、リクエストは列ストアノードに配信されます。 SQLリクエストによってスキャンされた行の推定数がしきい値を超えない場合、リクエストは行ストアノードまたはプライマリノードに配信されます。

自動配布ソリューション

PolarDB for MySQLのデータベースプロキシは、リクエストによってスキャンされた推定行数が指定されたしきい値を超えるかどうかに基づいて、SQLリクエストを列ストアノードに配信するかどうかを決定します。これにより、行ストアおよび列ストアノードのパフォーマンスを完全に活用できます。

リクエスト配布ルール:

OLTPサービス: ほとんどの場合、読み取りおよび書き込み要求が含まれます。すべての書き込み要求は、プライマリノードによって処理されます。読み取り要求は、読み取り専用の行ストアノードまたはプライマリノードによって処理されます。
OLAPサービス: ほとんどの場合、読み取り要求のみが含まれます。すべての読み取り要求は、読み取り専用列ストアノードによって処理されます。

自動リクエスト配信ソリューション:

プライマリノードと読み取り専用列ストアノード間のリクエストの配布: プライマリノードも行ストアモードにあるため、プライマリノードはOLTP読み取りリクエストを処理できます。このソリューションでは、書き込み要求とOLTP読み取り要求がプライマリノードに分散されます。 OLAP読み取り要求は、読み取り専用列ストアノードに配信されます。
読み取り専用の行ストアノードと読み取り専用の列ストアノード間のリクエストの分散: このソリューションでは、書き込みリクエストはプライマリノードに分散され、OLTP読み取りリクエストは読み取り専用の行ストアノードまたはプライマリノードに分散され、OLAP読み取りリクエストは読み取り専用の列ストアノードに分散されます。

混合下分流

制限事項

クラスターには、少なくとも1つの読み取り専用列ストアノードと1つの行ストアノードが含まれています。

ステップ1: 列ストアノードと行ストアノード間の自動リクエスト配信を有効にする

PolarDBコンソールにログインします。
左上隅で、クラスターがデプロイされているリージョンを選択します。
クラスターを見つけて、そのIDをクリックします。
では、Enterprise Editionのセクション概要ページで、クラスターエンドポイントを見つけて、クラスターエンドポイントの右側にある変更をクリックします。
適切な読み書きモードを選択します。
- クラスターエンドポイントの読み取り /書き込みモードは、読み書き に設定されています。
- クラスターエンドポイントの読み取り /書き込みモードはReadOnlyに設定され、負荷分散ポリシーはアクティブな要求ベースの負荷分散に設定されます。
ノード設定 セクションで、リクエストの処理に使用するプライマリノードと読み取り専用の行ストアおよび列ストアノードを選択します。 HTAP の最適化セクションで、トランザクションと分析処理の分離を有効にします。 [OK] をクリックします。
説明
ノード設定 で少なくとも1つの読み取り専用列ストアノードを選択する必要があります。
例1: 次の図では、1つのプライマリノード、1つの読み取り専用行ストアノード、および2つの読み取り専用列ストアノードが選択されています。この場合、システムは次のポリシーに基づいてクエリを配布します。
- 書き込み要求は、プライマリノードに配信されます。
- OLAP読み取り要求は、読み取り専用列ストアノードに配信されます。
- OLTP読み取り要求は、読み取り専用の行ストアノードに配信されます。 [SLB設定] セクションの [プライマリノードの読み取り要求の受け入れ] が [はい] に設定されている場合、OLTP読み取り要求もプライマリノードに配信される可能性があります。
例2: 次の図では、1つのプライマリノードと1つの読み取り専用列ストアノードが選択されています。自動リクエスト配信機能が有効になっている場合、書き込みリクエストとOLTP読み取りリクエストはプライマリノードに配信され、OLAP読み取りリクエストは読み取り専用列ストアノードに配信されます。
説明
読み書き モードでは、[ノード設定] セクションでプライマリノードが選択されているかどうかに関係なく、すべての書き込み要求はプライマリノードにのみ配信されます。

ステップ2: 自動リクエスト配信のしきい値を指定する

自動リクエスト配布を有効にした後、SQL文のスキャン行数のしきい値を指定する必要があります。しきい値が指定された後、データベースプロキシは、このしきい値に基づいて要求がどのノードに分配されるかを決定する。 SQLリクエストによってスキャンされた行の推定数がしきい値を超えると、リクエストは列ストアノードに配信されます。 SQLリクエストによってスキャンされた行の推定数がしきい値を超えない場合、リクエストは行ストアノードまたはプライマリノードに配信されます。

次の表に示すパラメーターは、実行コストに関連するしきい値を決定します。クラスターの パラメーター ページで、パラメーターの値を変更できます。

パラメーター	説明
loose_imci_ap_threshold	SQL文を列ストアノードに分散するかどうかを決定するしきい値。デフォルト値: 50000 説明たとえば、デフォルト値が使用されている場合、SQLステートメントによってスキャンされた行の数が50,000を超えると推定される場合、ステートメントは列ストアノードに配布されます。重要 `loose_cost_threshold_for_imci`パラメーターは、PolarDB for MySQL 8.0.1.xバージョン (8.0.1.1.39以降) および8.0.2.xバージョン (8.0.2.2.23以降) では、このパラメーターの代わりに使用されます。
loose_cost_threshold_for_imci	列ストアノードの列ストア実行プランを使用してSQL文を実行するかどうかを決定するしきい値。デフォルト値: 50000 説明たとえば、デフォルト値が使用されている場合、SQL文によってスキャンされた行の数が50,000を超えると推定される場合、列ストア実行プランを使用して文が実行されます。それ以外の場合、行ストア実行プランが使用されます。

SHOW STATUS LIKE 'Last_query_costステートメントを実行して、最後のSQLステートメントの推定実行コストを照会し、照会した値を使用してパラメーター値を変更できます。

説明

クラスターエンドポイントを使用してデータベースに接続する場合は、SHOW STATUS LIKE 'Last_query_cost 'ステートメントの前に /* ROUTE_TO_LAST_USED */ ヒントを追加して、最後のSQLステートメントの推定実行コストが期待されるノードで照会されるようにする必要があります。例を次に示します。

/* ROUTE_TO_LAST_USED */SHOW STATUS LIKE 'Last_query_cost ';

例：

SHOW STATUS LIKE 'Last_query_cost';

次の応答が返されます。

+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| Last_query_cost      | 2     |
+----------------------+-------+
1 row in set (0.01 sec)

クエリ結果は、SQL文の実行コストが2であることを示しています。

SQL文を列ストアノードに配布して列ストア実行プランを使用して実行するには、次のように設定します。

PolarDB for MySQL 8.0.1.1.38および8.0.2.2.22以前
loose_imci_ap_thresholdおよびloose_cost_threshold_for_imciパラメーターを1に設定します。
PolarDB for MySQL 8.0.1.1.39以降のバージョン8.0.1.xおよび8.0.2.2.23以降のバージョン8.0.2.x。
loose_cost_threshold_for_imciパラメーターを1に設定します。

列ストア実行プランまたは行ストア実行プランを使用して、`ヒント`を使用して要求を強制的に実行する

リクエストの自動配布の結果が期待どおりでない場合は、ヒントを使用して、列ストア実行プランまたは行ストア実行プランを使用してリクエストを強制的に実行できます。

説明

ヒントは、それが含まれているSQL文に対してのみ有効です。ヒントは、同じ接続内の他のステートメントまたは他の接続内のステートメントに対しては有効になりません。
MySQL 5.7.7以前を使用してヒントとともにステートメントを実行する場合は、データベースエンジンに接続するときに -- commentsオプションを追加する必要があります。 mysql -- versionコマンドを実行して、MySQLクライアントのバージョンを確認できます。

列ストア実行プランを使用してステートメントを強制的に実行する
- PolarDB for MySQL 8.0.1.1.38および8.0.2.2.22以前
  loose_imci_ap_thresholdの値に関係なく、列ストアノードにリクエストを強制的に配信する場合は、SQLキーワードの前に /* FORCE_IMCI_NODES */ ヒントを追加できます。例：
```
/* FORCE_IMCI_NODES */EXPLAIN SELECT COUNT(*) FROM t1 WHERE t1.a > 1;
```
  loose_cost_threshold_for_imciパラメーターの値に関係なく、カラムストア実行プランを使用してステートメントを強制的に実行する場合は、/* + SET_VAR(cost_threshold_for_imci=0)*/ ヒントをステートメントに追加することで、しきい値を0に変更できます。サンプル文:
```
/* FORCE_IMCI_NODES */EXPLAIN SELECT /* + SET_VAR(cost_threshold_for_imci=0) */ COUNT(*) FROM t1 WHERE t1.a > 1;
```
- PolarDB MySQL 8.0.1.1.39以降のバージョン8.0.1.xおよび8.0.2.2.23以降のバージョン8.0.2.x。
  hintsを使用して、loose_cost_threshold_for_imciパラメーターを0に設定します。
```
EXPLAIN SELECT /* + SET_VAR(cost_threshold_for_imci=0) */ COUNT(*) FROM t1 WHERE t1.a > 1;
```
説明
/* + SET_VAR()*/ を使用してしきい値を変更する場合は、パラメーター名のloose_ プレフィックスを省略する必要があります。それ以外の場合、ヒントは有効になりません。
行ストア実行プランを使用したステートメントの強制実行
行ストア実行プランを使用してステートメントを強制的に実行する場合は、/* + SET_VAR(USE_IMCI_ENGINE=OFF) * /ヒントをステートメントに追加できます。サンプル文:
```
EXPLAIN SELECT /* + SET_VAR(USE_IMCI_ENGINE=OFF) */ COUNT(*) FROM t1 WHERE t1.a > 1;
```

自動配布ソリューション

制限事項

ステップ1: 列ストアノードと行ストアノード間の自動リクエスト配信を有効にする

ステップ2: 自動リクエスト配信のしきい値を指定する

列ストア実行プランまたは行ストア実行プランを使用して、ヒントを使用して要求を強制的に実行する

列ストア実行プランまたは行ストア実行プランを使用して、`ヒント`を使用して要求を強制的に実行する