50 TiB データのインポートに関するベストプラクティス
このドキュメントでは、TiDBへの大容量データのインポートに関するベストプラクティスを解説します。データのインポートに影響を与える重要な要素や手順も含まれています。弊社では、50TiBを超える大規模な単一テーブルのデータを社内環境とお客様の環境の両方にインポートした実績があり、これらの実際のアプリケーションシナリオに基づいたベストプラクティスを蓄積してきました。これにより、よりスムーズかつ効率的にデータをインポートできるようになります。
TiDB Lightning （ 物理インポートモード ）は、空のテーブルにデータをインポートしたり、空のクラスターを初期化したりするために使用される包括的で効率的なデータインポートツールであり、ファイルをデータソースとして使用します。TiDB TiDB Lightningは、単一インスタンスと並行輸入 2つの実行モードを提供します。さまざまなサイズのソースファイルをインポートできます。
- ソース ファイルのデータ サイズが 10 TiB 以内の場合は、インポートにTiDB Lightningの単一インスタンスを使用することをお勧めします。
- ソースファイルのデータサイズが 10 TiB を超える場合は、 並行輸入に対してTiDB Lightningの複数のインスタンスを使用することをお勧めします。
- ソース ファイルのデータ規模が非常に大きい場合 (50 TiB を超える場合)、並列インポートに加えて、ソース データの特性、テーブル定義、およびパラメータ構成に基づいて特定の準備と最適化を行い、大規模データのインポートをよりスムーズかつ高速に実現する必要があります。
次のセクションは、複数のテーブルのインポートと大きな単一のテーブルのインポートの両方に適用されます。
大きな単一テーブルをインポートするためのベスト プラクティスは、特別な要件があるため、次のセクションで別途説明します。
主な要因
データをインポートする際、いくつかの重要な要素がインポートのパフォーマンスに影響を与え、場合によってはインポートが失敗する可能性があります。一般的な重要な要素には、次のようなものがあります。
ソースファイル
- 単一ファイル内のデータが主キーでソートされているかどうか。ソートされたデータは最適なインポートパフォーマンスを実現します。
- 複数のTiDB Lightningインスタンスによってインポートされたソースファイル間に、重複する主キーまたは非NULLの一意のインデックスが存在するかどうか。重複が少ないほど、インポートのパフォーマンスは向上します。
表の定義
- テーブルごとのセカンダリインデックスの数とサイズは、インポート速度に影響を与える可能性があります。インデックスの数が少ないほど、インポートが高速化し、インポート後のスペース消費も少なくなります。
- インデックス データ サイズ = インデックスの数 インデックス サイズ 行数。
圧縮比
- TiDBクラスタにインポートされたデータは圧縮形式で保存されます。圧縮率は事前に計算できません。圧縮率は、データが実際にTiKVクラスタにインポートされた後にのみ判定できます。
- ベスト プラクティスとして、最初にデータの小さな部分 (たとえば、10%) をインポートして、クラスターの対応する圧縮率を取得し、それを使用してデータ インポート全体の圧縮率を推定することができます。
コンフィグレーションパラメータ
region-concurrency: TiDB Lightningのメイン論理処理の同時実行性。send-kv-pairs: 1 回のリクエストでTiDB Lightningから TiKV に送信されるキーと値のペアの数。disk-quota: 物理インポート モードを使用するときに、 TiDB Lightning のローカル一時ファイルによって使用されるディスク クォータ。GOMEMLIMIT: TiDB LightningはGo言語で実装されていますGOMEMLIMIT適切に設定します。
データ検証
データとインデックスのインポートが完了すると、各テーブルに対して
ADMIN CHECKSUMステートメントが実行され、チェックサム値がTiDB Lightningのローカルチェックサム値と比較されます。テーブル数が多い場合、または個々のテーブルに多数の行がある場合、チェックサムフェーズに長い時間がかかることがあります。分析操作
チェックサムが正常に完了すると、各テーブルに対して
ANALYZE TABLEステートメントが実行され、最適な実行プランが生成されます。多数のテーブル、または大量のデータを含む個々のテーブルを扱う場合、分析操作には時間がかかることがあります。関連する問題
50TiBのデータを実際にインポートするプロセスでは、膨大な数のソースファイルや大規模クラスタを扱う場合にのみ発生する特定の問題が発生する可能性があります。製品バージョンを選択する際には、該当する問題が修正されているかどうかを確認することをお勧めします。
v6.5.3、v7.1.0 以降のバージョンでは、次の問題が解決されています。
- 問題-14745 : インポートが完了すると、TiKV インポート ディレクトリに大量の一時ファイルが残ります。
- 問題-6426 : PD レンジスケジュールインターフェースがリージョンの分散に失敗し、タイムアウトの問題が発生する可能性があります。v6.2.0より前のバージョンでは、グローバルスケジューリングはデフォルトで無効になっているため、この問題の発生を回避できます。
- 問題-43079 : TiDB Lightning は、NotLeader エラーの再試行中にリージョンピア情報を更新できません。
- 問題-43291 : 一時ファイルが見つからない場合 (「そのようなファイルまたはディレクトリはありません」というエラー)、 TiDB Lightning は再試行しません。
ソースファイルの準備
- ソースファイルを生成する際は、単一ファイル内で主キーでソートすることをお勧めします。テーブル定義に主キーがない場合は、自動増分主キーを追加できます。この場合、ファイルの内容の順序は関係ありません。
- ソースファイルを複数のTiDB Lightningインスタンスに割り当てる際は、複数のソースファイル間で重複する主キーやnull以外の一意のインデックスが存在する状況を避けるようにしてください。生成されたファイルがグローバルにソートされている場合は、範囲に基づいて異なるTiDB Lightningインスタンスに分散することで、最適なインポートパフォーマンスを実現できます。
- ファイル生成中に各ファイルのサイズが 96 MiB 未満になるように制御します。
- ファイルが非常に大きく、256 MiB を超える場合は、
strict-format有効にします。
storageスペースの見積もり
データのインポートに必要なstorage容量を見積もるには、次の 2 つの方法のいずれかを使用できます。
- 総データサイズをA 、総インデックスサイズをB 、レプリケーション係数を3 、圧縮率をα （通常は約2.5）と仮定すると、全体の占有領域は(A+B)*3/αで計算できます。この方法は主に、データのインポートを実行せずにクラスタトポロジを計画する際に、概算を行うために使用されます。
- データの10%のみをインポートし、実際に使用されている容量に10を掛けることで、そのデータバッチの最終的な容量使用量を推定します。この方法は、特に大量のデータをインポートする場合に、より正確です。
圧縮やスナップショットのレプリケーションなどのバックグラウンド タスクもstorage領域の一部を消費するため、20% のstorage領域を予約することをお勧めします。
設定パラメータを変更する
region-concurrency: TiDB Lightning のメイン論理処理の同時実行性。並列インポート中は、リソースの過負荷と潜在的な OOM 問題を防ぐため、CPU コアの 75% に設定することをお勧めします。send-kv-pairs: TiDB Lightningが1回のリクエストでTiKVに送信するキーと値のペアの数。この値は、send-kv-pairs * row-size < 1 MiBという式に基づいて調整することをお勧めします。v7.2.0以降、このパラメータはsend-kv-sizeに置き換えられ、追加の設定は不要です。disk-quota: TiDB Lightningのソートディレクトリの容量がデータソースのサイズよりも大きいことを確認することをお勧めします。確保できない場合は、disk-quotaTiDB Lightningのソートディレクトリの容量の 80% に設定できます。これにより、 TiDB Lightning は指定されたdisk-quotaに従ってデータを一括でソートして書き込みますが、この方法では完全なソート処理と比較してインポートパフォーマンスが低下する可能性があることに注意してください。GOMEMLIMIT: TiDB LightningはGo言語で実装されています。インスタンスメモリの80%をGOMEMLIMITに設定することで、GoのGCメカニズムによるOOMの発生確率を低減します。
TiDB Lightningパラメータの詳細については、 TiDB Lightning構成パラメータ参照してください。
「チェックサム不一致」エラーを解決する
データ検証中に競合が発生する可能性があります。エラーメッセージは「チェックサムが一致しません」です。この問題を解決するには、必要に応じて以下の手順を実行してください。
- ソースデータで、主キーまたは一意キーの競合がないか確認し、再インポート前に競合を解決してください。ほとんどの場合、これが最も一般的な原因です。
- テーブルの主キーまたは一意キーの定義が適切かどうかを確認してください。適切でない場合は、テーブル定義を修正してデータを再インポートしてください。
- 上記の2つの手順を実行しても問題が解決しない場合は、ソースデータに少量（10%未満）の予期しない競合データが存在するかどうかを確認するために、さらに調査する必要があります。TiDB TiDB Lightningで競合データを検出して解決するには、 競合検出有効にしてください。
チェックポイントを有効にする
大量データのインポートには、 ライトニングチェックポイントを参照し、チェックポイントを有効にすることが必須です。コンテナ環境でTiDB Lightning を動作させている場合、コンテナが終了してチェックポイント情報が削除される可能性があるため、チェックポイント情報の消失を防ぐため、ドライバとして MySQL を優先的に使用することをお勧めします。
インポート中に下流のTiKVの容量が不足した場合は、すべてのTiDB Lightningインスタンスに対してコマンドkill （オプション-9なし）を手動で実行できます。容量をスケールアップした後、チェックポイント情報に基づいてインポートを再開できます。
大きな単一テーブルをインポートするためのベストプラクティス
複数のテーブルをインポートすると、チェックサムと分析の処理時間が長くなり、場合によってはデータのインポート自体にかかる時間を超えることがあります。ただし、通常は設定を調整する必要はありません。複数のテーブルの中に1つ以上の大きなテーブルがある場合は、それらの大きなテーブルのソースファイルを分割し、個別にインポートすることをお勧めします。
このセクションでは、大規模な単一テーブルをインポートするためのベストプラクティスを紹介します。大規模な単一テーブルには厳密な定義はありませんが、一般的には以下のいずれかの基準を満たすものと見なされます。
- テーブルサイズが10 TiBを超えています。
- 幅の広い表では行数が 10 億を超え、列数が 50 を超えます。
ソースファイルを生成する
ソースファイルの準備に記載されている手順に従います。
大きな単一テーブルの場合、グローバル ソートは実行できないが、主キーに基づいて各ファイル内でソートすることが可能であり、ファイルが標準の CSV ファイルである場合は、それぞれ約 20 GiB の大きな単一ファイルを生成することをお勧めします。
次に、 strict-format有効にします。このアプローチにより、 TiDB Lightningインスタンス間でインポートされたファイルの主キーと一意のキーの重複が削減され、 TiDB Lightningインスタンスはインポート前に大きなファイルを分割して、最適なインポート パフォーマンスを実現できます。
クラスタトポロジを計画する
TiDB Lightningインスタンスを準備し、各インスタンスが5TiB～10TiBのソースデータを処理できるようにします。各ノードに1つのTiDB Lightningインスタンスをデプロイ。ノードの仕様については、 TiDB Lightningインスタンスの環境要件参照してください。
設定パラメータを変更する
- TiDB Lightningインスタンスのコア数の
region-concurrency～ 75% を設定します。 send-kv-pairs3200に設定します。この方法はTiDB v7.1.0以前のバージョンに適用されます。v7.2.0以降では、このパラメータはsend-kv-sizeに置き換えられ、追加の設定は不要です。- インスタンスが配置されているノード上のメモリを
GOMEMLIMIT～ 80% に調整します。
インポート プロセス中の PD 散布リージョンのレイテンシーが30 分を超える場合は、次の最適化を検討してください。
- TiKV クラスターで I/O ボトルネックが発生しているかどうかを確認します。
- TiKV
raftstore.apply-pool-sizeデフォルト値の2から4または8に増やします。 - TiDB Lightning
region-split-concurrencyCPU コア数の半分に減らします (最小値は1。
分析操作を無効にする
単一のテーブルが大きい場合（たとえば、行数が 10 億行以上、列数が 50 列以上）、インポート処理中にanalyze操作（ analyze="off" ）を無効にし、インポートが完了した後にANALYZE TABLEステートメントを手動で実行することをお勧めします。
analyzeの設定の詳細については、 TiDB Lightningタスク構成参照してください。
トラブルシューティング
TiDB Lightningの使用中に問題が発生した場合は、 TiDB Lightning のトラブルシューティング参照してください。