📣
TiDB Cloud Essential はパブリックプレビュー中です。このページは自動翻訳されたものです。原文はこちらからご覧ください。

IMPORT INTO とTiDB Lightning の比較

多くのユーザーから、 TiDB Lightningの展開、構成、メンテナンスは、特に並行輸入の大規模なデータセットが関係するシナリオでは複雑であるというフィードバックが寄せられています。

皆様からのフィードバックに基づき、TiDBはTiDB Lightningの一部の機能をIMPORT INTO SQL文に段階的に統合してきました。3 IMPORT INTO実行することでデータを直接インポートできるため、データインポートの効率が向上します。さらに、 IMPORT INTO自動分散タスクスケジューリングやTiDB グローバルソートといった、 TiDB Lightningにはない機能もサポートされています。

IMPORT INTOはv7.2.0で導入され、v7.5.0で一般提供(GA)されます。今後のバージョンでも引き続き改良と最適化が行われます。2 IMPORT INTO機能がTiDB Lightningを完全に置き換えることが可能になった時点で、 TiDB Lightningは廃止されます。その際には、TiDBのリリースノートおよびドキュメントで事前にお知らせいたします。

IMPORT INTOとTiDB Lightningの比較

次のセクションでは、 IMPORT INTOとTiDB Lightningの違いをさまざまな側面から説明します。

導入コスト

IMPORT INTO

IMPORT INTO個別のデプロイメントを必要としません。TiDB ノード上で直接実行できるため、追加のデプロイメント作業が不要になります。

TiDB Lightning

対照的に、 TiDB Lightning個別のサーバー展開必要です。

リソースの活用

IMPORT INTO

IMPORT INTOタスクと他のビジネスワークロードは、TiDB リソースを共有したり、異なるタイミングで利用したりすることで、TiDB リソースを最大限に活用できます。3 タスクのパフォーマンスと安定性を維持しながら、ビジネスワークロードの安定した運用を確保するために、 IMPORT INTOタスクにデータインポート専用の特定のTiDBノードを指定することができIMPORT INTO

TiDB グローバルソート使用する場合、大容量のローカルディスクをマウントする必要はありません。TiDB Global Sort は Amazon S3 をstorageとして使用できます。インポートタスクが完了すると、グローバルソート用に Amazon S3 に保存された一時データは自動的に削除され、storageコストを節約できます。

TiDB Lightning

TiDB Lightning をデプロイして実行するには、別々のサーバーが必要です。インポートタスクが実行されていない場合、これらのリソースはアイドル状態のままになります。インポートタスクが定期的に実行されるシナリオでは、合計アイドル時間はさらに長くなり、リソースの無駄が発生します。

インポートするデータセットが大きい場合は、インポートするデータをソートするための大容量のローカル ディスクも準備する必要があります。

タスクの構成と統合

IMPORT INTO

You can directly write SQL statements to submit import tasks, which are easy to call and integrate.

TiDB Lightning

対照的に、 TiDB Lightningタスク設定ファイル記述する必要があります。これらの構成ファイルは複雑であり、サードパーティが簡単に呼び出すことはできません。

タスクのスケジュール

IMPORT INTO

IMPORT INTO分散実行をサポートします。例えば、40TiBのソースデータファイルを1つのターゲットテーブルにインポートする場合、SQL文の送信後、TiDBはインポートタスクを複数のサブタスクに自動的に分割し、各サブタスクを実行するために異なるTiDBノードをスケジュールします。

TiDB Lightning

対照的に、 TiDB Lightningの構成は複雑で非効率であり、エラーが発生しやすくなります。

10 個のTiDB Lightningインスタンスを起動してデータを並列インポートする場合、10 個のTiDB Lightning設定ファイルを作成する必要があります。各ファイルでは、対応するTiDB Lightningインスタンスが読み取るソースファイルの範囲を設定する必要があります。例えば、 TiDB Lightningインスタンス 1 は最初の 100 ファイルを読み取り、インスタンス 2 は次の 100 ファイルを読み取り、というように続きます。

さらに、これら 10 個のTiDB Lightningインスタンスの共有メタデータ テーブルやその他の構成情報を構成する必要があり、これは複雑です。

グローバルソートとローカルソート

IMPORT INTO

TiDB Global Sort を使用すると、 IMPORT INTO十 TiB のソースデータを複数の TiDB ノードに送信し、データ KV ペアとインデックス KV ペアをエンコードしてから、これらのペアを Amazon S3 に転送してグローバルソートしてから、TiKV に書き込むことができます。

