TiDB HTAPのクイック スタート ガイド
このガイドでは、ハイブリッド トランザクションおよび分析処理 (HTAP) の TiDB のワンストップ ソリューションを開始するための最も簡単な方法について説明します。
ノート：
このガイドに記載されている手順は、テスト環境でのクイック スタート専用です。本番環境では、 HTAP を調べるをお勧めします。
基本概念
TiDB HTAPを使用する前に、 TiKV 、TiDB Online Transactional Processing (OLTP) 用の行ベースのストレージ エンジン、およびティフラッシュ 、TiDB Online Analytical Processing (OLAP) 用の列型ストレージ エンジンに関する基本的な知識が必要です。
- HTAP のストレージ エンジン: HTAP では、行ベースのストレージ エンジンと列ベースのストレージ エンジンが共存します。どちらのストレージ エンジンもデータを自動的にレプリケートし、強力な整合性を維持できます。行ベースのストレージ エンジンは OLTP のパフォーマンスを最適化し、列ベースのストレージ エンジンは OLAP のパフォーマンスを最適化します。
- HTAP のデータ整合性: 分散型のトランザクション キー値データベースとして、TiKV はACID準拠のトランザクション インターフェイスを提供し、複数のレプリカ間のデータ整合性とRaftコンセンサスアルゴリズムの実装による高可用性を保証します。 TiKV のカラムナ ストレージ拡張として、TiFlash はRaft Learner コンセンサス アルゴリズムに従ってリアルタイムで TiKV からデータをレプリケートします。
- HTAP のデータ分離: HTAP リソースの分離の問題を解決するために、必要に応じて TiKV と TiFlash を異なるマシンに展開できます。
- MPP コンピューティング エンジン: MPPは、TiDB 5.0 以降の TiFlash エンジンによって提供される分散コンピューティング フレームワークであり、ノード間のデータ交換を可能にし、高性能で高スループットの SQL アルゴリズムを提供します。 MPP モードでは、分析クエリの実行時間を大幅に短縮できます。
手順
このドキュメントでは、 TPC-Hのデータセットでサンプル テーブルをクエリすることにより、 TiDB HTAPの利便性と高性能を体験できます。 TPC-H は、大量のデータと非常に複雑な一連のビジネス指向のアドホック クエリで構成される、一般的な意思決定支援ベンチマークです。 TPC-H を使用して 22 個の完全な SQL クエリを体験するには、 tidb-bench リポジトリまたはTPC-Hにアクセスして、クエリ ステートメントとデータを生成する方法を確認してください。
ステップ 1. ローカル テスト環境をデプロイする
TiDB HTAPを使用する前に、 TiDB データベース プラットフォームのクイック スタート ガイドの手順に従ってローカル テスト環境を準備し、次のコマンドを実行して TiDB クラスターをデプロイします。
tiup playground
ノート：
tiup playgroundコマンドは、本番用ではなく、クイック スタート専用です。
ステップ 2. テスト データの準備
次の手順では、 TiDB HTAPを使用するためのテスト データとしてTPC-Hのデータセットを作成できます。 TPC-H に興味がある場合は、 一般的な実装ガイドラインを参照してください。
ノート：
分析クエリに既存のデータを使用する場合は、次のことができデータを TiDB に移行する 。独自のテスト データを設計して作成する場合は、SQL ステートメントを実行するか、関連ツールを使用して作成できます。
次のコマンドを実行して、テスト データ生成ツールをインストールします。
tiup install bench次のコマンドを実行して、テスト データを生成します。
tiup bench tpch --sf=1 prepareこのコマンドの出力に
Finishedが表示された場合、データが作成されたことを示します。次の SQL ステートメントを実行して、生成されたデータを表示します。
SELECT CONCAT(table_schema,'.',table_name) AS 'Table Name', table_rows AS 'Number of Rows', FORMAT_BYTES(data_length) AS 'Data Size', FORMAT_BYTES(index_length) AS 'Index Size', FORMAT_BYTES(data_length+index_length) AS'Total' FROM information_schema.TABLES WHERE table_schema='test';出力からわかるように、合計 8 つのテーブルが作成され、最大のテーブルには 650 万行あります (データがランダムに生成されるため、ツールによって作成される行の数は、実際の SQL クエリの結果によって異なります)。
+---------------+----------------+-----------+------------+-----------+ | Table Name | Number of Rows | Data Size | Index Size | Total | +---------------+----------------+-----------+------------+-----------+ | test.nation | 25 | 2.44 KiB | 0 bytes | 2.44 KiB | | test.region | 5 | 416 bytes | 0 bytes | 416 bytes | | test.part | 200000 | 25.07 MiB | 0 bytes | 25.07 MiB | | test.supplier | 10000 | 1.45 MiB | 0 bytes | 1.45 MiB | | test.partsupp | 800000 | 120.17 MiB| 12.21 MiB | 132.38 MiB| | test.customer | 150000 | 24.77 MiB | 0 bytes | 24.77 MiB | | test.orders | 1527648 | 174.40 MiB| 0 bytes | 174.40 MiB| | test.lineitem | 6491711 | 849.07 MiB| 99.06 MiB | 948.13 MiB| +---------------+----------------+-----------+------------+-----------+ 8 rows in set (0.06 sec)商用発注システムのデータベースです。
test.nation表は国に関する情報を示し、test.region表は地域に関する情報を示し、test.part表は部品に関する情報を示し、test.supplier表はサプライヤーに関する情報を示し、test.partsupp表はサプライヤーの部品に関する情報を示し、表test.customerは顧客に関する情報、表test.customerは注文に関する情報、表test.lineitemはオンライン アイテムに関する情報を示します。
ステップ 3. 行ベースのストレージ エンジンを使用してデータをクエリする
行ベースのストレージ エンジンのみを使用した TiDB のパフォーマンスを確認するには、次の SQL ステートメントを実行します。
SELECT
l_orderkey,
SUM(
l_extendedprice * (1 - l_discount)
) AS revenue,
o_orderdate,
o_shippriority
FROM
customer,
orders,
lineitem
WHERE
c_mktsegment = 'BUILDING'
AND c_custkey = o_custkey
AND l_orderkey = o_orderkey
AND o_orderdate < DATE '1996-01-01'
AND l_shipdate > DATE '1996-02-01'
GROUP BY
l_orderkey,
o_orderdate,
o_shippriority
ORDER BY
revenue DESC,
o_orderdate
limit 10;
これは出荷優先度クエリで、指定された日付までに出荷されなかった最高収益の注文の優先度と潜在的な収益を提供します。潜在的な収益はl_extendedprice * (1-l_discount)の合計として定義されます。注文は収益の降順でリストされます。この例では、このクエリは未出荷の注文を上位 10 位までリストします。
手順 4. テスト データを列指向ストレージ エンジンにレプリケートする
TiFlash がデプロイされた後、TiKV はデータをすぐに TiFlash に複製しません。レプリケートする必要があるテーブルを指定するには、TiDB の MySQL クライアントで次の DDL ステートメントを実行する必要があります。その後、TiDB はそれに応じて指定されたレプリカを TiFlash に作成します。
ALTER TABLE test.customer SET TIFLASH REPLICA 1;
ALTER TABLE test.orders SET TIFLASH REPLICA 1;
ALTER TABLE test.lineitem SET TIFLASH REPLICA 1;
特定のテーブルのレプリケーション ステータスを確認するには、次のステートメントを実行します。
SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = 'test' and TABLE_NAME = 'customer';
SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = 'test' and TABLE_NAME = 'orders';
SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = 'test' and TABLE_NAME = 'lineitem';
上記のステートメントの結果:
AVAILABLEは、特定のテーブルの TiFlash レプリカが使用可能かどうかを示します。1は利用可能であることを意味し、0は利用できないことを意味します。レプリカが利用可能になると、このステータスはそれ以上変化しません。 DDL ステートメントを使用してレプリカの数を変更すると、レプリケーション ステータスが再計算されます。PROGRESSは、レプリケーションの進行状況を意味します。値は 0.0 ～ 1.0 です。 1 は、少なくとも 1 つのレプリカがレプリケートされることを意味します。
ステップ 5. HTAP を使用してデータをより迅速に分析する
ステップ 3の SQL ステートメントを再度実行すると、 TiDB HTAPのパフォーマンスを確認できます。
TiFlash レプリカを含むテーブルの場合、TiDB オプティマイザは、コストの見積もりに基づいて TiFlash レプリカを使用するかどうかを自動的に決定します。 TiFlash レプリカが選択されているかどうかを確認するには、 descまたはexplain analyzeステートメントを使用できます。例えば：
explain analyze SELECT
l_orderkey,
SUM(
l_extendedprice * (1 - l_discount)
) AS revenue,
o_orderdate,
o_shippriority
FROM
customer,
orders,
lineitem
WHERE
c_mktsegment = 'BUILDING'
AND c_custkey = o_custkey
AND l_orderkey = o_orderkey
AND o_orderdate < DATE '1996-01-01'
AND l_shipdate > DATE '1996-02-01'
GROUP BY
l_orderkey,
o_orderdate,
o_shippriority
ORDER BY
revenue DESC,
o_orderdate
limit 10;
EXPLAINステートメントの結果がExchangeSenderつとExchangeReceiverの演算子を示している場合、MPP モードが有効になっていることを示します。
さらに、クエリ全体の各部分が TiFlash エンジンのみを使用して計算されるように指定できます。詳細については、 TiDB を使用して TiFlash レプリカを読み取るを参照してください。
これら 2 つの方法のクエリ結果とクエリ パフォーマンスを比較できます。