📣
TiDB Cloud Premium はパブリックプレビュー中です。エンタープライズワークロード向けの無制限のスケーリング、即時の弾力性、高度なセキュリティを提供します。このページは自動翻訳されたものです。原文はこちらからご覧ください。
AI
開発者向け
ベストプラクティス
API

リソース制御を使用して、リソースグループの制限とフロー制御を実現します。

注記：

この機能は、 TiDB Cloud StarterおよびTiDB Cloud Essentialインスタンスではご利用いただけません。

クラスタ管理者として、リソース制御機能を使用して、リソースグループの作成、リソースグループの割り当て量の設定、およびユーザーをそれらのグループにバインドすることができます。

TiDBのリソース制御機能は、TiDBレイヤーのフロー制御機能とTiKVレイヤーの優先度スケジューリング機能という2つのレイヤーのリソース管理機能を提供します。これらの2つの機能は、個別に、または同時に有効にすることができます。詳しくはリソース制御のためのパラメータについては を参照してください。これにより、TiDBレイヤーはリソースグループに設定されたクォータに基づいてユーザーの読み取りおよび書き込み要求のフローを制御し、TiKVレイヤーは読み取りおよび書き込みクォータにマッピングされた優先度に基づいて要求をスケジュールすることができます。この操作を行うことで、アプリケーションのリソース分離を確保し、サービス品質（QoS）要件を満たすことができます。

  • TiDBフロー制御：TiDBフロー制御は を使用します。バケットに十分なトークンがなく、リソースグループ トークンバケットアルゴリズムBURSTABLEオプションを指定していない場合、リソースグループへのリクエストはトークンバケットがトークンを補充するまで待機し、再試行します。再試行はタイムアウトにより失敗する可能性があります。

  • TiKV スケジューリング: 必要に応じて絶対優先度（ PRIORITY ）を設定できます。異なるリソースはPRIORITY設定に従ってスケジュールされます。 PRIORITYが高いタスクが最初にスケジュールされます。絶対優先度を設定しない場合、TiKV は各リソース グループのRU_PER_SECの値を使用して、各リソース グループの読み取りおよび書き込み要求の優先度を決定します。storageレイヤーは、優先度に基づいて優先度キューを使用して要求をスケジュールおよび処理します。

バージョン7.4.0以降、リソース制御機能はTiFlashリソースの制御をサポートしています。その原理は、TiDBフロー制御およびTiKVスケジューリングと同様です。

  • TiFlashフロー制御: TiFlashパイプライン実行モデルライン実行モデルを使用すると、 TiFlash はさまざまなクエリの CPU 消費量をより正確に取得し、それを要求単位数（RU）に変換して差し引くことができます。トラフィック制御はトークン バケット アルゴリズムを使用して実装されます。
  • TiFlashスケジューリング: システム リソースが不足している場合、 TiFlash は優先順位に基づいて複数のリソース グループ間でパイプライン タスクをスケジュールします。具体的なロジックは次のとおりです。まず、 TiFlash はリソース グループのPRIORITYを評価し、次に CPU 使用率とRU_PER_SECを考慮します。その結果、 rg1とrg2が同じPRIORITYを持ち、 RU_PER_SECのrg2がrg1の 2 倍である場合、 rg2の CPU 使用率はrg1の 2 倍になります。

バックグラウンドタスクの管理方法や、リソースを大量に消費するクエリ（暴走クエリ）の処理方法については、以下のドキュメントを参照してください。

リソース制御のシナリオ

リソース制御機能の導入は、TiDBにとって画期的な出来事です。この機能により、分散データベースクラスタを複数の論理ユニットに分割できます。たとえ個々のユニットがリソースを過剰に使用したとしても、他のユニットが必要とするリソースを圧迫することはありません。

この機能を使うと、次のことができます。

  • 異なるシステムに存在する複数の中小規模アプリケーションを単一のTiDBクラスタに統合します。アプリケーションのワークロードが増加しても、他のアプリケーションの正常な動作には影響しません。システムワークロードが低い場合、負荷の高いアプリケーションは設定されたクォータを超えても必要なシステムリソースを割り当てられるため、リソースを最大限に活用できます。
  • すべてのテスト環境を単一のTiDBクラスタに統合するか、より多くのリソースを消費するバッチタスクを単一のリソースグループにまとめるかを選択できます。これにより、ハードウェア利用率を向上させ、運用コストを削減しながら、重要なアプリケーションが常に必要なリソースを確保できるようになります。
  • システム内に複数のワークロードが存在する場合、異なるワークロードを別々のリソースグループに割り当てることができます。リソース制御機能を使用することで、トランザクションアプリケーションの応答時間がデータ分析やバッチ処理アプリケーションの影響を受けないようにすることができます。
  • クラスターで予期しないSQLパフォーマンスの問題が発生した場合、SQLバインディングとリソースグループを併用することで、SQLステートメントのリソース消費を一時的に制限できます。

