データのインポートからTPC-Hデータセットでのクエリまでのプロセス全体を体験するには、 TiDB HTAPのクイックスタートガイドを参照してください。
TiFlashを使用する
TiFlashがデプロイされた後、データレプリケーションは自動的に開始されません。複製するテーブルを手動で指定する必要があります。
TiDBを使用して中規模の分析処理用のTiFlashレプリカを読み取るか、TiSparkを使用して大規模な分析処理用のTiFlashレプリカを読み取ることができます。これは独自のニーズに基づいています。詳細については、次のセクションを参照してください。
テーブルのTiFlashレプリカを作成する
TiFlashがTiKVクラスタに接続された後、デフォルトではデータレプリケーションは開始されません。 MySQLクライアントを介してDDLステートメントをTiDBに送信して、特定のテーブルのTiFlashレプリカを作成できます。
ALTER TABLE table_name SET TIFLASH REPLICA count;
上記のコマンドのパラメータは次のとおりです。
countはレプリカの数を示します。値が0の場合、レプリカは削除されます。
同じテーブルで複数のDDLステートメントを実行すると、最後のステートメントのみが有効になります。次の例では、2つのDDLステートメントがテーブルtpch50で実行されますが、2番目のステートメント（レプリカを削除するため）のみが有効になります。
テーブルのレプリカを2つ作成します。
ALTER TABLE `tpch50`.`lineitem` SET TIFLASH REPLICA 2;
レプリカを削除します。
ALTER TABLE `tpch50`.`lineitem` SET TIFLASH REPLICA 0;
ノート：
テーブル
tが上記のDDLステートメントを介してTiFlashに複製される場合、次のステートメントを使用して作成されたテーブルも自動的にTiFlashに複製されます。CREATE TABLE table_name like t;v4.0.6より前のバージョンでは、TiDB Lightningを使用してデータをインポートする前にTiFlashレプリカを作成すると、データのインポートが失敗します。テーブルのTiFlashレプリカを作成する前に、データをテーブルにインポートする必要があります。
TiDBとTiDBLightningの両方がv4.0.6以降の場合、テーブルにTiFlashレプリカがあるかどうかに関係なく、TiDBLightningを使用してそのテーブルにデータをインポートできます。これにより、TiDB Lightningの手順が遅くなる可能性があることに注意してください。これは、LightningホストのNIC帯域幅、TiFlashノードのCPUとディスクの負荷、およびTiFlashレプリカの数によって異なります。
PDスケジューリングのパフォーマンスが低下するため、1,000を超えるテーブルを複製しないことをお勧めします。この制限は、今後のバージョンで削除される予定です。
v5.1以降のバージョンでは、システムテーブルのレプリカの設定はサポートされなくなりました。クラスタをアップグレードする前に、関連するシステムテーブルのレプリカをクリアする必要があります。そうしないと、クラスタを新しいバージョンにアップグレードした後、システムテーブルのレプリカ設定を変更できません。
レプリケーションの進行状況を確認する
次のステートメントを使用して、特定のテーブルのTiFlashレプリカのステータスを確認できます。テーブルはWHERE句を使用して指定されます。 WHERE句を削除すると、すべてのテーブルのレプリカステータスが確認されます。
SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = '<db_name>' and TABLE_NAME = '<table_name>';
上記のステートメントの結果：
AVAILABLEは、このテーブルのTiFlashレプリカが使用可能かどうかを示します。1は利用可能、0は利用不可を意味します。レプリカが使用可能になると、このステータスは変更されません。 DDLステートメントを使用してレプリカの数を変更すると、レプリケーションステータスが再計算されます。PROGRESSは、レプリケーションの進行状況を意味します。値は0.01.0。1は、少なくとも1つのレプリカが複製されることを意味します。
利用可能なゾーンを設定する
レプリカを構成するときに、ディザスタリカバリのためにTiFlashレプリカを複数のデータセンターに配布する必要がある場合は、以下の手順に従って使用可能なゾーンを構成できます。
クラスタ構成ファイルでTiFlashノードのラベルを指定します。
tiflash_servers: - host: 172.16.5.81 config: flash.proxy.labels: zone=z1 - host: 172.16.5.82 config: flash.proxy.labels: zone=z1 - host: 172.16.5.85 config: flash.proxy.labels: zone=z2クラスタを起動した後、レプリカを作成するときにラベルを指定します。
ALTER TABLE table_name SET TIFLASH REPLICA count LOCATION LABELS location_labels;例えば：
ALTER TABLE t SET TIFLASH REPLICA 2 LOCATION LABELS "zone";PDは、ラベルに基づいてレプリカをスケジュールします。この例では、PDはそれぞれテーブル
tの2つのレプリカを2つの使用可能なゾーンにスケジュールします。 pd-ctlを使用してスケジュールを表示できます。> tiup ctl:<version> pd -u<pd-host>:<pd-port> store ... "address": "172.16.5.82:23913", "labels": [ { "key": "engine", "value": "tiflash"}, { "key": "zone", "value": "z1" } ], "region_count": 4, ... "address": "172.16.5.81:23913", "labels": [ { "key": "engine", "value": "tiflash"}, { "key": "zone", "value": "z1" } ], "region_count": 5, ... "address": "172.16.5.85:23913", "labels": [ { "key": "engine", "value": "tiflash"}, { "key": "zone", "value": "z2" } ], "region_count": 9, ...
ラベルを使用したレプリカのスケジューリングの詳細については、 トポロジラベルによるレプリカのスケジュール 、および1 つの地域展開における複数のデータセンターを参照して2つの都市に配置された3つのデータセンター 。
TiDBを使用してTiFlashレプリカを読み取る
TiDBは、TiFlashレプリカを読み取る3つの方法を提供します。エンジン構成なしでTiFlashレプリカを追加した場合、デフォルトでCBO（コストベースの最適化）モードが使用されます。
スマートセレクション
TiFlashレプリカを含むテーブルの場合、TiDBオプティマイザは、コスト見積もりに基づいてTiFlashレプリカを使用するかどうかを自動的に決定します。 descまたはexplain analyzeステートメントを使用して、TiFlashレプリカが選択されているかどうかを確認できます。例えば：
desc select count(*) from test.t;
+--------------------------+---------+--------------+---------------+--------------------------------+
| id | estRows | task | access object | operator info |
+--------------------------+---------+--------------+---------------+--------------------------------+
| StreamAgg_9 | 1.00 | root | | funcs:count(1)->Column#4 |
| └─TableReader_17 | 1.00 | root | | data:TableFullScan_16 |
| └─TableFullScan_16 | 1.00 | cop[tiflash] | table:t | keep order:false, stats:pseudo |
+--------------------------+---------+--------------+---------------+--------------------------------+
3 rows in set (0.00 sec)
explain analyze select count(*) from test.t;
+--------------------------+---------+---------+--------------+---------------+----------------------------------------------------------------------+--------------------------------+-----------+------+
| id | estRows | actRows | task | access object | execution info | operator info | memory | disk |
+--------------------------+---------+---------+--------------+---------------+----------------------------------------------------------------------+--------------------------------+-----------+------+
| StreamAgg_9 | 1.00 | 1 | root | | time:83.8372ms, loops:2 | funcs:count(1)->Column#4 | 372 Bytes | N/A |
| └─TableReader_17 | 1.00 | 1 | root | | time:83.7776ms, loops:2, rpc num: 1, rpc time:83.5701ms, proc keys:0 | data:TableFullScan_16 | 152 Bytes | N/A |
| └─TableFullScan_16 | 1.00 | 1 | cop[tiflash] | table:t | time:43ms, loops:1 | keep order:false, stats:pseudo | N/A | N/A |
+--------------------------+---------+---------+--------------+---------------+----------------------------------------------------------------------+--------------------------------+-----------+------+
cop[tiflash]は、タスクが処理のためにTiFlashに送信されることを意味します。 TiFlashレプリカを選択していない場合は、 analyze tableステートメントを使用して統計を更新し、 explain analyzeステートメントを使用して結果を確認できます。
テーブルにTiFlashレプリカが1つしかなく、関連ノードがサービスを提供できない場合、CBOモードのクエリは繰り返し再試行することに注意してください。この状況では、エンジンを指定するか、手動ヒントを使用してTiKVレプリカからデータを読み取る必要があります。
エンジンの分離
エンジンの分離とは、対応する変数を構成することにより、すべてのクエリが指定されたエンジンのレプリカを使用するように指定することです。オプションのエンジンは、「tikv」、「tidb」（一部のTiDBシステムテーブルを格納し、ユーザーがアクティブに使用できないTiDBの内部メモリテーブル領域を示します）、および「tiflash」で、次の2つの構成レベルがあります。
TiDBインスタンスレベル、つまりINSTANCEレベル。 TiDB構成ファイルに次の構成項目を追加します。
[isolation-read] engines = ["tikv", "tidb", "tiflash"]INSTANCEレベルのデフォルト構成は
["tikv", "tidb", "tiflash"]です。SESSIONレベル。次のステートメントを使用して構成します。
set @@session.tidb_isolation_read_engines = "engine list separated by commas";また
set SESSION tidb_isolation_read_engines = "engine list separated by commas";SESSIONレベルのデフォルト構成は、TiDBINSTANCEレベルの構成を継承します。
最終的なエンジン構成はセッションレベルの構成です。つまり、セッションレベルの構成はインスタンスレベルの構成をオーバーライドします。たとえば、INSTANCEレベルで「tikv」を構成し、SESSIONレベルで「tiflash」を構成した場合、TiFlashレプリカが読み取られます。最終的なエンジン構成が「tikv」と「tiflash」の場合、TiKVとTiFlashのレプリカが両方とも読み取られ、オプティマイザーは実行するのに適したエンジンを自動的に選択します。
ノート：
TiDBダッシュボードおよびその他のコンポーネントは、TiDBメモリテーブル領域に格納されている一部のシステムテーブルを読み取る必要があるため、常に「tidb」エンジンをインスタンスレベルのエンジン構成に追加することをお勧めします。
照会されたテーブルに指定されたエンジンのレプリカがない場合（たとえば、エンジンが「tiflash」として構成されているが、テーブルにTiFlashレプリカがない場合）、クエリはエラーを返します。
手動ヒント
手動のヒントにより、TiDBは、エンジンの分離を満たすことを前提として、特定のテーブルに指定されたレプリカを使用するように強制できます。手動ヒントの使用例を次に示します。
select /*+ read_from_storage(tiflash[table_name]) */ ... from table_name;
クエリステートメントでテーブルにエイリアスを設定する場合は、ヒントを有効にするためのヒントを含むエイリアスをステートメントで使用する必要があります。例えば：
select /*+ read_from_storage(tiflash[alias_a,alias_b]) */ ... from table_name_1 as alias_a, table_name_2 as alias_b where alias_a.column_1 = alias_b.column_2;
上記のステートメントで、 tiflash[]はオプティマイザにTiFlashレプリカを読み取るように促します。 tikv[]を使用して、必要に応じてオプティマイザにTiKVレプリカを読み取るように求めることもできます。ヒント構文の詳細については、 READ_FROM_STORAGEを参照してください。
ヒントで指定されたテーブルに指定されたエンジンのレプリカがない場合、ヒントは無視され、警告が報告されます。さらに、ヒントはエンジン分離の前提でのみ有効になります。ヒントで指定されたエンジンがエンジン分離リストにない場合、ヒントも無視され、警告が報告されます。
ノート：
5.7.7以前のバージョンのMySQLクライアントは、デフォルトでオプティマイザヒントをクリアします。これらの初期バージョンでヒント構文を使用するには、
--commentsオプション（たとえば、mysql -h 127.0.0.1 -P 4000 -uroot --comments）でクライアントを起動します。
スマートセレクション、エンジン分離、および手動ヒントの関係
上記の3つのTiFlashレプリカの読み取り方法では、エンジン分離により、エンジンの使用可能なレプリカの全体的な範囲が指定されます。この範囲内で、手動ヒントは、よりきめ細かいステートメントレベルおよびテーブルレベルのエンジン選択を提供します。最後に、CBOが決定を下し、指定されたエンジンリスト内のコスト見積もりに基づいてエンジンのレプリカを選択します。
ノート：
UPDATE ...より前では、非読み取り専用SQLステートメント（たとえば、INSERT INTO ... SELECT）でのSELECT ... FOR UPDATEレプリカからの読み取りのDELETE ...は定義されていません。 v4.0.3以降のバージョンでは、内部的にTiDBは非読み取り専用SQLステートメントのTiFlashレプリカを無視して、データの正確性を保証します。つまり、 スマートセレクションの場合、TiDBは非TiFlashレプリカを自動的に選択します。 TiFlashレプリカのみを指定するエンジンの分離の場合、TiDBはエラーを報告します。 手動ヒントの場合、TiDBはヒントを無視します。
TiSparkを使用してTiFlashレプリカを読み取ります
現在、TiSparkを使用して、TiDBのエンジン分離と同様の方法でTiFlashレプリカを読み取ることができます。この方法は、 spark.tispark.isolation_read_enginesつのパラメーターを構成するためのものです。パラメータ値のデフォルトはtikv,tiflashです。これは、TiDBがCBOの選択に従ってTiFlashまたはTiKVからデータを読み取ることを意味します。パラメータ値をtiflashに設定すると、TiDBがTiFlashからデータを強制的に読み取ることを意味します。
ノート
このパラメーターが
tiflashに設定されている場合、クエリに関係するすべてのテーブルのTiFlashレプリカのみが読み取られ、これらのテーブルにはTiFlashレプリカが必要です。 TiFlashレプリカがないテーブルの場合、エラーが報告されます。このパラメーターがtikvに設定されている場合、TiKVレプリカのみが読み取られます。
このパラメーターは、次のいずれかの方法で構成できます。
spark-defaults.confのファイルに次の項目を追加します。spark.tispark.isolation_read_engines tiflashSparkシェルまたはThriftサーバーを初期化するときに、初期化コマンドに
--conf spark.tispark.isolation_read_engines=tiflashを追加します。リアルタイムでSparkシェルに
spark.conf.set("spark.tispark.isolation_read_engines", "tiflash")を設定します。サーバーがbeeline経由で接続された後、Thriftサーバーに
set spark.tispark.isolation_read_engines=tiflashを設定します。
サポートされているプッシュダウン計算
TiFlashは、次の演算子のプッシュダウンをサポートしています。
- TableScan：テーブルからデータを読み取ります。
- 選択：データをフィルタリングします。
- HashAgg： ハッシュ集計アルゴリズムに基づいてデータ集約を実行します。
- StreamAgg： ストリーム集計のアルゴリズムに基づいてデータ集約を実行します。 SteamAggは、
GROUP BYの条件なしで集約のみをサポートします。 - TopN：TopN計算を実行します。
- 制限：制限計算を実行します。
- プロジェクト：投影計算を実行します。
- HashJoin（Equi Join）： ハッシュ参加アルゴリズムに基づいて結合計算を実行しますが、次の条件があります。
- オペレーターはMPPモードでのみ押し下げることができます。
Full Outer Joinのプッシュダウンはサポートされていません。
- HashJoin（非等結合）：デカルト結合アルゴリズムを実行しますが、次の条件があります。
- オペレーターはMPPモードでのみ押し下げることができます。
- デカルト結合は、ブロードキャスト結合でのみサポートされます。
TiDBでは、演算子はツリー構造で編成されています。オペレーターをTiFlashにプッシュダウンするには、次のすべての前提条件が満たされている必要があります。
- その子演算子はすべてTiFlashにプッシュダウンできます。
- 演算子に式が含まれている場合（ほとんどの演算子に式が含まれている場合）、演算子のすべての式をTiFlashにプッシュダウンできます。
現在、TiFlashは次のプッシュダウン式をサポートしています。
- 数学関数：
+, -, /, *, %, >=, <=, =, !=, <, >, round, abs, floor(int), ceil(int), ceiling(int), sqrt, log, log2, log10, ln, exp, pow, sign, radians, degrees, conv, crc32 - 論理関数：
and, or, not, case when, if, ifnull, isnull, in, like, coalesce - ビット演算：
bitand, bitor, bigneg, bitxor - 文字列関数：
substr, char_length, replace, concat, concat_ws, left, right, ascii, length, trim, ltrim, rtrim, position, format, lower, ucase, upper, substring_index, lpad, rpad, strcmp - 日付関数：
date_format, timestampdiff, from_unixtime, unix_timestamp(int), unix_timestamp(decimal), str_to_date(date), str_to_date(datetime), datediff, year, month, day, extract(datetime), date, hour, microsecond, minute, second, sysdate, date_add, date_sub, adddate, subdate, quarter - JSON関数：
json_length - 変換機能：
cast(int as double), cast(int as decimal), cast(int as string), cast(int as time), cast(double as int), cast(double as decimal), cast(double as string), cast(double as time), cast(string as int), cast(string as double), cast(string as decimal), cast(string as time), cast(decimal as int), cast(decimal as string), cast(decimal as time), cast(time as int), cast(time as decimal), cast(time as string), cast(time as real) - 集計関数：
min, max, sum, count, avg, approx_count_distinct, group_concat - その他の機能：
inetntoa, inetaton, inet6ntoa, inet6aton
その他の制限
Bit、Set、およびGeometryタイプを含む式は、TiFlashにプッシュダウンできません。
date_add、subdatedate_subは、次の間隔タイプのみをサポートしadddate。他の間隔タイプが使用されている場合、TiFlashはエラーを報告します。- 日
- 週
- 月
- 年
- 時間
- 分
- 2番目
クエリでサポートされていないプッシュダウン計算が発生した場合、TiDBは残りの計算を完了する必要があります。これは、TiFlashアクセラレーション効果に大きな影響を与える可能性があります。現在サポートされていない演算子と式は、将来のバージョンでサポートされる可能性があります。
MPPモードを使用する
TiFlashは、MPPモードを使用したクエリの実行をサポートします。これにより、ノード間のデータ交換（データシャッフルプロセス）が計算に導入されます。 TiDBは、オプティマイザのコスト見積もりを使用して、MPPモードを選択するかどうかを自動的に決定します。 tidb_allow_mppとtidb_enforce_mppの値を変更することにより、選択戦略を変更できます。
MPPモードを選択するかどうかを制御します
tidb_allow_mpp変数は、TiDBがクエリを実行するためにMPPモードを選択できるかどうかを制御します。 tidb_enforce_mpp変数は、オプティマイザーのコスト見積もりを無視するかどうかを制御し、TiFlashのMPPモードを使用してクエリを強制的に実行します。
これら2つの変数のすべての値に対応する結果は次のとおりです。
| tidb_allow_mpp = off | tidb_allow_mpp = on（デフォルト） | |
|---|---|---|
| tidb_enforce_mpp = off（デフォルト） | MPPモードは使用されません。 | オプティマイザは、コスト見積もりに基づいてMPPモードを選択します。 （デフォルト） |
| tidb_enforce_mpp = on | MPPモードは使用されません。 | TiDBはコスト見積もりを無視し、MPPモードを選択します。 |
たとえば、MPPモードを使用したくない場合は、次のステートメントを実行できます。
set @@session.tidb_allow_mpp=1;
set @@session.tidb_enforce_mpp=0;
TiDBのコストベースのオプティマイザでMPPモード（デフォルト）を使用するかどうかを自動的に決定する場合は、次のステートメントを実行できます。
set @@session.tidb_allow_mpp=1;
set @@session.tidb_enforce_mpp=0;
TiDBでオプティマイザのコスト見積もりを無視し、MPPモードを強制的に選択する場合は、次のステートメントを実行できます。
set @@session.tidb_allow_mpp=1;
set @@session.tidb_enforce_mpp=1;
tidb_enforce_mppセッション変数の初期値は、このtidb-serverインスタンスのenforce-mpp構成値（デフォルトではfalse ）と同じです。 TiDBクラスタの複数のtidb-serverインスタンスが分析クエリのみを実行し、これらのインスタンスでMPPモードが使用されていることを確認する場合は、 enforce-mppの構成値をtrueに変更できます。
ノート：
tidb_enforce_mpp=1が有効になると、TiDBオプティマイザはコスト見積もりを無視してMPPモードを選択します。ただし、他の要因がMPPモードをブロックしている場合、TiDBはMPPモードを選択しません。これらの要因には、TiFlashレプリカの欠如、TiFlashレプリカの未完成の複製、およびMPPモードでサポートされていない演算子または関数を含むステートメントが含まれます。コスト見積もり以外の理由でTiDBオプティマイザがMPPモードを選択できない場合、
EXPLAINステートメントを使用して実行プランをチェックアウトすると、理由を説明する警告が返されます。例えば：
MPPモードのアルゴリズムサポート
MPPモードは、ブロードキャストハッシュ結合、シャッフルハッシュ結合、シャッフルハッシュ集計、Union All、TopN、およびLimitの物理アルゴリズムをサポートします。オプティマイザは、クエリで使用するアルゴリズムを自動的に決定します。特定のクエリ実行プランを確認するには、 EXPLAINステートメントを実行します。 EXPLAINステートメントの結果にExchangeSenderおよびExchangeReceiver演算子が表示されている場合は、MPPモードが有効になっていることを示しています。
次のステートメントは、TPC-Hテストセットのテーブル構造を例として取り上げています。
explain select count(*) from customer c join nation n on c.c_nationkey=n.n_nationkey;
+------------------------------------------+------------+-------------------+---------------+----------------------------------------------------------------------------+
| id | estRows | task | access object | operator info |
+------------------------------------------+------------+-------------------+---------------+----------------------------------------------------------------------------+
| HashAgg_23 | 1.00 | root | | funcs:count(Column#16)->Column#15 |
| └─TableReader_25 | 1.00 | root | | data:ExchangeSender_24 |
| └─ExchangeSender_24 | 1.00 | batchCop[tiflash] | | ExchangeType: PassThrough |
| └─HashAgg_12 | 1.00 | batchCop[tiflash] | | funcs:count(1)->Column#16 |
| └─HashJoin_17 | 3000000.00 | batchCop[tiflash] | | inner join, equal:[eq(tpch.nation.n_nationkey, tpch.customer.c_nationkey)] |
| ├─ExchangeReceiver_21(Build) | 25.00 | batchCop[tiflash] | | |
| │ └─ExchangeSender_20 | 25.00 | batchCop[tiflash] | | ExchangeType: Broadcast |
| │ └─TableFullScan_18 | 25.00 | batchCop[tiflash] | table:n | keep order:false |
| └─TableFullScan_22(Probe) | 3000000.00 | batchCop[tiflash] | table:c | keep order:false |
+------------------------------------------+------------+-------------------+---------------+----------------------------------------------------------------------------+
9 rows in set (0.00 sec)
実行プランの例には、 ExchangeReceiverとExchangeSenderの演算子が含まれています。実行プランは、 nationテーブルが読み取られた後、 ExchangeSenderオペレーターがテーブルを各ノードにブロードキャストし、 HashJoinおよびHashAgg操作がnationテーブルとcustomerテーブルで実行され、結果がTiDBに返されることを示しています。
TiFlashは、ブロードキャストハッシュ結合を使用するかどうかを制御するために、次の2つのグローバル/セッション変数を提供します。
tidb_broadcast_join_threshold_size：値の単位はバイトです。テーブルサイズ（バイト単位）が変数の値よりも小さい場合は、ブロードキャストハッシュ結合アルゴリズムが使用されます。それ以外の場合は、シャッフルハッシュ結合アルゴリズムが使用されます。tidb_broadcast_join_threshold_count：値の単位は行です。結合操作のオブジェクトがサブクエリに属している場合、オプティマイザはサブクエリ結果セットのサイズを推定できないため、サイズは結果セットの行数によって決定されます。サブクエリの推定行数がこの変数の値よりも少ない場合は、ブロードキャストハッシュ結合アルゴリズムが使用されます。それ以外の場合は、シャッフルハッシュ結合アルゴリズムが使用されます。
データ検証
ユーザーシナリオ
データの破損は通常、深刻なハードウェア障害によって引き起こされます。このような場合、手動でデータを回復しようとしても、データの信頼性が低下します。
データの整合性を確保するために、デフォルトでは、TiFlashはCity128アルゴリズムを使用してデータファイルに対して基本的なデータ検証を実行します。データ検証に失敗した場合、TiFlashはすぐにエラーを報告して終了し、一貫性のないデータによって引き起こされる二次的な災害を回避します。このとき、TiFlashノードを復元する前に、手動で介入してデータを再度複製する必要があります。
v5.4.0以降、TiFlashはより高度なデータ検証機能を導入しています。 TiFlashはデフォルトでXXH3アルゴリズムを使用し、検証フレームとアルゴリズムをカスタマイズできます。
検証メカニズム
検証メカニズムは、DeltaTreeファイル（DTFile）に基づいて構築されています。 DTFileは、TiFlashデータを保持するストレージファイルです。 DTFileには次の3つの形式があります。
| バージョン | 州 | 検証メカニズム | ノート |
|---|---|---|---|
| V1 | 非推奨 | ハッシュはデータファイルに埋め込まれています。 | |
| V2 | デフォルト | ハッシュはデータファイルに埋め込まれています。 | V1と比較して、V2は列データの統計を追加します。 |
| V3 | 手動で有効にする | V3には、メタデータとトークンデータのチェックサムが含まれており、複数のハッシュアルゴリズムをサポートしています。 | v5.4.0の新機能。 |
DTFileは、データファイルディレクトリのstableフォルダに保存されます。現在有効になっているすべての形式はフォルダ形式です。つまり、データはdmf_<file id>のような名前のフォルダの下にある複数のファイルに保存されます。
データ検証を使用する
TiFlashは、自動データ検証と手動データ検証の両方をサポートしています。
- 自動データ検証：
- TiFlashは、デフォルトでV2検証メカニズムを有効にします。
- V3検証メカニズムを有効にするには、 TiFlash構成ファイルを参照してください。
- 手動データ検証。
DTTool inspectを参照してください。
検証ツール
TiFlashがデータを読み取るときに実行される自動データ検証に加えて、データの整合性を手動でチェックするためのツールがv5.4.0で導入されています。詳しくはDTToolをご覧ください。
ノート
次の状況では、TiFlashはTiDBと互換性がありません。
TiFlash計算レイヤー：
オーバーフローした数値のチェックはサポートされていません。たとえば、
BIGINTタイプ9223372036854775807 + 9223372036854775807の2つの最大値を追加します。 TiDBでのこの計算の予想される動作は、ERROR 1690 (22003): BIGINT value is out of rangeエラーを返すことです。ただし、この計算をTiFlashで実行すると、オーバーフロー値-2がエラーなしで返されます。ウィンドウ関数はサポートされていません。
TiKVからのデータの読み取りはサポートされていません。
現在、TiFlashの
sum関数は文字列型引数をサポートしていません。ただし、TiDBは、コンパイル中に文字列型の引数がsum関数に渡されたかどうかを識別できません。したがって、select sum(string_col) from tと同様のステートメントを実行すると、TiFlashは[FLASH:Coprocessor:Unimplemented] CastStringAsReal is not supported.エラーを返します。この場合のこのようなエラーを回避するには、このSQLステートメントをselect sum(cast(string_col as double)) from tに変更する必要があります。現在、TiFlashの小数除算の計算はTiDBの計算と互換性がありません。たとえば、小数を除算する場合、TiFlashは常にコンパイルから推測されたタイプを使用して計算を実行します。ただし、TiDBは、コンパイルから推測されるタイプよりも正確なタイプを使用してこの計算を実行します。したがって、10進数の除算を含む一部のSQLステートメントは、TiDB+TiKVとTiDB+TiFlashで実行されたときに異なる実行結果を返します。例えば：
mysql> create table t (a decimal(3,0), b decimal(10, 0)); Query OK, 0 rows affected (0.07 sec) mysql> insert into t values (43, 1044774912); Query OK, 1 row affected (0.03 sec) mysql> alter table t set tiflash replica 1; Query OK, 0 rows affected (0.07 sec) mysql> set session tidb_isolation_read_engines='tikv'; Query OK, 0 rows affected (0.00 sec) mysql> select a/b, a/b + 0.0000000000001 from t where a/b; +--------+-----------------------+ | a/b | a/b + 0.0000000000001 | +--------+-----------------------+ | 0.0000 | 0.0000000410001 | +--------+-----------------------+ 1 row in set (0.00 sec) mysql> set session tidb_isolation_read_engines='tiflash'; Query OK, 0 rows affected (0.00 sec) mysql> select a/b, a/b + 0.0000000000001 from t where a/b; Empty set (0.01 sec)上記の例では、コンパイルから推測される
a/bの型は、TiDBとTiFlashの両方でDecimal(7,4)です。Decimal(7,4)によって制約され、a/bの返されるタイプは0.0000である必要があります。 TiDBでは、a/bの実行時精度はDecimal(7,4)よりも高いため、元のテーブルデータはwhere a/b条件によってフィルタリングされません。ただし、TiFlashでは、a/bの計算では結果タイプとしてDecimal(7,4)が使用されるため、元のテーブルデータはwhere a/b条件でフィルタリングされます。