こんにちは、にいるです。
今回もData Architecture and Management デザイナー試験関連です。
「大量データ(LDV)」に対する処理の最適化について、まとめてみたいと思います。
1.大量データの更新について
更新すべきデータが大量にある場合、無作為に更新することは危険です。
数百万件〜億単位でレコードが存在している場合、これらをエンドユーザの業務終了後に更新しないといけないとなると時間が限られてますよね。
なので、事前に綿密なスケジュールと対策を準備しておく必要があります。
ここでは、対策について、紹介していきます。
2.大量データをチャンクする方法
データが大量にある場合は、もうデータを分けるしかないです。
というのも大量データに対するDML操作が処理落ちする原因はタイムアウトです。
タイムアウトしないためには大量データの母数を分けておいて、順次データローダやApexの一括処理で抽出、更新していくしかありません。
このデータの分割を「チャンク」と言います。
チャンクする方法は、まずは自動採番項目を作成します。
次にその自動採寸番号を数値型にする数式項目を作成します。
そして、その数値型の数式項目にカスタムインデックスを設定します。
あとは、比較演算子(<=,<,>,>=)を使用した範囲検索を作成するだけです。
トランザクションデータが大量に発生し、将来的に更新が発生するオブジェクトについては予め、自動採番項目を作っておいた方がいいですね。
さらに、この数式項目に値が入っているかも下記のSOQLで確認しておきましょう。
|
1 2 |
Select FormulaId__c From sObject Order by ExportID__c Asc null last Limit 1; Select FormulaId__c From sObject Order by ExportID__c Desc null last Limit 1; |
最後に、下記のようにWHERE句を変更して抽出します。
|
1 2 3 4 5 |
SELECT Name, Id FROM sObject WHERE FormulaId__c > 1000000 AND FormulaId__c <= 1200000 ; |
事故ったあとでは遅いので、二重確認できるのであれば他の人にも抽出ロジックはうるさいくらいに確認しておきましょう。
3.データ抽出・更新時の注意事項
データ更新はBulk APIを使用し並列モードで実行します。
・Bulk APIについてはこちらからご覧ください。
並列モードの注意点として、親レコードに対するレコードロックの競合が発生する可能性があります。
この場合、エラーとなりそのレコードは更新に失敗します。
失敗したレコードがある場合、もう一度、更新をする必要があるので対象のリスト化をしておきましょう。
また、クエリを実行するユーザはシステム管理者で実行してください。（おそらくないと思いますが）
全てのレコードにアクセスできて管理者でないと予期せぬエラーが発生し、異常終了する可能性が高くなります。
最後に失敗したとしてもリカバリーの導線を考えておくことも重要です。
4.まとめ
いかがでしたでしょうか。
実務でマスタ整備することがあるので、データ更新は本当に注意しています。
顧客情報はクライアントの資産であるため、本当に更新は怖いです笑
できればしたくないですが、そんなこと言ってると導入も改修もできないので、ITである以上はついて回るタスクですね！
皆さんもデータの取り扱いには十分に注意してください。
他にも色々と標準機能やSalesforce機能について紹介していますので、ご覧ください。
ではでは！
コメント