大量のデータ・インポートのベスト・プラクティスを教えてください。
大量のデータ・インポートのベスト・プラクティスをいくつか次に示します。
CX SalesおよびB2B Serviceインスタンスに大量のデータをロードする必要がある場合があります。 たとえば、最初のロールアウト時に、CX SalesおよびB2B Serviceの使用を他のユーザーまたはディビジョンに拡張したり、CX Sales and Fusion Serviceの使用を拡張して他のオブジェクト・タイプを含めます(サービス・オブジェクトのサポートの追加など)。
大量のデータをCX Sales and Fusion Serviceにロードする場合、重要な考慮事項の1つはデータのインポートにかかる時間です。 データ・インポートを実行する期間が制限されている場合(週末の移行など)、大量のデータをインポートするために必要な時間を短縮することが重要です。 Oracleでは、データ・インポートのパフォーマンスを向上するために使用できる特定のベスト・プラクティスを推奨しています。
実際のスループットは、各レコードに含まれるデータの量、データ・インポート中に作成される関係の数、ソース・ファイル内のレコード数など、様々なファクタに基づいてユーザーによって異なります。
本番環境でデータ・インポートを実行する前に、Oracleでは、テスト環境で次の機能検証およびパフォーマンス最適化の手順を実行することをお薦めします:
-
データ・クレンジング
-
機能インポートの検証
-
最適化プロセス
テスト環境でこれらの演習を行うことで、これらの演習が本番環境内の既存の操作やデータに影響を与えないようにします。
データ・クレンジング
大量のインポートに進む前に、インポートするデータを完全に消去する必要があります。 データが正しい形式であることを確認すると、データ・インポート中に発生したエラーの数が少なくなります。 これにより、2つの方法で全体のスループットが向上します:
-
インポートできないレコードのインポートを試行しても、処理時間は無駄になりません。
-
エラー・ログをレビューし、問題を修正し、データを再インポートする必要はありません。 データ・インポートを試行する前にデータをクレンジングするコストは、データ・インポート中に発生する問題を修正するコストより少なくなります。
データをクリーニングする場合は、次の点に注意してください:
-
フィールド長 - データがOSCの最大フィールド長を超えないようにしてください
-
データ型 - OSCでのインポート先フィールドのデータが正しいタイプであることを確認してください
-
必須 - すべての必須フィールドに値が指定されていることを確認してください
-
条件付きで必須 - 場合によっては、別のフィールドに指定された値に基づいて値が必須になります(たとえば、商談の場合、商談の状況がクローズに設定されている場合はクローズ日が必要です)
-
外部キー - 外部キーに有効な値を指定して、レコード間の関係を作成します。 外部キーは、オブジェクトごとに異なる場合があります。
データを確実にクリーンにすることで、レガシー・アプリケーションからCX Sales and Fusion Serviceへのデータのインポートに関連する多くの問題を回避できます。
機能インポートの検証
データを正常にクリーンアップしたことを確認するために、Oracleでは、少数のデータ・セットを使用してテスト環境でインポートを検証することをお薦めします。 機能インポートを検証するには、次のガイドラインに従います:
-
大量のデータをインポートする前に、インポートが正常に完了し、結果のデータが期待したデータと一致していることを確認してください。 これには、データが正しいオブジェクトにインポートされたり、フィールドが正しくマップされたり、関係が正しくインポートされたりすることが含まれます。
-
各属性の値を含む少数のレコードをインポートします。 Oracleでは、完全なデータ・セットに存在するバリエーションを保存できる最小限の入力データ・セットを使用することをお薦めします。
-
インポート・ログ・ファイルでレポートされるデータの問題を特定します。 エラーのある行についてレポートされた特定の問題を修正します。 エラーがレポートされない行については、その行を再インポートしないでください。 すべての問題を解決し、データのサブセットを正常にインポートした後、大きなデータ・セットに変更を適用します(たとえば、タイム・スタンプ書式が正しくないと判断した場合、入力データ・ファイル内の全データ・セットのすべてのレコードに対して、この問題を解決します)。
最適化プロセス
大量のデータのインポートはプロジェクトであり、実装のプロジェクト計画に含める必要があります。 データの実際のインポートと、データ・セットのインポート・プロセスの設計および最適化に時間を割り当てる必要があります。
データ・インポートを最適化する場合は、入力データ・ファイルに含めるレコードの数と、アクティブ化できる同時インポート・アクティビティの数を識別します。 複数のデータ・インポート操作を同時に実行することで、コンカレント・インポート・アクティビティをトリガーします。 同時インポート・アクティビティの数は、実行中でまだ完了していないデータ・インポートの数です。 インポート・アクティビティをシリアルに実行したり、多数のインポート・アクティビティを同時に実行すると、スループットが低下する可能性があります。 これら2つのパラメータの正しい値を見つけることは、インポート・プロセスを設計する重要な側面です。 あらゆる状況に対して正しい答えはありません。 すべてのデータ・セットが異なるため、実行する新しいデータ・インポート操作に対してこのプロセスを繰り返す必要があります。
1回のインポート操作で100,000を超えるレコードをインポートしたり、5つ以上の同時インポート・アクティビティを実行したりしないでください。
Oracleでは、大量のデータ・インポートを計画する際に、このプロセスに従うことをお薦めします:
-
ベースライン・パフォーマンスの確立
-
インポート・ボリュームのスケール・アップ
-
コンカレント・インポート・アクティビティの最適化
これらの各ステップについて詳しく説明します。
ベースライン・パフォーマンスの設定
Oracleでは、データをクレンジングしてインポートが機能的に正しいことを検証した後、インポート・ボリュームのスケール・アップのプロセスを開始することをお薦めします。 このプロセスの最初のステップは、パフォーマンス・ベースラインの確立です。 これには、大量のレコードを使用した一連のシリアル・インポートの実行が含まれます。
Oracleでは、1回のインポート・アクティビティで少数のレコード(数百から数千のレコード)をインポートすることをお薦めします。 たとえば、各レコード2,500件の4つのインポート・アクティビティを使用して、10,000件のレコードをインポートできます。 これらのデータ・インポート・アクティビティが完了したら、レコードのインポートを完了し、全体的なスループット(1秒当たりのインポートされたレコード数)を計算するのに必要な時間に注意してください。
データ・インポート操作間の時間を追跡することもできます。
インポート・ボリュームのスケール・アップ
ベースラインを設定した後、入力ファイルのレコード数を増やし、複数のインポートを同時に実行することができます。 ボリュームを制御された方法でスケーリングし、すべてのステップでスループットをノートします。
コンカレント・インポート・アクティビティの最適化
複数のインポート・アクティビティを同時に実行できます。 これにより、同じインポートを順次実行するのではなく、全体のスループットが向上します。 最適な同時インポート・アクティビティの数は、オブジェクトやユースケースによって異なります。最も効率的なデータ・インポート計画を特定するには、本番データ・ロードを開始する前にテストを実行する必要があります。
最初のアクティビティの処理中に新しいインポート・アクティビティを発行することで、複数のデータ・インポート・アクティビティを同時に実行できます。 CX Sales and Fusion Serviceでは、2番目のアクティビティを開始する前に最初のアクティビティが完了するまで待機せずに、両方のインポート・アクティビティを処理します。 追加のデータ・インポート・アクティビティに対して、複数のデータ・インポート・アクティビティを同時に実行できます。
たとえば、最初にテストを実行して、それぞれ50,000件のレコードの4つのシリアル・アクティビティを使用して200,000件のレコードをインポートするときにスループットを測定します。 次の表に示すように、テストを実行して合計600,000のレコードをインポートできます:
テスト番号 |
レコードの合計数 |
アクティビティごとのレコード数 |
アクティビティ数 |
同時 |
平均スループット |
---|---|---|---|---|---|
1 |
200,000 |
50,000 |
4 |
シリアル |
|
2.1 |
100,000 |
50,000 |
2 |
コンカレント |
|
2.2 |
200,000 |
50,000 |
4 |
コンカレント |
|
2.3 |
300,000 |
50,000 |
6 |
コンカレント |
すべてのステップで、平均スループットに注意する必要があります。 スループットが低下しているポイントに達した場合、最適な並行性を超えた可能性があります。 テストを繰り返して、正しい結論を出すための十分なデータ・ポイントがあることを確認できます。
一部のレコード・タイプに添付ファイルをインポートできます。 添付のインポートはインポート・パフォーマンスに影響するため、データ・インポート・アクティビティを計画する際に考慮する必要があります。
また、入力データ・ファイルのレコード数に基づいてデータ・インポートを調整することもできます。 たとえば、25,000レコードから開始し、毎回の実行で25,000レコード増加します。 各バッチのレコード数を増やすと、平均スループットに注意してください。 スループットが低下しているポイントに達した場合は、最適なレコード数を超えた可能性があります。 Oracleでは、1つのインポート・アクティビティに100,000を超えるレコードをインポートし、5つの同時インポート・アクティビティを超えることをお薦めしません。
サイズ
多くの新規ユーザーの追加や大量のデータ・インポートの実行など、使用パターンが大きく変更されると、ポッド・サイジング評価が変更される可能性があります。 組織で生成されたインポート・データ量を処理するための環境のサイズが、ユーザーによって実行される他の操作とともに正しく設定されていることを確認します。 大量のインポート・プロセスまたは1回かぎりのデータ・ロードを開始する前に、Oracleでサイズ設定を確認することをお薦めします。 このレビュー・プロセスを開始するには、Oracleヘルプ・デスクに連絡してください。