# リソース制御とデータベース統合 (v7.1)

### 概要
+ これらの演習を修了すると、TiDBのマルチテナント対応機能の1つであるリソース制御の操作経験を積むことができます。この特定の機能により、データベースユーザー間のリソース分離を実装できます。
+ 演習1では、リクエストクォータを管理してリソースコントロールを実践します。
+ 演習2では、複数のMySQL互換データベースのデータとワークロードを統合し、それらの間でリソースの分離とサービス品質対策を実施します。

  <img src="./diagram/2013E14Overview_ja_002_20230327.png" width="80%" align="top"/>

### 注意
+ リソース制御機能をサポートする最初のLTSはバージョン**7.1.0**です。
+ いくつかのステップでは、2つの異なるターミナルウィンドウでコマンドを入力する必要があります。2つのターミナルを起動し、演習の間ずっと開いておくと便利でしょう。
+ これらの演習では、`IP address`、`port number`、`username`、`password`、`directory`、および演習スクリプトの推定経過時間など、お客様の環境が異なる場合があります。
+ ターミナルウィンドウの"`$`"とはOSプロンプトです。
+ ターミナルウィンドウ内の "`tidb>`" または "`mysql>`" は、SQL コマンドプロンプトです。
+ これらの演習は、ノートパソコンなどの単一のマシン上で実行することができます。
+ これらの演習は、TiDB Playground クラスタとTiDBサーバーレス用に設計されています。TiDB Playground クラスタは本番用には設計されていないことに注意することが重要です。

