TiDB Lightning用語集

このページでは、TiDB Lightning のログ、監視、構成、ドキュメントで使用される特殊な用語について説明します。

TiDB 関連の用語と定義については、 TiDB用語集参照してください。

あ

分析する

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アーキテクチャ参照。

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インポーターのメモリを節約するため、そのデータは複数のデータエンジンに分散されます。デフォルトでは、SQLデータ100GBごとに新しいデータエンジンが開かれますが、 mydumper.batch-size設定で変更可能です。

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

E

エンジン

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

TiDB Lightningは、エンジンを介してTiKV Importerにデータを転送します。まずエンジンを開き、KVペアを（順序は問わず）エンジンに送信し、最後にエンジンを閉じます。エンジンは閉じた後、受信したKVペアをソートします。閉じられたエンジンは、TiKVストアにアップロードして取り込みを行うことができます。

エンジンは TiKV インポーター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のパフォーマンスを決定づける要因です。

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

K

KVペア

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

KVエンコーダ

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

L

ローカルチェックサム

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

北

通常モード

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

P

後処理

データソース全体が解析され、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は「sorted string table（ソートされた文字列テーブル）」の略です。SSTファイルは、RocksDB（およびTiKV）のKVペアのコレクションのネイティブstorage形式です。

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