TiDBLightning用語集

このページでは、TiDB Lightningのログ、監視、構成、およびドキュメントで使用される特別な用語について説明します。

A

分析する

ANALYZE TABLEステートメントを実行しているTiDBテーブルの統計学情報を再構築する操作。

TiDB LightningはTiDBを経由せずにデータをインポートするため、統計情報は自動的に更新されません。したがって、TiDB Lightningは、インポート後にすべてのテーブルを明示的に分析します。この手順は、 post-restore.analyze構成をfalseに設定することで省略できます。

AUTO_INCREMENT_ID

すべてのテーブルには、自動インクリメント列のデフォルト値を提供するAUTO_INCREMENT_IDのカウンターが関連付けられています。 TiDBでは、このカウンターは行IDを割り当てるために追加で使用されます。

TiDB LightningはTiDBを経由せずにデータをインポートするため、 AUTO_INCREMENT_IDカウンターは自動的に更新されません。したがって、TiDBLightningはAUTO_INCREMENT_IDを有効な値に明示的に変更します。テーブルにAUTO_INCREMENTの列がない場合でも、このステップは常に実行されます。

B

バックエンド

バックエンドは、TiDBLightningが解析結果を送信する宛先です。 「バックエンド」とも呼ばれます。

詳細については、 TiDBLightningバックエンドを参照してください。

C

チェックポイント

TiDB Lightningは、インポート中に進行状況をローカルファイルまたはリモートデータベースに継続的に保存します。これにより、プロセス中にクラッシュした場合に、中間状態から再開できます。詳細については、 チェックポイントセクションを参照してください。

チェックサム

TiDB Lightningでは、テーブルのチェックサムは、そのテーブルの各KVペアの内容から計算された3つの数値のセットです。これらの番号はそれぞれ次のとおりです。

• KVペアの数、
• すべてのKVペアの全長、および
• 各ペアにCRC-64-ECMAの値のビット単位のXOR。

すべてのテーブルのローカルとリモートチェックサムを比較することによるインポートされたデータを検証します 。いずれかのペアが一致しない場合、プログラムは停止します。 post-restore.checksum構成をfalseに設定すると、このチェックをスキップできます。

チェックサムの不一致を適切に処理する方法については、 よくある質問も参照してください。

かたまり

ソースデータの連続範囲。通常、データソース内の単一のファイルに相当します。

ファイルが大きすぎる場合、TiDBLightningはファイルを複数のチャンクに分割する場合があります。

圧縮

複数の小さなSSTファイルを1つの大きなSSTファイルにマージし、削除されたエントリをクリーンアップする操作。 TiKVは、TiDB Lightningのインポート中に、バックグラウンドでデータを自動的に圧縮します。

ノート：

従来の理由から、テーブルがインポートされるたびに圧縮を明示的にトリガーするようにTiDBLightningを構成することもできます。ただし、これは推奨されておらず、対応する設定はデフォルトで無効になっています。

技術的な詳細については、 圧縮に関するRocksDBのwikiページを参照してください。

D

データエンジン

実際の行データをソートするためのエンジン 。

テーブルが非常に大きい場合、そのデータは複数のデータエンジンに配置され、タスクのパイプライン化を改善し、TiKVImporterのスペースを節約します。デフォルトでは、100 GBのSQLデータごとに新しいデータエンジンが開かれます。これは、 mydumper.batch-sizeの設定で構成できます。

TiDB Lightningは、複数のデータエンジンを同時に処理します。これはlightning.table-concurrencyの設定で制御されます。

E

エンジン

TiKV Importerでは、エンジンはKVペアを並べ替えるためのRocksDBインスタンスです。

TiDB Lightningは、エンジンを介してデータをTiKVImporterに転送します。最初にエンジンを開き、KVペアを（順不同で）送信し、最後にエンジンを閉じます。エンジンは、受信したKVペアを閉じた後にソートします。これらのクローズドエンジンは、取り込みのためにTiKVストアにさらにアップロードできます。

エンジンは、TiKV Importerのimport-dirを一時ストレージとして使用します。これは、「エンジンファイル」と呼ばれることもあります。

データエンジンおよびインデックスエンジンも参照してください。

F

フィルター

インポートまたは除外するテーブルを指定する構成リスト。

詳細については、 テーブルフィルターを参照してください。

私

インポートモード

読み取り速度とスペース使用量が低下する代わりに、書き込み用にTiKVを最適化する構成。

TiDB Lightningは、実行中にインポートモードのオンとオフを自動的に切り替えます。ただし、 ノーマルモードがインポートモードでスタックした場合は、 tidb-lightning-ctlを使用でき強制的に元に戻す 。

インデックスエンジン

インデックスをソートするためのエンジン 。

インデックスの数に関係なく、すべてのテーブルは1つのインデックスエンジンに関連付けられています。

TiDB Lightningは、複数のインデックスエンジンを同時に処理します。これはlightning.index-concurrencyの設定で制御されます。すべてのテーブルには1つのインデックスエンジンがあるため、これにより、同時に処理するテーブルの最大数も構成されます。

摂取する

SSTファイルのコンテンツ全体をRocksDB（TiKV）ストアに挿入する操作。

取り込みは、KVペアを1つずつ挿入する場合に比べて非常に高速な操作です。この操作は、TiDBLightningのパフォーマンスを決定する要因です。

技術的な詳細については、 SSTファイルの作成と取り込みに関するRocksDBのwikiページを参照してください。

K

KVペア

「キーと値のペア」の略語。

KVエンコーダ

SQLまたはCSV行をKVペアに解析するルーチン。複数のKVエンコーダーが並行して実行され、処理が高速化されます。

L

ローカルチェックサム

KVペアをTiKVImporterに送信する前にTiDBLightning自体によって計算されたテーブルのチェックサム 。

N

ノーマルモード

インポートモードが無効になっているモード。

P

後処理

データソース全体が解析されてTiKVインポーターに送信されてからの期間。 TiDB Lightningは、TiKVImporterがアップロードして摂取するを待機していSSTファイル 。

R

リモートチェックサム

インポート後にTiDBによって計算されたテーブルのチェックサム 。

S

散乱

領域のリーダーとピアをランダムに再割り当てする操作。スキャッタリングにより、インポートされたデータがTiKVストア間で均等に分散されます。これにより、PDへのストレスが軽減されます。

分割

エンジンは通常非常に大きく（約100 GB）、単一の領域として扱われる場合はTiKVに適していません。 TiKV Importerは、アップロードする前に、エンジンを複数の小さなSSTファイル （TiKV Importerのimport.region-split-size設定で構成可能）に分割します。

SSTファイル

SSTは、「sortedstringtable」の略語です。 SSTファイルは、KVペアのコレクションのRocksDB（したがってTiKV）のネイティブストレージ形式です。

TiKV Importerは、閉じたエンジンからSSTファイルを生成します。これらのSSTファイルはアップロードされてからTiKVストアに摂取したアップロードされます。