IMPORT INTO とTiDB Lightning の比較
多くのユーザーから、 TiDB Lightningのデプロイ、構成、メンテナンスは、特に並列インポートの大規模なデータセットが関係するシナリオでは複雑であるというフィードバックが寄せられています。
皆様からのフィードバックに基づき、TiDBはTiDB Lightningの一部の機能をIMPORT INTO SQL文に段階的に統合してきました。IMPORT INTOを実行することでデータを直接インポートできるため、データインポートの効率が向上します。さらに、 IMPORT INTOは自動分散タスクスケジューリングやTiDB グローバルソートといった、 TiDB Lightningにはない機能もサポートされています。
IMPORT INTOはv7.2.0で導入され、v7.5.0で一般提供（GA）されます。今後のバージョンでも引き続き改良と最適化が行われます。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 リソースを最大限に活用できます。IMPORT INTOタスクのパフォーマンスと安定性を維持しながら、ビジネスワークロードの安定した運用を確保するために、データインポート用にIMPORT INTO専用の特定のTiDBノードを指定することができます。
TiDB グローバルソートを使用する場合、大容量のローカルディスクをマウントする必要はありません。TiDB Global Sort は Amazon S3 をストレージとして使用できます。インポートタスクが完了すると、グローバルソート用に Amazon S3 に保存された一時データは自動的に削除され、ストレージコストを節約できます。
TiDB Lightning
TiDB Lightning をデプロイして実行するには、別々のサーバーが必要です。インポートタスクが実行されていない場合、これらのリソースはアイドル状態のままになります。インポートタスクが定期的に実行されるシナリオでは、合計アイドル時間はさらに長くなり、リソースの無駄が発生します。
インポートするデータセットが大きい場合は、インポートするデータをソートするための大容量のローカルディスクも準備する必要があります。
タスクの構成と統合
IMPORT INTO
SQL文を直接記述してインポートタスクを送信でき、呼び出しと統合が容易です。
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 上のグローバルソートに使用されたデータは自動的に削除され、ストレージコストを節約できます。
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の間で同等のテスト環境下でのパフォーマンステスト比較結果はありません。
グローバルソートのストレージとして Amazon S3 を使用した場合、 IMPORT INTOのパフォーマンステスト結果は次のとおりです。
高可用性
IMPORT INTO
TiDB ノードに障害が発生すると、そのノード上のタスクは残りの TiDB ノードに自動的に転送され、実行が継続されます。
TiDB Lightning
TiDB Lightningインスタンス ノードに障害が発生した場合、以前に記録されたチェックポイントに基づいて、新しいノードでタスクの手動リカバリを実行する必要があります。
スケーラビリティ
IMPORT INTO
Global Sortを使用しているため、TiKVにインポートされるデータが重複せず、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 INTOSQL文で指定できるターゲットテーブルは1つだけです。複数のターゲットテーブルにデータをインポートする場合は、IMPORT INTOのSQL文を発行する必要があります。
将来のバージョンでは、これらの機能はIMPORT INTOでサポートされる予定です。また、タスク実行中の同時実行性の変更やTiKVへの書き込みスループットの調整といった機能強化も行われます。これにより、タスク管理がより便利になります。
まとめ
TiDB Lightningと比較すると、 IMPORT INTOはTiDBノード上で直接実行でき、自動化された分散タスクスケジューリングとTiDB グローバルソートをサポートし、デプロイメント、リソース利用率、タスク設定の利便性、呼び出しと統合の容易さ、高可用性、スケーラビリティにおいて大幅な改善をもたらします。適切なシナリオでは、 TiDB LightningではなくIMPORT INTOの使用を検討することをお勧めします。