さらに、リソース制御機能を合理的に活用することで、クラスタ数を削減し、運用・保守の難易度を下げ、管理コストを削減することができます。

注記：

  • リソース管理の有効性を評価するには、クラスタを独立したコンピューティングノードとstorageノードにデプロイすることをお勧めします。 tiup playgroundで作成されたデプロイメントでは、リソースがインスタンス間で共有されるため、スケジューリングやその他のクラスタのリソースに依存する機能が正しく動作しない場合があります。

制限事項

リソース制御にはスケジューリングのオーバーヘッドが加わるため、この機能を有効にするとパフォーマンスがわずかに低下する可能性があります（5%未満）。

リクエストユニット（RU）とは何ですか？

リクエストユニット（RU）は、TiDBにおけるシステムリソースの統一抽象化単位であり、現在CPU、IOPS、およびIO帯域幅メトリックが含まれています。これは、データベースへの単一のリクエストによって消費されるリソースの量を示すために使用されます。リクエストによって消費されるRUの数は、操作の種類や、クエリまたは変更されるデータの量など、さまざまな要因によって異なります。現在、RUには次の表に示すリソースの消費統計が含まれています。

リソースタイプRU消費量
読むstorage読み取りバッチ2つで1RUを消費します
8回のstorage読み取りリクエストで1RUを消費します
64 KiBの読み取りリクエストペイロードは1 RUを消費します
書くstorage書き込みバッチ1つにつき1RUを消費します
storage書き込みリクエスト1件につき1RUを消費します。
1 KiBの書き込みリクエストペイロードは1 RUを消費します
CPU 3ミリ秒で1RUを消費します

注記：

  • 各書き込み操作は最終的にすべてのレプリカに複製されます（デフォルトでは、TiKVには3つのレプリカがあります）。各複製操作は、それぞれ異なる書き込み操作として扱われます。
  • 上記の表には、TiDBセルフマネージドクラスタのRU計算に関わるリソースのみが記載されており、ネットワークとstorageの消費量は含まれていません。TiDB Cloud StarterのRUについては、 TiDB Cloud Starterの料金詳細参照してください。
  • 現在、 TiFlashのリソース制御では、SQL CPUのみが考慮されます。SQL CPUとは、クエリおよび読み取りリクエストのペイロードに対するパイプラインタスクの実行によって消費されるCPU時間です。

リソース制御のためのパラメータ

リソース制御機能では、以下のシステム変数またはパラメータが導入されます。

  • TiDB: tidb_enable_resource_controlシステム変数を使用して、リソースグループのフロー制御を有効にするかどうかを制御できます。
  • TiKV: resource-control.enabledパラメータを使用すると、リソース グループに基づいてリクエスト スケジューリングを使用するかどうかを制御できます。
  • TiFlash: TiFlashリソース制御を有効にするかどうかは、 tidb_enable_resource_controlシステム変数とenable_resource_control構成項目（v7.4.0で導入）を使用して制御できます。

TiDB v7.0.0以降、 tidb_enable_resource_controlとresource-control.enabledはデフォルトで有効になっています。これら2つのパラメータの組み合わせによる結果を次の表に示します。

resource-control.enabledtidb_enable_resource_control = オンtidb_enable_resource_control = オフ
resource-control.enabled = trueフロー制御とスケジューリング（推奨）無効な組み合わせ
resource-control.enabled = false流量制御のみ（推奨しません）この機能は無効になっています。

バージョン7.4.0以降、 TiFlash構成項目enable_resource_controlはデフォルトで有効になっています。これはtidb_enable_resource_controlと連携してTiFlash制御機能を制御します。TiFlashリソース制御は、 enable_resource_controlとtidb_enable_resource_controlの両方が有効になっている場合にのみ、フロー制御と優先度スケジューリングを実行します。さらに、 enable_resource_control有効になっている場合、 TiFlashはパイプライン実行モデルを使用します。

リソース制御メカニズムとパラメータの詳細については、 RFC: TiDBにおけるグローバルリソース制御およびTiFlashリソース制御参照してください。

