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 ファイルにマージし、削除されたエントリをクリーンアップする操作。 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 ファイルはアップロードされ、 摂取したストアにアップロードされます。

Playground
新規
登録なしで TiDB の機能をワンストップでインタラクティブに体験できます。
製品
TiDB Cloud
TiDB
価格
PoC お問い合わせ
エコシステム
TiKV
TiFlash
OSS Insight
© 2024 PingCAP. All Rights Reserved.
Privacy Policy.