重要

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

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 ストアに摂取したされます。