リソース制御の使い方

このセクションでは、リソース制御機能を使用してリソースグループを管理し、各リソースグループのリソース割り当てを制御する方法について説明します。

クラスター容量を推定する

リソース計画を行う前に、クラスタ全体の容量を把握しておく必要があります。TiDB では、クラスタ容量を推定するためのCALIBRATE RESOURCEステートメントが提供されています。以下のいずれかの方法を使用できます。

TiDB ダッシュボードでリソースマネージャーページを表示できます。詳細については、 CALIBRATE RESOURCEを参照してください。

リソースグループを管理する

リソース グループを作成、変更、または削除するには、 SUPERまたはRESOURCE_GROUP_ADMIN権限が必要です。

CREATE RESOURCE GROUPコマンドを使用して、クラスターのリソース グループを作成できます。

既存のリソースグループの場合、 ALTER RESOURCE GROUPを使用して、リソースグループのRU_PER_SECオプション (1 秒あたりの RU バックフィル率) を変更できます。リソースグループへの変更は即座に有効になります。

DROP RESOURCE GROUPを使用してリソースグループを削除できます。

リソースグループを作成する

以下は、リソースグループを作成する方法の例です。

  1. リソースグループrg1を作成します。リソース制限は毎秒 500 RU で、このリソースグループ内のアプリケーションはリソースを超過することができます。

    CREATE RESOURCE GROUP IF NOT EXISTS rg1 RU_PER_SEC = 500 BURSTABLE;

  2. リソースグループrg2を作成します。RU バックフィルレートは毎秒 600 RU で、このリソースグループ内のアプリケーションがリソースをオーバーランすることを許可しません。

    CREATE RESOURCE GROUP IF NOT EXISTS rg2 RU_PER_SEC = 600;

  3. 絶対優先度をrg3 HIGHを作成します。現在の絶対優先度はLOW|MEDIUM|HIGHをサポートしています。デフォルト値はMEDIUMです。

    CREATE RESOURCE GROUP IF NOT EXISTS rg3 RU_PER_SEC = 100 PRIORITY = HIGH;

リソースグループをバインドする

TiDBは、以下の3つのレベルのリソースグループ設定をサポートしています。

  • ユーザーレベル。CREATE CREATE USERまたはALTER USERステートメントを使用して、ユーザーを特定のリソースグループにバインドします。ユーザーがリソースグループにバインドされると、そのユーザーが作成したセッションは自動的に対応するリソースグループにバインドされます。
  • セッションレベル。SET SET RESOURCE GROUPを使用して、現在のセッションのリソースグループを設定します。
  • ステートメントレベル。RESOURCE_GROUP RESOURCE_GROUP()オプティマイザヒントを使用して、現在のステートメントのリソースグループを設定します。

ユーザーをリソースグループにバインドする

次の例では、ユーザーusr1を作成し、そのユーザーをリソース グループrg1にバインドします。 rg1はリソースグループを作成するするの例で作成されたリソース グループです。

CREATE USER 'usr1'@'%' IDENTIFIED BY '123' RESOURCE GROUP rg1;

次の例ではALTER USERを使用して、ユーザーusr2をリソース グループrg2にバインドします。 rg2はリソースグループを作成するするの例で作成されたリソース グループです。

ALTER USER usr2 RESOURCE GROUP rg2;

ユーザーをバインドすると、新しく作成されたセッションのリソース消費は、指定されたクォータ（リクエストユニット、RU）によって制御されます。システムのワークロードが比較的高く、余裕のある容量がない場合、 usr2のリソース消費率は、クォータを超えないように厳密に制御されます。 usr1はrg1によってバインドされ、 BURSTABLEが設定されているため、 usr1の消費率はクォータを超えることが許可されます。

リソースグループに必要なリソースが不足するほどリクエストが多すぎる場合、クライアントのリクエストは待機状態になります。待機時間が長すぎると、リクエストはエラーを報告します。

注記：

  • CREATE USERまたはALTER USERを使用してユーザーをリソース グループにバインドすると、その設定はユーザーの既存のセッションには適用されず、ユーザーの新しいセッションにのみ適用されます。
  • TiDB はクラスタ初期化時にdefaultリソース グループを自動的に作成します。このリソース グループのRU_PER_SECのデフォルト値はUNLIMITED ( INT型の最大値、つまり2147483647に相当) で、 BURSTABLEモードです。リソース グループにバインドされていないステートメントは、自動的にこのリソース グループにバインドされます。このリソース グループは削除をサポートしていませんが、RU の設定を変更することはできます。

