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 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を一時ストレージとして使用します。これは「エンジン ファイル」と呼ばれることもあります。

データエンジン索引エンジンも参照してください。

フィルター

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

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

インポート モード

読み取り速度とスペース使用量の低下を犠牲にして、書き込み用に 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ストア間で均等に分散されます。これにより、PD のストレスが軽減されます。

分割

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

SSTファイル

SST は「ソートされた文字列テーブル」の略です。 SST ファイルは、KV ペアのコレクションの RocksDB (したがって TiKV) のネイティブ ストレージ形式です。

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

エコシステム
TiDB
TiKV
TiSpark
Chaos Mesh
© 2022 PingCAP. All Rights Reserved.