重要

このページは英語版のページを機械翻訳しています。原文はこちらからご覧ください。

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 が解析結果を送信する宛先です。「backend」とも表記されます。

詳細は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 ページ参照してください。

だ

データエンジン

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

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

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

え

エンジン

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

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

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

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

ふ

フィルター

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

詳細はテーブルフィルター参照。

私

インポートモード

読み取り速度とスペース使用量の低下を犠牲にして、書き込み用に TiKV を最適化する構成。

TiDB Lightning は実行中にインポートモードを自動的にオン/オフにします。ただし、TiKV がインポートモードで停止した場合は、 tidb-lightning-ctl ～強制的に元に戻す～ノーマルモードを使用できます。

インデックスエンジン

インデックスをソートする場合はエンジン。

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

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

取り込み

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

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

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

け

KVペア

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

KVエンコーダ

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

ら

ローカルチェックサム

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

いいえ

ノーマルモード

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

ポ

後処理

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

R

リモートチェックサム

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

S

Scattering

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

分割

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

SST ファイル

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

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