データインポートの概要

データインポートとは、外部データをOceanBaseの内部テーブルに書き込むプロセスです。データはローカルパス、オブジェクトストレージ、HDFSなどの外部ストレージに保存されている場合もあれば、他のデータベースから取得する場合もあります。

インポート方法を選択する際は、まずインポート方式（誰がファイルを読み、どのようなSQL/ツールで書き込むか）で判断し、その後データの保存場所とネットワークへのアクセス可能性を確認することをお勧めします。

OceanBaseデータベースのデータインポートソリューションのアーキテクチャは以下のとおりです：

インポート方法

ファイルまたは読み取り可能な外部パス上のデータを内部テーブルに書き込む際、ほとんどのシナリオでは以下の3つの方法から選択できます。これらは異なる実行エントリに対応しており、「データソースタイプ」によって分類されているわけではありません。

ダイレクトロードとは

OceanBaseは一部のインポートステートメントでダイレクトロードを有効にでき、通常の書き込みパスを短縮し、SQL層とMemTableのホットライト圧力を低減することで、大規模ロードのスループットを向上させます。

OceanBaseデータベースはダイレクトロード技術により、中間ステップをスキップして直接SSTableにデータを書き込み、リソース消費（CPU、メモリ）を削減するとともに、効率的な全量または増分データのインポートをサポートします。

技術アーキテクチャ

• 従来のインポート経路（青色の経路）：

  クライアント -> SQL解析 -> トランザクション処理 -> メモリテーブル（MemTable） -> ダンプ -> Minor/Majorマージ -> SSTable

  デメリット：経路が長く、リソース消費が高く、書き込み速度が制限される。

• ダイレクトロード経路（緑色の経路）：

  クライアント -> 型変換 -> 主キーソート（オプション） -> Major SSTable（全量）または Mini SSTable（増分）への直接書き込み

  メリット：

  • SQL、トランザクション、MemTableなどの中間モジュールをスキップし、リソース消費を削減する。
  • データを直接基盤ストレージに書き込むため、複数回のマージによるオーバーヘッドを回避する。

ダイレクトロードのコアメカニズム

• 中間層のスキップ：SQL解析、トランザクション、MemTableをバイパスし、直接SSTableに書き込む。

• 型変換とソート：

  • データ型の変換（例：CSVからOceanBaseテーブル構造へ）。
  • 主キーでソートする（フルインポート時に必須であり、Major SSTableの順序性を保証する）。

概念的には、ダイレクトロードはインポート実行モードであり、独立したデータソースや単独の構文カテゴリではありません。

つまり、ユーザーは通常、「ダイレクトロード」を選択してから構文を選択するわけではなく、まず業務要件に基づいて LOAD DATA、INSERT INTO SELECT、CREATE TABLE AS SELECT または obloader などのインポート方法を選択し、その後、現在の条件下でこれらのパスがダイレクトロード実行に適しているかどうかを判断します。

APPEND、DIRECT(...) などのヒントを有効にするか、テナントレベルのパラメータ default_load_mode に依存する場合、オプティマイザーと実行エンジンは、ステートメントタイプ、実行計画、並列能力、オブジェクト制約などの条件に基づいて、ダイレクトロードモードを採用できるかどうかを判断します。

適用シナリオ

• データ移行と同期。データ移行と同期では、通常、大量の様々な形式のデータを異なるデータソースからOceanBaseデータベースに移行する必要があり、従来のSQLインターフェースの性能では時間的要件を満たせない場合があります。

• 従来のETL。データがソース側で抽出・変換された後、ターゲット側にロードする際、通常は短時間で大量のデータをロードする必要があります。ダイレクトロード技術を使用することで、データインポートの性能が向上します。ETL技術においても、データロードプロセスでダイレクトロード技術を活用することで効率を高めることができます。

• テキストファイルやその他のデータソースからOceanBaseデータベースにデータをロードする際、ダイレクトロード技術を利用することで、データロード効率を向上させることができます。

ダイレクトロードとインポート構文の関係

ダイレクトロードを理解する際、最も混同されやすい点は、それが LOAD DATA、INSERT INTO SELECT、CTAS などの構文と並列するものではなく、実行モードとそれを支える構文との関係 であるということです。

これを次のように理解できます：

• LOAD DATA、INSERT INTO SELECT、CREATE TABLE AS SELECT などのステートメントは「データを読み取り、ターゲットテーブルに書き込む方法」を定義します。
• ダイレクトロードは、「これらのステートメントが条件を満たす場合、より効率的な書き込み方法を採用するかどうか」を定義します。

