# HOTデータストレージとCOLDデータストレージの階層化の実装 ### 概要 + これらの演習では、TiDBのSQL配置ルール、つまりSQL文を使用してTiDB内のどこにデータを保存するかを指定できる機能について経験を積むことができます。 ### 注意 + いくつかのステップでは、2つの異なるターミナルウィンドウでコマンドを入力する必要があります。2つのターミナルを起動し、演習の間ずっと開いておくと便利でしょう。 + この演習で利用する、`IP`、`port`、`username`、`password`、`directory`などは、あなたの環境と異なる場合があります。 + ターミナルウィンドウの"`$`"とはOSプロンプトです。 + ターミナルウィンドウ内の "`tidb>`" または "`mysql>`" は、SQL コマンドプロンプトです。 + これらの演習は、ノートパソコンなどの単一のマシン上で実行することができます。 + この演習では、TiDB Playground クラスタを使用します。PD とTiKV のラベルを管理する必要があります。一方、TiDB Cloudでは、サービスとしてのデータベースによって管理されます。 + これらの演習で実践するステップはすべて、実際のクラスタ環境と同様です。本番環境のTiDBクラスタの管理方法をさらに学ぶには、[PingCAP Education](https://pingcap.co.jp/education/)が提供するデータベース管理者向けのコースを受講できます。TiDB Playground クラスタは本番用には設計されていないことに注意することが重要です。 ### 前提条件 + macOSまたはLinuxを使用していること。 + [lab repository](https://github.com/pingcap/tidb-course-201-lab.git)をクローン済みであること。 + 演習「テスト用にTiDBクラスタを作成する」を完了していること。 ## 演習 1：COLDとHOTデータの配置制御 ### 概要 + コスト効率を向上させるために、配置ルールを使用して、COLDデータを`lower-cost`ストレージ（または低パフォーマンスノード）に、HOTデータを`higher-cost`ストレージ（または高パフォーマンスノード）にテーブルパーティションで分ける練習をします。 ### 所要時間 + この演習は約30分程度かかります。 ### タスク 1. `classroom` Playground クラスタがまだ稼働している場合は、それを終了します。 2. `classroom-pr`のタグが付いた新しいPlayground クラスタをデプロイして、`lower-cost`と`higher-cost` 2つのストレージ構成でTiKVノードをシミュレートします。 3. HOTデータを`higher-cost`ストレージが接続されたTiKVノードに、COLDデータを`lower-cost`ストレージが接続されたTiKVノードに指定する配置ポリシーを作成します。 4. ストレージのコスト効率を最大化するために、前のステップの配置ポリシーを利用して、レンジパーティションテーブルを作成します。 5. 配置ルールが有効になっていることを確認します。 6. `classroom-pr`をタグの TiDB Playground クラスタを削除します。 ### 手順 1. `classroom` Playground クラスタがまだ稼働している場合は、それを終了します。 以前に`playground-start.sh`を実行したターミナルに移動します。画面はこのようになります。 ``` ... To view the dashboard: http://127.0.0.1:2379/dashboard PD client endpoints: [127.0.0.1:2379 127.0.0.1:2382 127.0.0.1:2384] To view the Prometheus: http://127.0.0.1:9090 To view the Grafana: http://127.0.0.1:3000 ``` `Ctrl-C`を1回押すと、Playground クラスタ全体が中止されます。PD、TiKV、TiDB、TiFlashのインスタンスはすべて終了します。 ``` ^CPlayground receive signal: interrupt Got signal interrupt (Component: playground ; PID: 47472) ... tikv quit ``` 2. TiKV ノードのシミュレーションとして機能し、2つの異なるストレージ構成を持つ`classroom-pr`タグが付いた新しいTiDB Playgroundクラスタをデプロイします。1つの構成は`lower-cost` COLDデータをホストするように設計されており、もう1つの構成は`higher-cost` HOTデータの処理に適しています。これらのストレージ構成には`storage-performance`キーのラベルを付けてください。この演習では、使われていない`region` ラベルキーは無視します。ただし、`"region"="tokyo"`は注目に値します。これは、TiKV ノードが東京に設置されていることを示しています。 作業ディレクトリ`tidb-course-201-lab/scripts`の下で、TiKV 設定ファイル`misc/label-storage-higher-cost.toml` 内容を確認します。TiKV ノードには、`(region, tokyo)`と`(storage-パフォーマンス, high)` 2つのラベルを追加できます。ラベルキーは`region`と`storage-パフォーマンス`、ラベル値は`tokyo`と`high`です。つまり、ラベルは東京に導入され、高パフォーマンス（コスト）のストレージが接続されているTiKVノードに適しています。 ``` $ cd tidb-course-201-lab/scripts $ cat misc/label-storage-higher-cost.toml [server] labels = {"region"="tokyo", "storage-performance"="high"} ``` 別のTiKV 設定ファイル`misc/label-storage-lower-cost.toml`を確認します。今回の`storage-パフォーマンス`の値は`low`で、`region`は`Tokyo`のままです。つまり、このラベルは東京に導入され、パフォーマンス（コスト）の低いストレージが接続されているTiKVノードに適しています。 ``` $ cat misc/label-storage-lower-cost.toml [server] labels = {"region"="tokyo", "storage-performance"="low"} ``` スクリプト`playground-init-classroom-pr-01.sh`を見直します。`classroom-pr`タグが付いた新しいPlaygroundをローカルマシンに配置（または再配置）できます。3つの`higher-cost`ストレージTiKVノードで初期化されることに注意します。各「ノード」または「インスタンス」は実際には同じローカルマシン上で実行されているため、これはシミュレーションであることに注意します。 ``` $ cat ./playground-init-classroom-pr-01.sh #!/bin/bash ~/.tiup/bin/tiup clean classroom-pr # Higher cost storage TiKV node + 3 sleep 1; ~/.tiup/bin/tiup playground v6.5.1 --tag classroom-pr \ --pd 1 \ --kv 3 \ --db 0 \ --tiflash 0 \ --without-monitor \ --kv.config ./misc/label-storage-higher-cost.toml ``` スクリプト `playground-init-classroom-pr-01.sh` を実行します。 ``` $ ./playground-init-classroom-pr-01.sh ... Start pd instance:v6.5.1 Start tikv instance:v6.5.1 Start tikv instance:v6.5.1 Start tikv instance:v6.5.1 ``` 別のターミナルに切り替えて、スクリプト`playground-init-classroom-pr-02.sh`を見直します。これにより、TiDBサーバーが1つ追加され、3つの`lower-cost`ストレージTiKVノードでPlayground 用のTiKV クラスタがスケールアウトされます。 ``` $ cd tidb-course-201-lab/scripts $ cat playground-init-classroom-pr-02.sh #!/bin/bash # Adding one TiDB server ~/.tiup/bin/tiup playground scale-out --db 1 # Lower cost storage TiKV node + 3 sleep 1; ~/.tiup/bin/tiup playground scale-out --kv 3 --kv.config ./misc/label-storage-lower-cost.toml ~/.tiup/bin/tiup playground display ``` `playground-init-classroom-pr-02.sh` スクリプトを実行し、完了すると、合計6つのTiKVインスタンスが作成され、そのうち3つはストレージパフォーマンスが高く、3つは低いとラベル付けされます。 ``` $ ./playground-init-classroom-pr-02.sh ... Pid Role Uptime --- ---- ------ 95771 pd 1m16.365078657s 95772 tikv 1m16.297747426s 95773 tikv 1m16.234072579s 95774 tikv 1m16.16758214s 95819 tikv 905.153455ms 95820 tikv 839.390523ms 95821 tikv 775.561918ms 95807 tidb 22.953849065s ``` 3. HOTデータを`higher-cost`ストレージが接続されたTiKVノード（3つ）に、COLDデータを`lower-cost`ストレージが接続されたTiKVノード（3つ）に指定する配置ポリシーを作成します。 TiDBサーバーにルートで接続します。 ``` $ ./connect-4000.sh tidb:4000> ``` Playground のTiKV リージョンレプリカ設定を3にします。これは、ほとんどの本番環境のレプリカの最小設定です。 ```sql SET CONFIG PD replication.max-replicas = 3; ``` ``` tidb:4000> SET CONFIG PD replication.max-replicas = 3; Query OK, 0 rows affected (0.03 sec) ``` 配置ルールに使用できるラベルを確認します。`storage-performance` キーが付いたラベルに注意します。今のところ、`engine`と`region`は無視しても大丈夫です。 ```sql SHOW PLACEMENT LABELS; ``` ``` tidb:4000> SHOW PLACEMENT LABELS; +---------------------+-----------------+ | Key | Values | +---------------------+-----------------+ | region | ["tokyo"] | | storage-performance | ["high", "low"] | +---------------------+-----------------+ 3 rows in set (0.01 sec) ``` 利用可能なラベルとそれに対応するTiKVストアを確認します。`store_id`カラムはTiKVストアIDを表し、`label`カラムは各TiKVストアのラベル付きキーバリューを示していることに注意します。 ```sql SELECT store_id, address, store_state_name, label FROM information_schema.tikv_store_status; ``` ``` tidb:4000> SELECT store_id, address, store_state_name, label -> FROM information_schema.tikv_store_status; +----------+-----------------+------------------+----------------------------------------------------------------------------------------+ | store_id | address | store_state_name | label | +----------+-----------------+------------------+----------------------------------------------------------------------------------------+ | 1 | 127.0.0.1:20162 | Up | [{"key": "region", "value": "tokyo"}, {"key": "storage-performance", "value": "high"}] | | 4 | 127.0.0.1:20161 | Up | [{"key": "region", "value": "tokyo"}, {"key": "storage-performance", "value": "high"}] | | 5 | 127.0.0.1:20160 | Up | [{"key": "region", "value": "tokyo"}, {"key": "storage-performance", "value": "high"}] | | 136 | 127.0.0.1:49829 | Up | [{"key": "region", "value": "tokyo"}, {"key": "storage-performance", "value": "low"}] | | 137 | 127.0.0.1:49831 | Up | [{"key": "region", "value": "tokyo"}, {"key": "storage-performance", "value": "low"}] | | 138 | 127.0.0.1:49837 | Up | [{"key": "region", "value": "tokyo"}, {"key": "storage-performance", "value": "low"}] | +----------+-----------------+------------------+----------------------------------------------------------------------------------------+ 6 rows in set (0.00 sec) ``` HOTデータのプレースメントポリシーを作成し、それをラベルのキーと値のペア`(storage-performance, high)`にマッピングします。 ```sql DROP PLACEMENT POLICY IF EXISTS hot; CREATE PLACEMENT POLICY hot CONSTRAINTS="[+storage-performance=high]"; ``` ``` tidb:4000> DROP PLACEMENT POLICY IF EXISTS hot; Query OK, 0 rows affected, 1 warning (0.00 sec) tidb:4000> CREATE PLACEMENT POLICY hot -> CONSTRAINTS="[+storage-performance=high]"; Query OK, 0 rows affected (0.07 sec) ``` COLDデータのプレースメントポリシーを作成し、それをラベルのキーと値のペア`(storage-performance, low)`にマッピングします。 ```sql DROP PLACEMENT POLICY IF EXISTS cold; CREATE PLACEMENT POLICY cold CONSTRAINTS="[+storage-performance=low]"; ``` ``` tidb:4000> DROP PLACEMENT POLICY IF EXISTS cold; Query OK, 0 rows affected, 1 warning (0.01 sec) tidb:4000> CREATE PLACEMENT POLICY cold -> CONSTRAINTS="[+storage-performance=low]"; Query OK, 0 rows affected (0.07 sec) ``` 作成した配置ポリシー、`HOT`と`COLD`の制約定義を確認します。 ```sql SELECT policy_name, constraints FROM information_schema.placement_policies; ``` ``` tidb:4000> SELECT policy_name, constraints FROM information_schema.placement_policies; +-------------+-----------------------------+ | policy_name | constraints | +-------------+-----------------------------+ | hot | [+storage-performance=high] | | cold | [+storage-performance=low] | +-------------+-----------------------------+ 2 rows in set (0.00 sec) ``` 4. ストレージのコスト効率を最大化するために、前のステップで配置ポリシーを利用して2つの範囲パーティションテーブルを作成します。1つは`HOT-COLD`パーティションで、もう1つはCOLD専用パーティションです。 `HOT`と`COLD`の配置ポリシーを使用して、パーティションテーブル`test.orders`を作成します。`order_date`注文は、2010年以前と2010年から2015年の間（排他的）に`COLD`とマークされ、2015年以降には`MAXVALUE`パーティションにマップされる`HOT`とマークされます。 ```sql DROP TABLE IF EXISTS test.orders; CREATE TABLE test.orders (order_id INT, item VARCHAR(50), order_date DATE, PRIMARY KEY (order_date, order_id)) PARTITION BY RANGE( YEAR(order_date) ) ( PARTITION p10 VALUES LESS THAN (2010) PLACEMENT POLICY=cold, PARTITION p15 VALUES LESS THAN (2015) PLACEMENT POLICY=cold, PARTITION pm VALUES LESS THAN MAXVALUE PLACEMENT POLICY=hot ); ``` ``` tidb:4000> DROP TABLE IF EXISTS test.orders; Query OK, 0 rows affected, 1 warning (0.00 sec) tidb:4000> CREATE TABLE test.orders (order_id INT, item VARCHAR(50), order_date DATE, PRIMARY KEY (order_date, order_id)) -> PARTITION BY RANGE( YEAR(order_date) ) ( -> PARTITION p10 VALUES LESS THAN (2010) PLACEMENT POLICY=cold, -> PARTITION p15 VALUES LESS THAN (2015) PLACEMENT POLICY=cold, -> PARTITION pm VALUES LESS THAN MAXVALUE PLACEMENT POLICY=hot -> ); Query OK, 0 rows affected (0.34 sec) ``` すべてのパーティション`COLD`配置ポリシーのみを使用して、パーティションテーブル`test.orders_log`を作成します。 ```sql DROP TABLE IF EXISTS test.orders_log; CREATE TABLE test.orders_log (order_id INT, item VARCHAR(50), order_date DATE, PRIMARY KEY (order_date, order_id)) PARTITION BY RANGE( YEAR(order_date) ) ( PARTITION p10 VALUES LESS THAN (2010) PLACEMENT POLICY=cold, PARTITION p15 VALUES LESS THAN (2015) PLACEMENT POLICY=cold, PARTITION pm VALUES LESS THAN MAXVALUE PLACEMENT POLICY=cold ); ``` ``` tidb:4000> DROP TABLE IF EXISTS test.orders_log; Query OK, 0 rows affected, 1 warning (0.00 sec) tidb:4000> CREATE TABLE test.orders_log (order_id INT, item VARCHAR(50), order_date DATE, PRIMARY KEY (order_date, order_id)) -> PARTITION BY RANGE( YEAR(order_date) ) ( -> PARTITION p10 VALUES LESS THAN (2010) PLACEMENT POLICY=cold, -> PARTITION p15 VALUES LESS THAN (2015) PLACEMENT POLICY=cold, -> PARTITION pm VALUES LESS THAN MAXVALUE PLACEMENT POLICY=cold -> ); Query OK, 0 rows affected (0.38 sec) ``` 5. 配置ルールが有効になっていることを確認します。 `HOT-COLD`テーブル`test.orders` TiKV リージョン情報を表示します。`START_KEY`が最も大きい`REGION_ID`に注目します。それは`MAXVALUE` パーティションです。環境によっては、リージョンIDと開始キーの番号が異なる場合があることに注意します。 ```sql SHOW TABLE test.orders REGIONS\G ``` ``` tidb:4000> SHOW TABLE test.orders REGIONS\G -------------- SHOW TABLE test.orders REGIONS -------------- *************************** 1. row *************************** REGION_ID: 199 START_KEY: t_83_ END_KEY: t_84_ LEADER_ID: 211 LEADER_STORE_ID: 182 PEERS: 211, 216, 218 SCATTERING: 0 WRITTEN_BYTES: 136 READ_BYTES: 0 APPROXIMATE_SIZE(MB): 1 APPROXIMATE_KEYS: 0 SCHEDULING_CONSTRAINTS: CONSTRAINTS="[+storage-performance=low]" SCHEDULING_STATE: SCHEDULED *************************** 2. row *************************** REGION_ID: 203 START_KEY: t_84_ END_KEY: t_85_ LEADER_ID: 212 LEADER_STORE_ID: 182 PEERS: 212, 217, 220 SCATTERING: 0 WRITTEN_BYTES: 136 READ_BYTES: 0 APPROXIMATE_SIZE(MB): 1 APPROXIMATE_KEYS: 0 SCHEDULING_CONSTRAINTS: CONSTRAINTS="[+storage-performance=low]" SCHEDULING_STATE: SCHEDULED *************************** 3. row *************************** REGION_ID: 207 START_KEY: t_85_ END_KEY: t_86_ LEADER_ID: 210 LEADER_STORE_ID: 3 PEERS: 208, 209, 210 SCATTERING: 0 WRITTEN_BYTES: 39 READ_BYTES: 0 APPROXIMATE_SIZE(MB): 1 APPROXIMATE_KEYS: 0 SCHEDULING_CONSTRAINTS: CONSTRAINTS="[+storage-performance=high]" SCHEDULING_STATE: SCHEDULED 3 rows in set (0.02 sec) ``` テーブル`test.orders` リージョンとTiKV ストアのマッピングが配置ポリシーと一致していることを確認します。配置ルールによると、`REGION_ID` 207のリージョンは`storage-performance:high` のTiKV ノードにマップする必要があります。一方、他の2つのリージョン、199と203は`storage-performance:low` TiKV ノードにマップする必要があります。 ```sql SELECT kvrs.region_id, kvss.store_id, kvrp.is_leader, kvss.label, kvss.start_ts FROM information_schema.tikv_region_status kvrs JOIN information_schema.tikv_region_peers kvrp ON kvrs.region_id = kvrp.region_id JOIN information_schema.tikv_store_status kvss ON kvrp.store_id = kvss.store_id JOIN information_schema.tables t ON t.table_name = kvrs.table_name WHERE t.table_schema='test' AND t.table_name='orders' AND kvrs.is_index = 0 AND kvrp.is_leader = 1; ``` ``` tidb:4000> SELECT kvrs.region_id, kvss.store_id, kvrp.is_leader, kvss.label, kvss.start_ts ... -------------- +-----------+----------+-----------+----------------------------------------------------------------------------------------+---------------------+ | region_id | store_id | is_leader | label | start_ts | +-----------+----------+-----------+----------------------------------------------------------------------------------------+---------------------+ | 203 | 182 | 1 | [{"key": "region", "value": "tokyo"}, {"key": "storage-performance", "value": "low"}] | 2023-06-21 10:42:46 | | 199 | 182 | 1 | [{"key": "region", "value": "tokyo"}, {"key": "storage-performance", "value": "low"}] | 2023-06-21 10:42:46 | | 207 | 3 | 1 | [{"key": "region", "value": "tokyo"}, {"key": "storage-performance", "value": "high"}] | 2023-06-21 10:40:26 | +-----------+----------+-----------+----------------------------------------------------------------------------------------+---------------------+ 3 rows in set (0.04 sec) ``` `COLD`データのみのテーブル`test.orders_log` TiKV リージョン情報を表示します。すべてのリージョンの`REGION_ID`に注意します。出力例では、226、230、234です（環境によっては、リージョンIDとスタートキーの番号が異なる場合があることに注意します）。 ```sql SHOW TABLE test.orders_log REGIONS\G ``` ``` tidb:4000> SHOW TABLE test.orders_log REGIONS\G -------------- SHOW TABLE test.orders_log REGIONS -------------- *************************** 1. row *************************** REGION_ID: 226 START_KEY: t_88_ END_KEY: t_89_ LEADER_ID: 239 LEADER_STORE_ID: 182 PEERS: 239, 247, 250 SCATTERING: 0 WRITTEN_BYTES: 136 READ_BYTES: 0 APPROXIMATE_SIZE(MB): 1 APPROXIMATE_KEYS: 0 SCHEDULING_CONSTRAINTS: CONSTRAINTS="[+storage-performance=low]" SCHEDULING_STATE: SCHEDULED *************************** 2. row *************************** REGION_ID: 230 START_KEY: t_89_ END_KEY: t_90_ LEADER_ID: 238 LEADER_STORE_ID: 182 PEERS: 238, 245, 248 SCATTERING: 0 WRITTEN_BYTES: 136 READ_BYTES: 0 APPROXIMATE_SIZE(MB): 1 APPROXIMATE_KEYS: 0 SCHEDULING_CONSTRAINTS: CONSTRAINTS="[+storage-performance=low]" SCHEDULING_STATE: SCHEDULED *************************** 3. row *************************** REGION_ID: 234 START_KEY: t_90_ END_KEY: t_91_ LEADER_ID: 240 LEADER_STORE_ID: 182 PEERS: 240, 252, 253 SCATTERING: 0 WRITTEN_BYTES: 136 READ_BYTES: 0 APPROXIMATE_SIZE(MB): 1 APPROXIMATE_KEYS: 0 SCHEDULING_CONSTRAINTS: CONSTRAINTS="[+storage-performance=low]" SCHEDULING_STATE: SCHEDULED 3 rows in set (0.01 sec) ``` テーブル`test.orders_log` リージョンとTiKV ストアのマッピングが配置ポリシーと一致していることを確認します。配置ルールによると、すべてのリージョンを`storage-performance:low` TiKV ノードにマッピングする必要があります。 ```sql SELECT kvrs.region_id, kvss.store_id, kvrp.is_leader, kvss.label, kvss.start_ts FROM information_schema.tikv_region_status kvrs JOIN information_schema.tikv_region_peers kvrp ON kvrs.region_id = kvrp.region_id JOIN information_schema.tikv_store_status kvss ON kvrp.store_id = kvss.store_id JOIN information_schema.tables t ON t.table_name = kvrs.table_name WHERE t.table_schema='test' AND t.table_name='orders_log' AND kvrs.is_index = 0 AND kvrp.is_leader = 1; ``` ``` ... -------------- +-----------+----------+-----------+---------------------------------------------------------------------------------------+---------------------+ | region_id | store_id | is_leader | label | start_ts | +-----------+----------+-----------+---------------------------------------------------------------------------------------+---------------------+ | 230 | 182 | 1 | [{"key": "region", "value": "tokyo"}, {"key": "storage-performance", "value": "low"}] | 2023-06-21 10:42:46 | | 234 | 182 | 1 | [{"key": "region", "value": "tokyo"}, {"key": "storage-performance", "value": "low"}] | 2023-06-21 10:42:46 | | 226 | 182 | 1 | [{"key": "region", "value": "tokyo"}, {"key": "storage-performance", "value": "low"}] | 2023-06-21 10:42:46 | +-----------+----------+-----------+---------------------------------------------------------------------------------------+---------------------+ 3 rows in set (0.02 sec) ``` クエリトレースを実行して、テーブル `test.orders` のパーティションプルーニングを確認します。2013年のデータをクエリしているので、COLDストレージでのクエリスキャンが予想されます。出力から、リージョンIDが203のリージョンがスキャンされていることがわかります。このリージョンは、`storage-performance:low` ラベルが付いたTiKV ノードにあります。 ```sql TRACE SELECT item, order_date FROM test.orders WHERE order_date BETWEEN STR_TO_DATE('01/01/2013', '%m/%d/%Y') AND STR_TO_DATE('12/31/2013', '%m/%d/%Y'); ``` ``` tidb:4000> TRACE -> SELECT item, order_date FROM test.orders -> WHERE order_date BETWEEN STR_TO_DATE('01/01/2013', '%m/%d/%Y') AND STR_TO_DATE('12/31/2013', '%m/%d/%Y'); +----------------------------------------------------------------+-----------------+------------+ | operation | startTS | duration | +----------------------------------------------------------------+-----------------+------------+ | trace | 00:47:24.951954 | 8.606975ms | | ├─session.ExecuteStmt | 00:47:24.951965 | 5.072329ms | | │ ├─executor.Compile | 00:47:24.951984 | 3.676066ms | | │ └─session.runStmt | 00:47:24.956317 | 687.5µs | | └─*executor.IndexLookUpExecutor.Next | 00:47:24.957047 | 3.483774ms | | └─distsql.Select | 00:47:24.957089 | 26.993µs | | └─regionRequest.SendReqCtx | 00:47:24.957484 | 2.998185ms | | └─rpcClient.SendRequest, region ID: 203, type: Cop | 00:47:24.958109 | 2.038166ms | +----------------------------------------------------------------+-----------------+------------+ 8 rows in set (0.02 sec) ``` クエリトレースを実行して、テーブル `test.orders` のパーティションプルーニングを再度確認します。2018年から2020年の間にデータをクエリするので、HOTストレージでのクエリスキャンが予想されます。出力から、リージョンIDが207のリージョンがスキャンされていることがわかります。このリージョンは、`storage-performance:high` ラベルが付いたTiKV ノードにあります。 ```sql TRACE SELECT item, order_date FROM test.orders WHERE order_date BETWEEN STR_TO_DATE('01/01/2018', '%m/%d/%Y') AND STR_TO_DATE('12/31/2020', '%m/%d/%Y'); ``` ``` tidb:4000> TRACE -> SELECT item, order_date FROM test.orders -> WHERE order_date BETWEEN STR_TO_DATE('01/01/2018', '%m/%d/%Y') AND STR_TO_DATE('12/31/2020', '%m/%d/%Y'); +----------------------------------------------------------------+-----------------+------------+ | operation | startTS | duration | +----------------------------------------------------------------+-----------------+------------+ | trace | 00:48:02.290148 | 2.240812ms | | ├─session.ExecuteStmt | 00:48:02.290152 | 446.907µs | | │ ├─executor.Compile | 00:48:02.290168 | 308.025µs | | │ └─session.runStmt | 00:48:02.290495 | 83.827µs | | └─*executor.IndexLookUpExecutor.Next | 00:48:02.290609 | 1.749ms | | └─distsql.Select | 00:48:02.290653 | 35.851µs | | └─regionRequest.SendReqCtx | 00:48:02.290745 | 1.567311ms | | └─rpcClient.SendRequest, region ID: 207, type: Cop | 00:48:02.290763 | 1.510832ms | +----------------------------------------------------------------+-----------------+------------+ 8 rows in set (0.01 sec) ``` 時間があれば、`test.orders_log`というテーブルに対して同様のクエリを試してみてください。このテーブルは、COLD TiKV ノードにしかアクセスできません。 5. `classroom-pr`をタグの接頭辞に持つすべてのPlaygroundファイルを削除するには、コマンド`tiup clean classroom-pr`を実行します。 `classroom-pr`Playground が動作しているターミナルで、`Ctrl-C`を1回押して、Playground クラスタ全体を中止します。PD、TiKV、TiDBのインスタンスはすべて終了します。画面は次のようになります。 ``` Ctrl-C ``` ``` ^CPlayground receive signal: interrupt Got signal interrupt (Component: playground ; PID: 96359) ``` `tiup clean`を実行して、`classroom-pr`Playground のデータフォルダをクリアします。 ``` $ ~/.tiup/bin/tiup clean classroom-pr Clean instance of `playground`, directory: /Users/username/.tiup/data/classroom-pr ``` ## 補足 この演習は、シングルノードマシン上のTiDB Playground クラスタ環境を介して実行することを目的としており、本番環境には適していません。本番環境でより高度なテストやデモンストレーションが必要な場合は、[提供されているリンクをクリック](https://pingcap.co.jp/contact-us/?utm_source=edu&utm_medium=referral&utm_campaign=201.3.E10) してお問い合わせください。 ## 演習終わり