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アーキテクチャを参照してください。

C

チェックポイント

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 ファイルにマージし、削除されたエントリをクリーンアップする操作。 TiKV は、 TiDB Lightningのインポート中にバックグラウンドでデータを自動的に圧縮します。

注記:

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

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

D

データエンジン

実際の行データをソートする場合はエンジン

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

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

E

エンジン

TiKV Importer では、エンジンは KV ペアをソートするための RocksDB インスタンスです。

TiDB Lightning は、エンジンを通じてデータを TiKV Importer に転送します。まずエンジンを開き、KV ペアをそれに送信し (特に順序はありません)、最後にエンジンを閉じます。エンジンは閉じられた後に、受信した KV ペアを並べ替えます。これらのクローズド エンジンは、さらに TiKV ストアにアップロードして取り込むことができます。

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

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

F

フィルター

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

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

インポートモード

読み取り速度とスペース使用量の低下を犠牲にして、書き込み用に 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 インポーターに送信された後の期間。 TiDB Lightning は、 TiKV インポーターがアップロードするのを待っています摂取する SST ファイル

R

リモートチェックサム

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

S

Scattering

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

分割

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

SSTファイル

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

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

このページは役に立ちましたか?