TiDB Cloud
TiDB Self-Managed
Learning Center
お問い合わせ

50 TiB データのインポートに関するベスト プラクティス

このドキュメントでは、データのインポートに影響するいくつかの重要な要素と手順を含む、大量のデータを TiDB にインポートするためのベスト プラクティスについて説明します。当社は、50 TiB を超える大規模な単一テーブルのデータを社内環境と顧客環境の両方に正常にインポートしており、これらの実際のアプリケーション シナリオに基づいてベスト プラクティスを蓄積しています。これにより、データをよりスムーズかつ効率的にインポートできるようになります。

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ステートメントが実行され、最適な実行プランが生成されます。多数のテーブルや大量のデータを含む個々のテーブルを処理する場合、分析操作には時間がかかることがあります。

  • 関連する問題

    実際に 50 TiB のデータをインポートするプロセスでは、膨大な数のソース ファイルと大規模なクラスターを処理する場合にのみ発生する特定の問題が発生する可能性があります。製品バージョンを選択するときは、該当する問題が修正されているかどうかを確認することをお勧めします。

    v6.5.3、v7.1.0 以降のバージョンでは、次の問題が解決されています。

    • 問題-14745 : インポートが完了すると、TiKV インポート ディレクトリに大量の一時ファイルが残ります。
    • 問題-6426 : PD 範囲スケジュールインターフェイスが領域を分散できず、タイムアウトの問題が発生する可能性があります。v6.2.0 より前では、グローバル スケジューリングはデフォルトで無効になっているため、この問題の発生を回避できます。
    • 問題-43079 : TiDB Lightning は、 NotLeader エラーの再試行中にリージョンピア情報を更新できません。
    • 問題-43291 : 一時ファイルが見つからない場合 (「そのようなファイルまたはディレクトリはありません」というエラー)、 TiDB Lightning は再試行しません。

ソースファイルの準備

  • ソース ファイルを生成するときは、1 つのファイル内で主キーで並べ替えることをお勧めします。テーブル定義に主キーがない場合は、自動増分主キーを追加できます。この場合、ファイルの内容の順序は関係ありません。
  • ソース ファイルを複数の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領域の一部を消費するため、storage領域の 20% を予約することをお勧めします。

設定パラメータを変更する

  • 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-quota TiDB Lightningのソートディレクトリ領域の 80% に設定できます。このように、 TiDB Lightning は指定されたdisk-quotaに従ってデータをバッチでソートして書き込みますが、この方法では完全なソートプロセスと比較してインポートのパフォーマンスが低下する可能性があることに注意してください。
  • GOMEMLIMIT : TiDB Lightning はGo 言語で実装されています。インスタンスメモリの 80% をGOMEMLIMITに設定すると、Go GC メカニズムによって発生する OOM の可能性が減ります。

TiDB Lightningパラメータの詳細については、 TiDB Lightning構成パラメータ参照してください。

「チェックサム不一致」エラーを解決する

データ検証中に競合が発生する可能性があります。エラー メッセージは「チェックサムが一致しません」です。この問題を解決するには、必要に応じて次の手順を実行します。

  1. ソース データで競合する主キーまたは一意キーがないか確認し、再インポートする前に競合を解決します。ほとんどの場合、これが最も一般的な原因です。
  2. テーブルの主キーまたは一意キーの定義が適切かどうかを確認します。適切でない場合は、テーブル定義を変更してデータを再インポートします。
  3. 前の 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インスタンスはインポート前に大きなファイルを分割して、最適なインポート パフォーマンスを実現できます。

クラスタトポロジを計画する

各インスタンスが 5 TiB ～ 10 TiB のソース データを処理できるように、 TiDB Lightningインスタンスを準備します。各ノードに 1 つのTiDB Lightningインスタンスをデプロイ。ノードの仕様については、 TiDB Lightningインスタンスの環境要件を参照してください。

設定パラメータを変更する

  • TiDB Lightningインスタンスのコア数のregion-concurrency ～ 75% を設定します。
  • send-kv-pairsを3200に設定します。この方法は、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-concurrency CPU コア数の半分に減らします (最小値は1 )。

分析操作を無効にする

単一のテーブルが大きい場合（たとえば、行数が 10 億行以上、列数が 50 列以上）、インポート処理中にanalyze操作（ analyze="off" ）を無効にし、インポートが完了した後にANALYZE TABLEステートメントを手動で実行することをお勧めします。

analyzeの設定の詳細については、 TiDB Lightningタスク構成を参照してください。

トラブルシューティング

TiDB Lightningの使用中に問題が発生した場合は、 TiDB Lightningシューティング参照してください。

このページは役に立ちましたか？