したがって、同一のインポートステートメントは異なる条件下で異なる実行方法を持つ可能性があります：

• ステートメントは異なるOceanBaseバージョン間で、バージョンの動作の違いにより通常の挿入方式で実行される場合があります。
• ヒント、パラメータ、並列能力、オブジェクト制限などの前提条件を満たす場合、ステートメントはダイレクトロード経路を経由する可能性があります。

例：

• LOAD DATA はファイルインポートシナリオに適しており、ダイレクトロードを経由するかどうかは具体的なヒント、モード、実行条件によって決まります。
• INSERT INTO ... SELECT ... がダイレクトロードを経由できるかどうかは、多くの場合、並列DML（PDML）などの前提条件にも依存します。詳細は 並列DML を参照してください。
• CREATE TABLE AS SELECT は、テーブル作成と同時にデータをロードする場合、条件を満たす場合にダイレクトロード実行と組み合わせることができます。

ダイレクトロードをサポートする代表的なステートメント

以下の表は、一般的なインポートステートメントとダイレクトロードの関係を示しています。

フルダイレクトロードと増分ダイレクトロード

ダイレクトロードは通常、フルダイレクトロードと増分ダイレクトロードの2種類に分けられます。

• フルダイレクトロード

  • フルダイレクトロードは、完全なデータセットを一度にデータベースのデータファイルに直接書き込むために使用されます。この方法はSQL層のインターフェースをバイパスし、データファイル内に直接領域を割り当ててデータを挿入することで、データインポートの効率を向上させます。
  • フルダイレクトロードは、通常、データベースの初期化、データ移行、または大量のデータを迅速にロードする必要がある場合に使用されます。

• 増分ダイレクトロード

  • 増分ダイレクトロードは、既に大量のデータが存在する状況下で、新規データをSQLインターフェースを経由せずに直接データベースのデータファイルに書き込むために使用されます。この方法はSQL層のデータ処理プロセスをバイパスし、新規データを直接データファイルに書き込むことで、データ書き込み効率を向上させます。
  • 増分ダイレクトロードは、通常、大規模なリアルタイムデータ収集、ログ書き込みなどの高スループットデータ書き込みシナリオで使用されます。

両者の違いを理解するために、OceanBaseのLSM-Treeストレージ層を組み合わせて書き込みパスを観察することができます。OceanBaseのストレージ層は主に以下のものです：

1. MemTable：メモリ内の書き込み構造で、高並行更新をサポートします。
2. Mini SSTable：MemTableのダンプによって形成されるディスク構造です。
3. Major SSTable：マージ後に形成される安定したデータファイルで、効率的なクエリに適しています。

通常のインポートでは、データは通常、より完全なトランザクション書き込みとダンプのパスを経由する必要があります。一方、ダイレクトロードでは、実行エンジンはこのパスをできるだけ短縮し、大規模なロード効率を向上させます。フルダイレクトロードと増分ダイレクトロードの違いは、主に書き込み対象の形態、競合処理方法、および適用シナリオに表れます。

フルインポートの概要図：

増分インポートの概要図（競合しないデータのみ表示）：

注意事項

フルダイレクトロードの注意事項

フルダイレクトロードを使用する際は、以下のダイレクトロード機能レベルの制限と説明に注意してください：

• OceanBaseデータベースはV4.3.0バージョンからLOBデータ型のダイレクトロードをサポートしています。

• ダイレクトロード中はテーブルロックがかかり、テーブルに他のデータを書き込むことはできません。プロセス全体を通じてテーブルは読み取り専用となります。

• フルダイレクトロードは、大規模テーブルの初回インポート、10GB～TBレベルのデータ移行、およびCPUとメモリが特に余裕のないシナリオに適しています。これは、ダイレクトロードの実行パスが短く、CPUオーバーヘッドを節約できるためです。

• インポート中は、2つの書き込み操作文を同時に実行することはできません（つまり、1つのテーブルに同時に書き込むことはできません）。これは、インポート中に最初にテーブルロックがかかり、インポート全体を通じて読み取り操作のみが可能になるためです。

• トリガー(Trigger)での使用はサポートされていません。

• 生成列を含むテーブルはサポートされていません（一部のインデックスは隠れた生成列を作成する場合があります。例：KEY idx_c2 (c2(16)) GLOBAL）。

• Liboblogおよびフラッシュバッククエリ（Flashback Query）はサポートされていません。