### 前提条件
+ `tiup`と`mysql` コマンドラインクライアントをインストールしたか、演習「テスト用にTiDBクラスタを作成する」を完了していること。
+ macOSまたはLinuxを使用していること。
+ [GitHubのラボリポジトリ](https://github.com/pingcap/tidb-course-201-lab.git)のクローンを作成していること。

## 演習 1: リクエストクォータの管理

  <img src="./diagram/2013E141_ja_002_20230327.png" width="30%" align="top"/>

### 概要
+ この演習では、`RU_PER_SEC`属性を使用してリソースグループのリソースクォータを設定することで、`RU (Request Unit)`の概念に慣れます。
+ この演習では、`classroom-rc`という新しいタグが付いた TiDB Playground クラスタを作成します。

### 所要時間
+ この演習は約10分程度かかります。

### タスク
1. `classroom` Playground クラスタがまだ稼働している場合は、それを終了します。
2. リソース制御機能をサポートする特定のバージョンのTiDBで、`classroom-rc` タグが付いた新しいPlayground クラスタをデプロイします。
3. TiDBサーバーのリソース制御機能をオンにします。
4. 新しいユーザー、新しいリソースグループを作成し、それらのユーザーをそれぞれリソースグループに割り当てます。
5. リソース制御クォータ設定がユーザーセッションで有効になっていることを確認します。

### 手順
1. `classroom` Playground クラスタがまだ稼働している場合は、それを終了します。

   以前に`playground-start.sh`を実行したターミナルに移動します。画面はこのような感じです:
   ```
   ...
   Connect TiDB: mysql --comments --host 127.0.0.1 --port 4000 -u root
   TiDB Dashboard: http://127.0.0.1:2379/dashboard
   Grafana: http://127.0.0.1:56345
   ```


   `Ctrl-C`を1回押すと、Playground クラスタ全体が中止されます。PD、TiKV、TiDB、TiFlashのインスタンスはすべて終了します。
   ```
   ^CPlayground receive signal: interrupt
   Got signal interrupt (Component: playground ; PID: 47472)
   ...
   tikv quit
   ```


2. `tidb-course-201-lab/scripts`ディレクトリで、スクリプト`playground-start-rc.sh`を実行して、`classroom-rc` タグが付いた新しいPlayground クラスタをデプロイします。

   ```
   $ ./playground-start-rc.sh
   ```
   1. 別のターミナルで、`tidb-course-201-lab/scripts`ディレクトリで、スクリプト`connect-4000.sh`を実行して、ユーザー`root`としてTiDBにログインします。
   ```
   $ ./connect-4000.sh
   ```

4. リソース制御機能がTiDBサーバーレイヤーとTiKVサーバーレイヤーの両方で有効になっていることを確認します。

   ```sql
   SHOW GLOBAL VARIABLES LIKE 'tidb_enable_resource_control';
   SHOW CONFIG WHERE type='tikv' AND name='resource-control.enabled';
   ```
   ```
   tidb:4000> SHOW GLOBAL VARIABLES LIKE 'tidb_enable_resource_control';
   +------------------------------+-------+
   | Variable_name | Value |
   +------------------------------+-------+
   | tidb_enable_resource_control | ON |
   +------------------------------+-------+
   1 row in set (0.00 sec)

   tidb:4000> SHOW CONFIG WHERE type='tikv' AND name='resource-control.enabled';
   +------+-----------------+--------------------------+-------+
   | Type | Instance | Name | Value |
   +------+-----------------+--------------------------+-------+
   | tikv | 127.0.0.1:20160 | resource-control.enabled | true |
   +------+-----------------+--------------------------+-------+
   1 row in set (0.01 sec)
   ```

5. `p1_group`という名前の新しいリソースグループを作成し、そのバックフィルレートを`900`リクエスト/秒 (`RU`) に設定します。さらに、新しく作成したデータベースユーザー、`p1_user`をこのリソースグループに割り当てます。`RU`という略語は、`Request Unit`の略で、TiDBサーバーがリソースクォータを管理するために使用されます。
。詳細については、[`RU`](https://docs.pingcap.com/ja/tidb/stable/tidb-resource-control#what-is-request-unit-ru)ドキュメンテーションを確認してください。

   ```sql
   DROP RESOURCE GROUP IF EXISTS p1_group;
   CREATE RESOURCE GROUP p1_group RU_PER_SEC 900;
   CREATE USER p1_user IDENTIFIED BY 'tidb' RESOURCE GROUP p1_group;
   GRANT CREATE, DROP, SELECT, UPDATE, INSERT, REFERENCES on *.* to p1_user;
   ```
   ```
   tidb:4000> DROP RESOURCE GROUP IF EXISTS p1_group;
   Query OK, 0 rows affected (0.65 sec)

   tidb:4000> CREATE RESOURCE GROUP p1_group RU_PER_SEC 900;
   Query OK, 0 rows affected (0.62 sec)

   tidb:4000> CREATE USER p1_user IDENTIFIED BY 'tidb' RESOURCE GROUP p1_group;
   Query OK, 0 rows affected (0.19 sec)

   tidb:4000> GRANT CREATE, DROP, SELECT, UPDATE, INSERT on *.* to p1_user;
   Query OK, 0 rows affected (0.08 sec)
   ```

6. 1 秒あたり `RU` のバックフィルレート `100` で `p2_group` という名前のリソースグループを作成します。そして、新しいデータベースユーザー`p2_user`をそれに割り当てます。

   ```sql
   DROP RESOURCE GROUP IF EXISTS p2_group;
   CREATE RESOURCE GROUP p2_group RU_PER_SEC 100;
   CREATE USER p2_user IDENTIFIED BY 'tidb' RESOURCE GROUP p2_group;
   GRANT CREATE, DROP, SELECT, UPDATE, INSERT, REFERENCES on *.* to p2_user;
   SELECT name, ru_per_sec, priority, burstable FROM information_schema.resource_groups;
   SELECT user, host, user_attributes FROM mysql.user WHERE user LIKE 'p%';
   ```
   ```
   tidb:4000> DROP RESOURCE GROUP IF EXISTS p2_group;
   Query OK, 0 rows affected (0.65 sec)

   tidb:4000> CREATE RESOURCE GROUP p2_group RU_PER_SEC 100;
   Query OK, 0 rows affected (0.69 sec)

   tidb:4000> CREATE USER p2_user IDENTIFIED BY 'tidb' RESOURCE GROUP p2_group;
   Query OK, 0 rows affected (0.16 sec)

   tidb:4000> GRANT CREATE, DROP, SELECT, UPDATE, INSERT on *.* to p2_user;
   Query OK, 0 rows affected (0.12 sec)

   tidb:4000> SELECT name, ru_per_sec, priority, burstable FROM information_schema.resource_groups;
   +----------+------------+----------+-----------+
   | name | ru_per_sec | priority | burstable |
   +----------+------------+----------+-----------+
   | default | UNLIMITED | MEDIUM | YES |
   | p1_group | 900 | MEDIUM | NO |
   | p2_group | 100 | MEDIUM | NO |
   +----------+------------+----------+-----------+
   3 rows in set (0.00 sec)

   tidb:4000> SELECT user, host, user_attributes FROM mysql.user WHERE user LIKE 'p%';
   +---------+------+--------------------------------+
   | user | host | user_attributes |
   +---------+------+--------------------------------+
   | p1_user | % | {"resource_group": "p1_group"} |
   | p2_user | % | {"resource_group": "p2_group"} |
   +---------+------+--------------------------------+
   2 rows in set (0.03 sec)

   tidb:4000> exit;
   Bye
   $
   ```

7. `RU`の構成はステップ5の要件に対して低すぎるため、サンプルワークロードの実行中に、リソースグループ`p2_group`に属するユーザー`p2_user`がキューに入れられていることを確認します。

   `tidb-course-201-lab/scripts`ディレクトリで、ユーザー`p2_user`としてTiDBクラスタにログインし、テスト目的で`universe`スキーマを再作成します。
   ```
   $ mysql -h 127.0.0.1 -P 4000 -u p2_user -ptidb
   mysql>
   ```
   ```sql
   SELECT USER();
   SOURCE universe.sql
   ```
   ```
   mysql> SELECT USER();
   +-------------------+
   | user() |
   +-------------------+
   | p2_user@127.0.0.1 |
   +-------------------+
   1 row in set (0.00 sec)

   mysql> SOURCE universe.sql
   Query OK, 0 rows affected (0.00 sec)
   ...
   Records: 2 Duplicates: 0 Warnings: 0
   ```

   `SOURCE double-planets.sql`を約**8回**実行します。出力が`Query OK, 1280 rows affected`と表示されるのに、3秒以上かかるはずです。また、クォータ制限により失敗し、`ERROR 8252 (HY000): Exceeded resource group quota limitation`というエラーメッセージが表示されます。また、システムにはまだ大きな負荷がかかていませんが。ユーザー`p2_user`に対するこのような制約のあるサービス品質は、リソース管理の結果として予想されます。リソースグループ`p2_group` ユーザーは、`RU`のバックフィルの生成速度が毎秒100しかないため、TiDBサーバー上のCPUとIOリソースをあまり消費できません。
   ```sql
   SOURCE double-planets.sql
   ```
   ```
   mysql> SOURCE double-planets.sql
   Query OK, 1280 rows affected (4.53 sec)
   Records: 1280 Duplicates: 0 Warnings: 0
   ```

   ```
   mysql> exit;
   Bye
   $
   ```

8. 手順4での`RU`の設定は十分であるため、`p1_group`のリソースグループに所属する`p1_user`のユーザーは、リソースグループ設定以外の同じ条件で、より優れたパフォーマンスでワークロードを実行できることを確認します。

   TiDBクラスタにユーザー`p1_user`としてログインし、テスト用に`universe`スキーマを再作成します。
   ```
   $ mysql -h 127.0.0.1 -P 4000 -u p1_user -ptidb
   mysql>
   ```
   ```sql
   SELECT USER();
   SOURCE universe.sql
   ```
   ```
   mysql> SELECT USER();
   +--------------------+
   | user() |
   +--------------------+
   | p1_user@127.0.0.1 |
   +--------------------+
   1 row in set (0.00 sec)

   mysql> SOURCE universe.sql
   Query OK, 0 rows affected (0.00 sec)
   ...
   Records: 2 Duplicates: 0 Warnings: 0
   ```

   `SOURCE double-planets.sql`を再度約**8回**実行します。出力が`Query OK, 1280 rows affected`と表示されても、SQL文の実行が完了するまでに1秒もかからないはずです。リソース制御の結果として、ユーザー`p1_user` 良好なパフォーマンスも期待されます。
   ```sql
   SOURCE double-planets.sql
   ```
   ```
   mysql> SOURCE double-planets.sql
   Query OK, 1280 rows affected (0.41 sec)
   Records: 1280 Duplicates: 0 Warnings: 0
   ```

   ```
   mysql> exit;
   Bye
   $
   ```

9. `RU`の使い方を理解するには、`TiDB-Resource-Control` Grafanaダッシュボードにアクセスします。`http://127.0.0.1:3000/`を開き、ユーザー名`admin`とパスワード`admin`を入力します（パスワードを変更するように求められます）。`Test-Cluster-TiDB-Resource-Control`のダッシュボードを見つけてクリックします。

  <img src="./diagram/2013E141GrafanaResourceControl_aa_001_20230330.png" width="30%" align="top"/>

10. ダッシュボードでは、`RU`に関連する統計がリソースグループ別に分類されています。作成したリソースグループ（`p1_group`と`p2_group`）に加えて、デフォルトのリソースグループにも気付くかもしれません。これらの統計は、ワークロードの妥当な`RU`を見積もるのに役立ちます。

  <img src="./diagram/2013E141GrafanaResourceControlRU_aa_001_20230330.png" width="68%" align="top"/>

11. また、次のコマンドを使用して、システムの推定最大キャパシティを 1 秒あたりのリクエストユニット数で取得します。

    `root`としてログインします。
    ```
    $ ./connect-4000.sh
    ```

    `CALIBRATE`ステートメントを実行します。
    ```sql
    CALIBRATE RESOURCE;
    ```
    ```
    tidb:4000> CALIBRATE RESOURCE;
    +-------+
    | QUOTA |
    +-------+
    | 45712 |
    +-------+
    1 row in set (0.02 sec)
    ```

## 演習 2：データベースを TiDB に統合し、混合ワークロードに対する QoS ポリシーを適用する

  <img src="./diagram/2013E142_ja_001_20230327.png" width="40%" align="top"/>

### 概要
+ この演習では、さまざまなビジネスに役立つMySQL互換ソースの3つのデータベースを統合します。これらのデータベースには、`mydb`、`emp`、`universe`が含まれます。
+ `mydb`、`emp`、`universe` データベースには、3つの仮のワークロードランナーがあります。リソース消費のレベルにもよりますが、最も軽量なランナーは`universe`用で完了時間が最も速く、`mydb` ランナーは最も遅いです。`emp` ランナーはその中間です。
+ `mydb`、`emp`、`universe` データベースのリソースグループ設定は、それぞれのワークロードパターンをサポートし、ビジネスの観点からさまざまな優先順位を反映するように設定しました。
+ `RU_PER_SEC`に加えて、リソースグループの2つの属性、`PRIORITY`と`BURSTABLE`を使って練習します。

### 注意
+ この演習で使用したすべてのテスト結果は、ベンチマークではなく、シングルノードのTiUp Playgroundを介してリソースコントロールを使用するスキルを実証するためのものです。本番レベルのテストを実施したい場合は、[リンク]（https://pingcap.co.jp/contact-us/?utm_source=edu&utm_medium=referral&utm_campaign=201.3.E14）にアクセスしてデモリクエストをしてください。

### 所要時間
+ この演習は約10分程度かかります。

### タスク
1. 3つのデータベース`mydb`、`emp`、`universe`をTiDBに移行します。
2. 3つのデータベースにアクセスできる3つのデータベースユーザー`mydb_app`、`emp_app`、`universe_app` を作成します。
3. ユーザーを特定のリソースグループに割り当てて、ビジネス要件を満たすようにリソース管理ポリシーを適用します。

### 手順
1. この演習の目標を達成するために、`RU_PER_SEC`、`BURSTABLE`、`PRIORITY` 3つのリソースグループ属性を組み合わせて使用します。リソース制御ロジックは次のように動作します。

  <img src="./diagram/2013E142Logic_ja_001_20230327.png" width="50%" align="top"/>

2. TiDBとTiKVの両方のサーバーレイヤーのリソース制御機能がオンになっていることを確認します。

   ```sql
   SHOW GLOBAL VARIABLES LIKE 'tidb_enable_resource_control';
   SHOW CONFIG WHERE type='tikv' AND name='resource-control.enabled';
   ```
   ```
   tidb:4000> SHOW GLOBAL VARIABLES LIKE 'tidb_enable_resource_control';
   +------------------------------+-------+
   | Variable_name | Value |
   +------------------------------+-------+
   | tidb_enable_resource_control | ON |
   +------------------------------+-------+
   1 row in set (0.00 sec)

   tidb:4000> SHOW CONFIG WHERE type='tikv' AND name='resource-control.enabled';
   +------+-----------------+--------------------------+-------+
   | Type | Instance | Name | Value |
   +------+-----------------+--------------------------+-------+
   | tikv | 127.0.0.1:20160 | resource-control.enabled | true |
   +------+-----------------+--------------------------+-------+
   1 row in set (0.01 sec)
   ```

3. データインポートタスク用に`imp`という名前の新しいユーザーを作成します。

   ```sql
   CREATE USER imp@'%' IDENTIFIED BY 'q1w2e3R4_';
   GRANT ALL PRIVILEGES ON *.* TO imp@'%';
   ```
   ```
   tidb:4000> CREATE USER imp@'%' IDENTIFIED BY 'q1w2e3R4_';
   Query OK, 0 rows affected (0.06 sec)

   tidb:4000> GRANT ALL PRIVILEGES ON *.* TO imp@'%';
   Query OK, 0 rows affected (0.05 sec)
   ```
   ```
   tidb:4000> exit;
   Bye
   ```

4. ダンプファイルから`mydb`と`emp`のデータベースをインポートします。そして、SQLスクリプトから`universe`データベースをインポートします。

   ワーキングディレクトリを`misc/`に変更します。
   ```
   $ cd tidb-course-201-lab/scripts/misc/
   ```

   `mydb` データベースをTiDBにインポートします。
   ```
   $ rm -f /tmp/tidb_lightning_checkpoint.pb
   $ tiup tidb-lightning -config lightning-mydb.toml
   ```

   `emp` データベースをTiDBにインポートします。
   ```
   $ rm -f /tmp/tidb_lightning_checkpoint.pb
   $ tiup tidb-lightning -config lightning-emp.toml
   ```

   作業ディレクトリを`scripts/`に戻し、`universe`データベースをTiDBにインポートします。
   ```
   $ cd -
   $ ./connect-4000.sh
   ```

   ```sql
   SOURCE universe.sql
   ```
   ```
   tidb:4000> SOURCE universe.sql
   Query OK, 0 rows affected (0.00 sec)

   Query OK, 0 rows affected (0.00 sec)

   Query OK, 0 rows affected (0.24 sec)

   Database changed
   ...
   ```

`SHOW DATABASES`を実行して、`mydb`、`emp`、`universe` 3つのデータベースがインポートされたことを確認します。

   ```sql
   SHOW DATABASES;
   ```
   ```
   tidb:4000> SHOW DATABASES;
   +--------------------+
   | Database |
   +--------------------+
   | INFORMATION_SCHEMA |
   | METRICS_SCHEMA |
   | PERFORMANCE_SCHEMA |
   | emp |
   | mydb |
   | mysql |
   | test |
   | universe |
   +--------------------+
   8 rows in set (0.00 sec)
   ```


5. `universe`データベースは、古い内部アプリケーションのみをサポートし、事業運営に不可欠ではありません。システムが過負荷になった場合、アプリケーションの優先度は**低い**と見なすべきです。データベースにアクセスしている間に利用可能なすべてのシステムリソースを消費することは固く禁じられています。

   `universe`データベースアプリケーションのユーザーを作成します。
   ```sql
   CREATE USER universe_app IDENTIFIED BY 'tidb';
   GRANT ALL ON universe.* TO universe_app;
   ```
   ```
   tidb:4000> CREATE USER universe_app IDENTIFIED BY 'tidb';
   Query OK, 0 rows affected (0.05 sec)

   tidb:4000> GRANT ALL ON universe.* TO universe_app;
   Query OK, 0 rows affected (0.06 sec)
   ```
   `universe_group`という名前のリソースグループを作成します。システムが過負荷になっても優先度の低いクラスにとどまるには、`PRIORITY`を`LOW`に設定します。リクエストクォータの消費がオーバーフローするのを防ぐため、`BURSTABLE`を宣言しないでください。私たちのPlayground の例では、`universe`アプリケーションの`RU_PER_SEC`の推定値は`10`です。
   ```sql
   CREATE RESOURCE GROUP universe_group RU_PER_SEC=10 PRIORITY=LOW;
   ALTER USER universe_app RESOURCE GROUP universe_group;
   ```
   ```
   tidb:4000> CREATE RESOURCE GROUP universe_group RU_PER_SEC=10 PRIORITY=LOW;
   ALTER USER universe_app RESOURCE GROUP universe_group;
   Query OK, 0 rows affected (0.46 sec)

   tidb:4000> ALTER USER universe_app RESOURCE GROUP universe_group;
   Query OK, 0 rows affected (0.14 sec)
   ```

6. `mydb`データベースは、主にオンラインビジネスを対象としており、大量のQPSが発生します。`mydb`アプリケーションは、過負荷時に利用可能なすべてのシステムリソースを使い果たすことができます。私たちのPlayground の例では、`mydb`アプリケーションの`RU_PER_SEC`の推定値は`100`です。

   `mydb`データベースアプリケーションのユーザーを作成します。
   ```sql
   CREATE USER mydb_app IDENTIFIED BY 'tidb';
   GRANT ALL ON mydb.* TO mydb_app;
   ```
   ```
   tidb:4000> CREATE USER mydb_app IDENTIFIED BY 'tidb';
   Query OK, 0 rows affected (0.05 sec)

   tidb:4000> GRANT ALL ON mydb.* TO mydb_app;
   Query OK, 0 rows affected (0.06 sec)
   ```

   `mydb_group`という名前のリソースグループを作成します。`PRIORITY`を`HIGH`に設定して、`mydb_app`からのリクエストが常に最初にスケジュールされるようにします。リクエストクォータが過剰に消費可能にするには、`BURSTABLE`を宣言します。私たちのPlayground の例では、`mydb`アプリケーションの`RU_PER_SEC`の推定値は`100`です。
   ```sql
   CREATE RESOURCE GROUP mydb_group RU_PER_SEC=100 PRIORITY=HIGH BURSTABLE;
   ALTER USER mydb_app RESOURCE GROUP mydb_group;
   ```
   ```
   tidb:4000> CREATE RESOURCE GROUP mydb_group RU_PER_SEC=100 PRIORITY=HIGH BURSTABLE;
   Query OK, 0 rows affected (0.46 sec)
   tidb:4000> ALTER USER mydb_app RESOURCE GROUP mydb_group;
   Query OK, 0 rows affected (0.05 sec)
   ```

7. `emp`データベースは社内のERPに使用され、バッチジョブを頻繁に実行します。これらのバッチジョブ中に`mydb`アプリケーションのQPS に悪影響を及ぼすことはないはずです。`mydb`アプリケーションは、過負荷時に利用可能なすべてのシステムリソースを使い果たすことができます。私たちのPlayground の例では、`emp`アプリケーションの`RU_PER_SEC`の推定値は`800`です。

   `emp`データベースアプリケーションのユーザーを作成します。
   ```sql
   CREATE USER emp_app IDENTIFIED BY 'tidb';
   GRANT ALL ON emp.* TO emp_app;
   ```
   ```
   tidb:4000> CREATE USER emp_app IDENTIFIED BY 'tidb';
   Query OK, 0 rows affected (0.05 sec)

   tidb:4000> GRANT ALL ON emp.* TO emp_app;
   Query OK, 0 rows affected (0.06 sec)
   ```

   `emp_group`という名前のリソースグループを作成します。`emp`アプリケーションのバッチジョブが`mydb`アプリケーションに与える影響を最小限に抑えるには、`PRIORITY`を`MEDIUM`に設定します。リクエストクォータが過剰に消費可能にするには、`BURSTABLE`を宣言します。私たちのPlayground の例では、`emp`アプリケーションの`RU_PER_SEC`の推定値は`800`です。
   ```sql
   CREATE RESOURCE GROUP emp_group RU_PER_SEC=800 PRIORITY=MEDIUM BURSTABLE;
   ALTER USER emp_app RESOURCE GROUP emp_group;
   ```
   ```
   tidb:4000> CREATE RESOURCE GROUP emp_group RU_PER_SEC=800 PRIORITY=MEDIUM BURSTABLE;
   Query OK, 0 rows affected (0.68 sec)

   tidb:4000> ALTER USER emp_app RESOURCE GROUP emp_group;
   Query OK, 0 rows affected (0.06 sec)
   ```


8. データベースユーザーとリソースグループのリソース制御設定が期待される基準を満たしていることを確認します。ユーザー `universe_app` はバーストできないため、リソースクォータが最も制限されています。`mydb_app`と`emp_app` ユーザーはバースト可能であるため、システムに過負荷がかかると利用可能なすべてのリソースを消費する可能性があります。優先度の設定によると、リクエストクォータの設定（`RU_PER_SEC`）に関係なく、システムが過負荷になると、`mydb_app`からのリクエストは常に最初にスケジュールされます。

   ```sql
   SELECT u.user, u.host, u.user_attributes, r.name, r.ru_per_sec, r.burstable, r.priority
   FROM mysql.user u JOIN information_schema.resource_groups r
   ON r.name = u.user_attributes ->> '$.resource_group'
   WHERE u.user IN ('universe_app','emp_app','mydb_app')
   ORDER BY r.ru_per_sec DESC, r.burstable DESC;
   ```
   ```
   tidb:4000> SELECT u.user, u.host, u.user_attributes, r.name, r.ru_per_sec, r.burstable, r.priority
   -> FROM mysql.user u JOIN information_schema.resource_groups r
   -> ON r.name = u.user_attributes ->> '$.resource_group'
   -> WHERE u.user IN ('universe_app','emp_app','mydb_app')
   -> ORDER BY r.ru_per_sec DESC, r.burstable DESC;
   +--------------+------+--------------------------------------+----------------+------------+-----------+----------+
   | user | host | user_attributes | name | ru_per_sec | burstable | priority |
   +--------------+------+--------------------------------------+----------------+------------+-----------+----------+
   | emp_app | % | {"resource_group": "emp_group"} | emp_group | 800 | YES | MEDIUM |
   | mydb_app | % | {"resource_group": "mydb_group"} | mydb_group | 100 | YES | HIGH |
   | universe_app | % | {"resource_group": "universe_group"} | universe_group | 10 | NO | LOW |
   +--------------+------+--------------------------------------+----------------+------------+-----------+----------+
   3 rows in set (0.00 sec)
   ```

9. TiDB Playground クラスタ環境での私達の演習はここでやめなければなりません。ラップトップやシングルノードLinuxでは、システム負荷が高いため、`PRIORITY`と`BURSTABLE` 組み合わせを実証するのは難しいでしょう。そのため、製品レベルのテストやデモが必要な場合は、[ここをクリックしてお申し込みください](https://pingcap.co.jp/contact-us/?utm_source=edu&utm_medium=referral&utm_campaign=201.3.E14)。

## まとめ
TiDBは、一貫性のあるトランザクションをサポートするPBレベルの分散型RDBMS であることに注意します。また、これらの演習を通じてTiDBのリソース制御機能の使用経験を積むことで、MySQL互換データソースの複数のデータベースを1つのTiDBクラスタに統合することで、メンテナンスタスクを大幅に簡素化できます。これらの演習で実践したベストプラクティスに従うことで、TiDBのリソースグループに効果的に優先順位を付け、重要なワークロードには必要なリソースを受け取り、重要度の低いワークロードには必要に応じてリソースをアロケーションすることができます。優先度とクォータ制限のバランスを取り、リソースの使用状況を監視し、必要に応じて優先順位を調整することで、リソース配分を最適化し、システム全体のパフォーマンスを向上させることができます。

## 演習終わり