リソース グループからユーザーのバインドを解除するには、次のようにしてユーザーをdefaultグループに再度バインドするだけです。

ALTER USER 'usr3'@'%' RESOURCE GROUP `default`;

詳細については、 ALTER USER ... RESOURCE GROUP参照してください。

現在のセッションをリソースグループにバインドする

SET RESOURCE GROUPステートメントを使用すると、現在のセッションにバインドされているリソースグループを変更できます。セッションをリソースグループにバインドすると、対応するセッションのリソース使用量は、指定された使用量 (RU) によって制限されます。

システム変数tidb_resource_control_strict_mode ONに設定されている場合、このステートメントを実行するにはSUPERまたはRESOURCE_GROUP_ADMINまたはRESOURCE_GROUP_USERの権限が必要です。

次の例では、現在のセッションをリソースグループrg1にバインドします。

SET RESOURCE GROUP rg1;

現在のステートメントをリソースグループにバインドします。

SQL ステートメントにRESOURCE_GROUP(resource_group_name)ヒントを追加することで、ステートメントがバインドされるリソース グループを指定できます。このヒントはSELECT 、 INSERT 、 UPDATE 、およびDELETEステートメントをサポートします。

システム変数tidb_resource_control_strict_modeがONに設定されている場合、このヒントを使用するにはSUPERまたはRESOURCE_GROUP_ADMINまたはRESOURCE_GROUP_USERの権限が必要です。

次の例では、現在のステートメントをリソース グループrg1にバインドします。

SELECT /*+ RESOURCE_GROUP(rg1) */ * FROM t limit 10;

リソース制御を無効にする

  1. リソース制御機能を無効にするには、次のステートメントを実行してください。

    SET GLOBAL tidb_enable_resource_control = 'OFF';

  2. リソース グループの RU に基づくスケジューリングを無効にするには、TiKV パラメータresource-control.enabledをfalseに設定します。

  3. TiFlashのリソース制御を無効にするには、 TiFlash構成項目enable_resource_control falseに設定します。

RU消費量をビュー

RUの消費量に関する情報をご覧いただけます。

SQLによるRU消費量をビュー

SQL文のRU消費量は、以下の方法で確認できます。

  • システム変数tidb_last_query_info
  • EXPLAIN ANALYZE
  • 遅いクエリとそれに対応するシステムテーブル
  • statements_summary

システム変数tidb_last_query_infoを照会することで、前回のSQL実行で消費されたRUをビュー。

TiDBはシステム変数tidb_last_query_infoを提供します。このシステム変数には、最後に実行されたDMLステートメントの情報（SQL実行によって消費されたRUを含む）が記録されます。

例：

  1. UPDATEステートメントを実行します。

    UPDATE sbtest.sbtest1 SET k = k + 1 WHERE id = 1;

    Query OK, 1 row affected (0.01 sec)
Rows matched: 1  Changed: 1  Warnings: 0

  2. 最後に実行されたステートメントの情報を表示するには、システム変数tidb_last_query_info照会します。

    SELECT @@tidb_last_query_info;

    +------------------------------------------------------------------------------------------------------------------------+
| @@tidb_last_query_info                                                                                                 |
+------------------------------------------------------------------------------------------------------------------------+
| {"txn_scope":"global","start_ts":446809472210829315,"for_update_ts":446809472210829315,"ru_consumption":4.34885578125} |
+------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.01 sec)

    結果として、 ru_consumptionはこの SQL ステートメントの実行によって消費された RU です。

SQL実行中に消費されたRUをEXPLAIN ANALYZEでビュー

EXPLAIN ANALYZEステートメントを使用すると、SQL 実行中に消費される RU の量を取得できます。RU の量はキャッシュ (たとえば、コプロセッサキャッシュ) の影響を受けることに注意してください。同じ SQL を複数回実行すると、各実行で消費される RU の量は異なる場合があります。RU の値は各実行の正確な値を表すものではありませんが、推定の参考として使用できます。

遅いクエリとそれに対応するシステムテーブル

リソース制御を有効にすると、TiDB のスロークエリログと対応するシステム テーブルINFORMATION_SCHEMA.SLOW_QUERYには、リソース グループ、対応する SQL の RU 消費量、および利用可能な RU を待機した時間が含まれます。

RUの統計情報をstatements_summary別にビュー