• LOAD DATA ステートメントと INSERT INTO SELECT ステートメントで指定パーティションのダイレクトロードを使用する場合、ターゲットテーブルはレプリケーションテーブルであってはならず、自動インクリメント列、識別列、Global Indexを含むことはできません。

• V4.3.5バージョンについて、V4.3.5 BP1バージョン以降のフルダイレクトロードでは、以下の変更があります：

  • ターゲットテーブルの最後のパーティションがHash/Keyパーティションの場合、パーティションレベルのダイレクトロードをサポートします。
  • セッション変数 foreign_key_checks の値がFalseの場合、ダイレクトロード操作は外部キー制約の検証を行いません。

各インポートステートメント固有の使用制限（上記のダイレクトロード機能の制限とは異なる）については、それぞれ以下を参照してください：

• LOAD DATA を使用してダイレクトロードを実行する場合、構文およびステートメントレベルの使用制限については、LOAD DATA構文（MySQLモード）を参照してください。
• INSERT INTO SELECT を使用してダイレクトロードを実行する場合、構文およびステートメントレベルの使用制限については、INSERT構文（MySQLモード）を参照してください。

増分ダイレクトロードの注意事項

OceanBaseデータベースはV4.6.0バージョンで増分ダイレクトロードが最適化されました。新しい増分ダイレクトロード戦略では、データを2つの部分に分割します。既存データの主キーと競合する部分はMini SSTable（増分SSTable）に書き込み、競合しない部分は別のMajor SSTable（ベースラインSSTable）に書き込みます。これにより、競合データが少ない場合、新しい増分ダイレクトロード戦略では複数回のインポートが可能で、クエリ性能も低下しません。

増分ダイレクトロードを使用する際、上記のフルダイレクトロードの一般的な制限に加え、以下の増分ダイレクトロード機能レベルの制限にも注意する必要があります：

• 外部キーを持つテーブルは増分ダイレクトロードをサポートしません。
• GLOBAL インデックスを持つテーブルは増分ダイレクトロードをサポートしません。
• 制約を持つテーブルは増分ダイレクトロードをサポートしません。
• 主キーなしで複数の LOCAL 唯一インデックスを持つテーブルは増分ダイレクトロードをサポートしません。
• 唯一インデックスを持つ主キーテーブルは増分ダイレクトロードをサポートしません。

LOAD DATA または INSERT INTO SELECT を使用して増分ダイレクトロードを実行する場合、ステートメントレベルの使用制限については、LOAD DATA構文（MySQLモード） と INSERT構文（MySQLモード） を参照してください。

注意事項

ダイレクトロードを使用する際、以下の共通の注意事項があります（フルおよび増分の両方に適用されます）：

• 増分ダイレクトロードのデータはダンプをトリガーします。データ量が少なく、数分以内にインポートが完了する場合は、増分ダイレクトロードの使用は推奨されません。

• 増分ダイレクトロードは、ターゲットテーブルに非一意のローカルインデックスがある場合をサポートします。

• V4.3.5バージョンについて、V4.3.5 BP1バージョン以降の増分ダイレクトロードでは、以下の変更があります：

  • ターゲットテーブルの最後のパーティションがHash/Keyパーティションの場合、パーティションレベルのダイレクトロードをサポートします。
  • ヒープテーブルにローカル一意インデックスが1つある場合のみをサポートします。ターゲットテーブルに複数のローカル一意インデックスまたはグローバル一意インデックスが存在する場合、インポート操作は失敗します。
  • LOAD DATA/INSERT INTO SELECT ステートメントにおいて、複数のインポートタスクで重複するパーティションが存在する場合、パーティションの並列インポートはサポートされません。重複するパーティションがない場合、パーティションの並列インポートをサポートします。
  • セッション変数 foreign_key_checks の値がFalseの場合、ダイレクトロード操作は外部キー制約の検証を行いません。

関連ドキュメント

• データ転送の概要
• データ移行の概要
• LOAD DATA FROM FILES
• LOAD DATA INFILE
• LOAD DATA LOCAL INFILE
• INSERT INTO SELECT FROM FILES
• 外部テーブルへのINSERT INTO SELECTによるインポート
• CREATE TABLE AS SELECTを使用したインポート
• obloaderを使用したデータインポート

完全なSQLステートメントの参考ドキュメント：

• LOAD DATA（MySQLモード）
• LOAD DATA（Oracleモード）
• INSERT（MySQLモード）
• INSERT（Oracleモード）