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

50 TiB データをインポートするためのベスト プラクティス

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

TiDB Lightning ( 物理インポートモード ) は、空のテーブルへのデータのインポートと空のクラスターの初期化に使用される包括的かつ効率的なデータ インポート ツールであり、データ ソースとしてファイルを使用します。 TiDB Lightning は、単一インスタンスと並行輸入品 2 つの実行モードを提供します。さまざまなサイズのソース ファイルをインポートできます。

  • ソース ファイルのデータ サイズが 10 TiB 以内の場合は、インポートにTiDB Lightningの単一インスタンスを使用することをお勧めします。
  • ソース ファイルのデータ サイズが 10 TiB を超える場合は、 TiDB Lightning for 並行輸入品の複数のインスタンスを使用することをお勧めします。
  • ソース ファイルのデータ規模が非常に大きい (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 は、一時ファイルが見つからない場合 (「そのようなファイルまたはディレクトリはありません」エラー) に再試行しません。

ソースファイルを準備する

  • ソース ファイルを生成するときは、単一​​ファイル内で主キーでソートすることが望ましいです。テーブル定義に主キーがない場合は、自動インクリメント主キーを追加できます。この場合、ファイルの内容の順序は関係ありません。
  • ソース ファイルを複数のTiDB Lightningインスタンスに割り当てる場合は、複数のソース ファイル間に重複する主キーまたは非 null の一意のインデックスが存在する状況を避けるようにしてください。生成されたファイルがグローバルにソートされている場合は、範囲に基づいて異なるTiDB Lightningインスタンスに分散して、最適なインポート パフォーマンスを実現できます。
  • ファイル生成時に各ファイルのサイズが 96 MiB 未満になるように制御します。
  • ファイルが非常に大きく、256 MiB を超える場合は、 strict-formatを有効にします。

storageスペースの見積もり

次の 2 つの方法のいずれかを使用して、データのインポートに必要なstorage容量を見積もることができます。

  • 合計データ サイズをA 、合計インデックス サイズをB 、レプリケーション係数を3 、圧縮率をα (通常は約 2.5) とすると、全体の占有スペースは次のように計算できます: (A+B)*3/ α 。この方法は主に、データのインポートを実行せずに見積もりを行い、クラスター トポロジを計画するために使用されます。
  • データの 10% のみをインポートし、実際に占有されているスペースを 10 倍して、そのデータ バッチの最終的なスペース使用量を見積もります。この方法は、特に大量のデータをインポートする場合に、より正確です。

圧縮やスナップショットレプリケーションなどのバックグラウンドタスクもstorageスペースの一部を消費するため、storageスペースの 20% を予約することをお勧めします。

構成パラメータを変更する

  • region-concurrency : TiDB Lightningのメイン論理処理の同時実行数。並行インポート中は、リソースの過負荷と潜在的な OOM の問題を防ぐために、CPU コアの 75% に設定することをお勧めします。
  • send-kv-pairs : 1 回のリクエストでTiDB Lightningによって TiKV に送信されるキーと値のペアの数。この値は、send-kv-pairs * row-size < 1 MiB の式に基づいて調整することをお勧めします。
  • disk-quota : TiDB Lightningのソート ディレクトリ スペースがデータ ソースのサイズよりも大きいことを確認することをお勧めします。それを確保できない場合は、 TiDB Lightningのソート ディレクトリ領域のdisk-quota ～ 80% を設定できます。このように、 TiDB Lightning は、指定されたdisk-quotaに従ってデータをバッチで並べ替えて書き込みますが、このアプローチでは、完全な並べ替えプロセスと比較してインポート パフォーマンスが低下する可能性があることに注意してください。
  • GOMEMLIMIT : TiDB Lightning はGo 言語で実装されています。 Go GC メカニズムによって引き起こされる OOM の可能性を減らすために、インスタンスメモリのGOMEMLIMIT ～ 80% を設定します。

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

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

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

  1. ソース データで、競合する主キーまたは一意キーがないか確認し、再インポートする前に競合を解決します。ほとんどの場合、これが最も一般的な原因です。
  2. テーブルの主キーまたは一意キーの定義が適切かどうかを確認してください。そうでない場合は、テーブル定義を変更し、データを再インポートします。
  3. 前の 2 つの手順を実行しても問題が解決しない場合は、ソース データに少量 (10% 未満) の予期しない競合データが存在するかどうかを判断するために、さらに調査する必要があります。 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インスタンスを準備して、各インスタンスが 5 TiB ～ 10 TiB のソース データを処理できるようにします。各ノードに 1 つのTiDB Lightningインスタンスをデプロイ。ノードの仕様については、 TiDB Lightningインスタンスの環境要件を参照してください。

構成パラメータを変更する

  • TiDB Lightningインスタンスのコア数のregion-concurrency ～ 75% を設定します。
  • send-kv-pairs ～ 3200を設定します。この方法は、TiDB v7.1.0 以前のバージョンに適用されます。
  • インスタンスが配置されているノード上のメモリの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のトラブルシューティングを参照してください。

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