TiDB のシステム テーブルINFORMATION_SCHEMA.statements_summaryには、SQL ステートメントの正規化および集計された統計情報が格納されます。このシステム テーブルを使用すると、SQL ステートメントの実行パフォーマンスを表示および分析できます。また、リソース グループ名、RU 消費量、利用可能な RU の待機時間など、リソース制御に関する統計情報も含まれています。詳細については、 statements_summaryフィールドの説明を参照してください。 説明

リソースグループのRU消費量をビュー

バージョン7.6.0以降、TiDBは各リソースグループのRU消費量の履歴レコードを保存するためのシステムテーブルmysql.request_unit_by_groupを提供します。

例：

SELECT * FROM request_unit_by_group LIMIT 5;

+----------------------------+----------------------------+----------------+----------+
| start_time                 | end_time                   | resource_group | total_ru |
+----------------------------+----------------------------+----------------+----------+
| 2024-01-01 00:00:00.000000 | 2024-01-02 00:00:00.000000 | default        |   334147 |
| 2024-01-01 00:00:00.000000 | 2024-01-02 00:00:00.000000 | rg1            |     4172 |
| 2024-01-01 00:00:00.000000 | 2024-01-02 00:00:00.000000 | rg2            |    34028 |
| 2024-01-02 00:00:00.000000 | 2024-01-03 00:00:00.000000 | default        |   334088 |
| 2024-01-02 00:00:00.000000 | 2024-01-03 00:00:00.000000 | rg1            |     3850 |
+----------------------------+----------------------------+----------------+----------+
5 rows in set (0.01 sec)

注記：

mysql.request_unit_by_groupのデータは、TiDB のスケジュールされたタスクによって毎日終了時に自動的にインポートされます。特定の日にリソース グループの RU 消費量が 0 の場合、レコードは生成されません。デフォルトでは、このテーブルには過去 3 か月 (最大 92 日) のデータが格納されます。この期間を超えるデータは自動的にクリアされます。

指標とグラフのモニタリング

TiDB はリソース制御に関する実行時情報を定期的に収集し、Grafana の[TiDB] > [リソース制御]ダッシュボードにメトリクスの視覚的なグラフを提供します。メトリクスについてはTiDBの重要な監視指標の「リソース制御」セクションで詳しく説明されています。

TiKV は、さまざまなリソース グループからのリクエスト QPS も記録します。詳細については、 TiKVモニタリング指標の詳細を参照してください。

TiDB ダッシュボードの現在のRESOURCE_GROUPSテーブルでリソース グループのデータを表示できます。詳しくはリソースマネージャーページをご覧ください。

ツールの互換性

リソース制御機能は、データのインポート、エクスポート、およびその他のレプリケーションツールの通常の使用には影響しませんBR、 TiDB Lightning、およびTiCDCは現在、リソース制御に関連するDDL操作の処理をサポートしておらず、リソース消費はリソース制御によって制限されません。

FAQ

  1. リソースグループを使用しない場合、リソース制御を無効にする必要がありますか？

    いいえ。リソースグループを指定しないユーザーは、リソースが無制限のdefaultリソースグループに自動的に割り当てられます。すべてのユーザーがdefaultリソースグループに属している場合、リソース割り当て方法は、リソース制御が無効になっている場合と同じです。

  2. データベースユーザーは複数のリソースグループに紐付けられますか？

    いいえ。データベースユーザーは1つのリソースグループにしかバインドできません。ただし、セッション実行時には、 SET RESOURCE GROUP使用して、現在のセッションで使用するリソースグループを設定できます。また、オプティマイザヒントRESOURCE_GROUP()を使用して、実行中のステートメントのリソースグループを設定することもできます。

  3. すべてのリソースグループの合計リソース割り当て（ RU_PER_SEC ）がシステム容量を超えた場合、どうなりますか？

    TiDB は、リソース グループを作成する際に容量を検証しません。システムに十分な利用可能なリソースがあれば、TiDB は各リソース グループのリソース要件を満たすことができます。システム リソースが制限を超えると、TiDB は優先度の高いリソース グループからの要求を満たすことを優先します。同じ優先度の要求すべてを満たすことができない場合、TiDB はリソース割り当て ( RU_PER_SEC ) に従ってリソースを比例的に割り当てます。

関連項目

TiDB Admin Lab 5: Using Resource Control with Mixed Workloads
ラボ
90 mins
詳しくはこちら ↗

このページは役に立ちましたか？