これらのKVペアはグローバルにソートされているため、複数のTiDBノードからTiKVにインポートされたデータは重複せず、RocksDBに直接書き込むことができます。これにより、TiKVによる圧縮操作が不要になり、TiKVの書き込みパフォーマンスと安定性が大幅に向上します。

インポートが完了すると、Amazon S3 上のグローバルソートに使用されたデータは自動的に削除され、storageコストを節約できます。

TiDB Lightning

TiDB Lightningはローカルソートのみをサポートします。例えば、数十TiB規模のソースデータの場合、 TiDB Lightningに大容量のローカルディスクが設定されていない場合、または複数のTiDB Lightningインスタンスを並列インポートに使用している場合、各TiDB Lightningインスタンスはローカルディスクを使用してのみインポートデータをソートできます。グローバルソートを実行できないため、複数のTiDB LightningインスタンスからTiKVにインポートされたデータに重複が生じ、特にインデックスデータが多いシナリオでは、TiKVは圧縮操作を実行します。圧縮操作はリソースを大量に消費するため、TiKVの書き込みパフォーマンスと安定性が低下します。

後日データのインポートを継続する場合は、次回のインポートのためにTiDB Lightningサーバーとサーバー上のディスクを保持しておく必要があります。事前割り当てディスクを使用する場合のコストは、Amazon S3を従量課金制で使用したIMPORT INTOと比較して比較的高くなります。

パフォーマンス

現在、 IMPORT INTOとTiDB Lightningの間で同等のテスト環境下でのパフォーマンステスト比較結果はありません。

グローバルソートのstorageとして Amazon S3 を使用した場合、 IMPORT INTOのパフォーマンステスト結果は次のとおりです。

ソースデータセットノード構成TiDBノードあたりの平均インポート速度
40 TiB のデータ (22.6 億行、行あたり 19 KiB)10個のTiDB(16C32G)ノードと20個のTiKV(16C27G)ノード222 GiB/時
10 TiB のデータ (5 億 6,500 万行、行あたり 19 KiB)5つのTiDB(16C32G)ノードと10つのTiKV(16C27G)ノード307 GiB/時

高可用性

IMPORT INTO

TiDB ノードに障害が発生すると、そのノード上のタスクは残りの TiDB ノードに自動的に転送され、実行が継続されます。

TiDB Lightning

TiDB Lightningインスタンス ノードに障害が発生した場合、以前に記録されたチェックポイントに基づいて、新しいノードでタスクの手動リカバリを実行する必要があります。

スケーラビリティ

IMPORT INTO

Due to the use of Global Sort, data imported into TiKV does not overlap, resulting in better scalability compared with TiDB Lightning.

TiDB Lightning

ローカルソートのみをサポートしているため、新しいTiDB Lightningインスタンスが追加されたときに TiKV にインポートされたデータが重複する可能性があり、その結果 TiKV の圧縮操作が増え、 IMPORT INTOに対するスケーラビリティが制限されます。

IMPORT INTOでサポートされていない機能

現在、 IMPORT INTOはまだいくつかの機能が欠けており、次のようなシナリオではTiDB Lightning を完全に置き換えることはできません。

  • 論理インポート

    IMPORT INTOでデータをインポートする前に、ターゲットテーブルは空である必要があります。既にデータが含まれているテーブルにデータをインポートする必要がある場合は、 LOAD DATAや直接挿入などの方法を使用することをお勧めします。TiDB v8.0以降、大規模トランザクションの実行にはバルクDMLサポートされます。

  • 競合データの処理

    IMPORT INTO現在、競合データの処理をサポートしていません。データのインポート前に、インポートするデータが主キー(PK)または一意キー(UK)と競合しないように、テーブルスキーマを適切に定義する必要があります。そうしないと、タスクが失敗する可能性があります。

  • 複数のターゲットテーブルへのデータのインポート

    現在、 IMPORT INTO SQL文で指定できるターゲットテーブルは1つだけです。複数のターゲットテーブルにデータをインポートする場合は、 IMPORT INTOのSQL文を発行する必要があります。

将来のバージョンでは、これらの機能はIMPORT INTOでサポートされる予定です。また、タスク実行中の同時実行性の変更やTiKVへの書き込みスループットの調整といった機能強化も行われます。これにより、タスク管理がより便利になります。

まとめ

TiDB Lightningと比較すると、 IMPORT INTO TiDBノード上で直接実行でき、自動化された分散タスクスケジューリングとTiDB グローバルソートサポートし、デプロイメント、リソース利用率、タスク設定の利便性、呼び出しと統合の容易さ、高可用性、スケーラビリティにおいて大幅な改善をもたらします。適切なシナリオでは、 TiDB LightningではなくIMPORT INTO使用を検討することをお勧めします。

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