TiDB Lightning用語集
このページでは、TiDB Lightning のログ、監視、構成、およびドキュメントで使用される特別な用語について説明します。
あ
分析する
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カウンターは自動的に更新されません。したがって、 TiDB Lightning は明示的にAUTO_INCREMENT_IDを有効な値に変更します。テーブルにAUTO_INCREMENT列がない場合でも、この手順は常に実行されます。
B
バックエンド
バックエンドは、 TiDB Lightning が解析結果を送信する宛先です。 「バックエンド」とも表記されます。
詳細はTiDB Lightningアーキテクチャを参照してください。
ハ
チェックポイント
TiDB Lightning は、インポート中に進行状況をローカル ファイルまたはリモート データベースに継続的に保存します。これにより、プロセスでクラッシュした場合に中間状態から再開できます。詳細については、セクションチェックポイントを参照してください。
チェックサム
TiDB Lightningでは、テーブルのチェックサムは、そのテーブル内の各 KV ペアの内容から計算された 3 つの数値のセットです。これらの数値はそれぞれ次のとおりです。
- KVペアの数、
- すべての KV ペアの全長、および
- 各ペアのCRC-64-ECMAの値のビットごとの XOR。
すべてのテーブルの地元とリモート チェックサム比較することによるTiDB Lightning インポートされたデータを検証します 。いずれかのペアが一致しない場合、プログラムは停止します。 post-restore.checksum構成をfalseに設定することで、このチェックをスキップできます。
チェックサムの不一致を適切に処理する方法については、 よくある質問も参照してください。
Chunk
ソース データの連続した範囲。通常は、データ ソース内の 1 つのファイルに相当します。
ファイルが大きすぎる場合、 TiDB Lightning はファイルを複数のチャンクに分割することがあります。
締固め
複数の小さな SST ファイルを 1 つの大きな SST ファイルにマージし、削除されたエントリをクリーンアップする操作。 TiDB Lightningのインポート中に、TiKV はバックグラウンドで自動的にデータを圧縮します。
ノート：
従来の理由から、テーブルがインポートされるたびに明示的に圧縮をトリガーするようにTiDB Lightningを引き続き構成できます。ただし、これはお勧めできません。対応する設定はデフォルトで無効になっています。
技術的な詳細については圧縮に関する RocksDB の wiki ページ参照してください。
D
データエンジン
実際の行データを並べ替える場合はエンジン 。
テーブルが非常に大きい場合、そのデータは複数のデータ エンジンに配置され、タスクのパイプライン処理が改善され、TiKV Importer のスペースが節約されます。デフォルトでは、100 GB の SQL データごとに新しいデータ エンジンが開かれます。これはmydumper.batch-size設定で構成できます。
TiDB Lightning は複数のデータ エンジンを同時に処理します。これはlightning.table-concurrency設定によって制御されます。
え
エンジン
TiKV Importer では、エンジンは KV ペアをソートするための RocksDB インスタンスです。
TiDB Lightning は、エンジンを介してデータを TiKV Importer に転送します。最初にエンジンを開き、KV ペアを (特定の順序で) 送信し、最後にエンジンを閉じます。エンジンは、閉じた後、受信した KV ペアを並べ替えます。これらのクローズド エンジンは、取り込みのために TiKV ストアにさらにアップロードできます。
エンジンは TiKV Importer のimport-dir一時storageとして使用し、「エンジン ファイル」と呼ばれることもあります。
ふ
フィルター
インポートまたは除外するテーブルを指定する構成リスト。
詳細はテーブル フィルターを参照してください。
私
インポート モード
読み取り速度とスペース使用量の低下を犠牲にして、書き込み用に TiKV を最適化する構成。
TiDB Lightning は、実行中にインポート モードを自動的に切り替えます。ただし、TiKV がインポート モードで動かなくなった場合は、 tidb-lightning-ctl ～ 強制復帰 ～ ノーマルモードを使用できます。
索引エンジン
インデックスを並べ替える場合はエンジン 。
インデックスの数に関係なく、すべてのテーブルは 1 つのインデックス エンジンに関連付けられています。
TiDB Lightning は、複数のインデックス エンジンを同時に処理します。これはlightning.index-concurrency設定によって制御されます。すべてのテーブルには 1 つのインデックス エンジンしかないため、同時に処理するテーブルの最大数も構成されます。
取り込み
SSTファイルのコンテンツ全体を RocksDB (TiKV) ストアに挿入する操作。
取り込みは、KV ペアを 1 つずつ挿入するのに比べて非常に高速な操作です。この操作は、 TiDB Lightningのパフォーマンスの決定要因です。
技術的な詳細についてはSST ファイルの作成と取り込みに関する RocksDB の wiki ページ参照してください。
K
KVペア
「キーバリューペア」の略。
KV エンコーダ
SQL または CSV 行を解析して KV ペアにするルーチン。複数の KV エンコーダーが並行して実行され、処理が高速化されます。
L
ローカル チェックサム
KV ペアを TiKV Importer に送信する前に、 TiDB Lightning自体によって計算されたテーブルのチェックサム 。
N
ノーマルモード
インポート モードが無効なモード。
P
後処理
データ ソース全体が解析され、TiKV Importer に送信された後の期間。 TiDB Lightning はTiKV Importer がアップロードするのを待っており、 摂取する the SST ファイル .
R
リモート チェックサム
インポート後に TiDB によって計算されたテーブルのチェックサム 。
S
Scattering
リージョンのリーダーとピアをランダムに再割り当てする操作。Scattering、インポートされたデータが TiKV ストア間で均等に分散されます。これにより、PD のストレスが軽減されます。
分割
通常、エンジンは非常に大きく (約 100 GB)、単一の領域として扱われると TiKV には適していません。 TiKV Importer は、アップロードする前にエンジンを複数の小さなSST ファイル (TiKV Importer のimport.region-split-size設定で構成可能) に分割します。
SSTファイル
SST は「ソートされた文字列テーブル」の略です。 SST ファイルは、KV ペアのコレクションの RocksDB (したがって TiKV) のネイティブstorage形式です。
TiKV Importer は、閉じたエンジンから SST ファイルを生成します。これらの SST ファイルはアップロードされ、TiKV ストアに摂取したされます。