データの削除および抽出の実行

学習の目的

この単元を完了すると、次のことができるようになります。

Salesforce Bulk API のデータ削除メカニズムを使用して、大量データの操作時のパフォーマンスを向上させる。
PK Chunking を使用して、組織から大量データを抽出するときのパフォーマンス低下に対処する。
削除を加速するためにカスタムオブジェクトにあるレコードを切り捨てることのメリットを理解する。

Bulk API を使用した削除および抽出

Salesforce 組織について言えば、データ管理は常に最上位の優先事項です。データの削除および抽出もこうした管理の一環です。そして、大量データの読み込みの場合と同様に、LDV の削除または抽出においても Bulk API が役立ちます。100 万件以上のレコードの削除を伴うプロセスがあるときは、Bulk API の物理削除オプションが効果的です。

論理削除と物理削除

Salesforce のデータ削除メカニズムを使用すると、大量データのパフォーマンスに大きな効果を及ぼすことができます。Salesforce では、ユーザーがデータを削除するとごみ箱に入れられますが、そのデータは削除される代わりに、削除済みのフラグが付けられ、ごみ箱に表示されます。このプロセスを論理削除といいます。論理削除されたデータは、依然として組織に存在するためデータベースのパフォーマンスに影響するほか、削除済みのデータをクエリから除外する必要があります。

データはごみ箱に 15 日間、またはごみ箱が特定のサイズに達するまで保存されます。期限またはサイズ制限に達した時点、あるいは UI、API、Apex のいずれかを使用してごみ箱が空にされたときに、データがデータベースから物理的に削除されます。

Bulk API では、レコードをごみ箱に入れず、ただちに削除できる物理削除オプションがサポートされています。Bulk API の物理削除機能を使用すると容量がすぐに解放され、関係ないものによるパフォーマンスへの影響が回避されるため、大量データを削除する場合はこの機能を使用することをお勧めします。物理削除オプションはデフォルトで無効になっているので、システム管理者に有効にしてもらう必要があります。

データのチャンク

Bulk API を使用してデータを抽出する場合、クエリはデフォルトで 10 万件のレコードのチャンクに分割されます。chunkSize ヘッダー項目を使用すると、これよりも小さいチャンクや、最大 25 万件の大きなチャンクに設定できます。チャンクのサイズが大きければ使用する Bulk API のバッチ数が少なくなりますが、パフォーマンスが低下する可能性があります。場合によってはいろいろ試し、最適なチャンクサイズを判断する必要があります。

レコード数が数億件に上る場合など極端に多いときは、項目値の条件検索でチャンクを定義することが実用的でないことがあります。返される行数が、Salesforce のクエリオプティマイザーの選択度しきい値を上回る可能性があります。その結果、テーブルの完全スキャンが行われてパフォーマンスが低下したり、場合によっては失敗したりすることがあります。そうした場合には、異なる戦略が必要です。

PK Chunking の使用

属性による条件検索によってデータを適当なサイズのチャンクに分割できない場合は、どうしたらよいでしょうか? PK Chunking を使用して、極端に大きなデータセットの抽出を処理します。PK は、オブジェクトのレコード ID である主キーを表し、常にインデックスが付いています。PK Chunking では、非常に大きなテーブルに対する一括クエリを、照会されるレコードの ID に基づいてチャンクに分割します。

レコード数が 1,000 万件超のテーブルを照会する場合や、一括クエリが絶えずタイムアウトになる場合は PK Chunking を有効にします。PK Chunking は Salesforce Bulk API でサポートされている機能のため、クエリを管理しやすいチャンクに分割する作業をすべて行います。Bulk API ジョブに 2 ～ 3 のパラメーターを入力すれば、プラットフォームが自動的にクエリを個々のチャンクに分割し、チャンクごとにクエリを実行して、データを返します。

PK Chunking は大半の標準オブジェクトで使用でき、Account、Campaign、CampaignMember、Case、Contact、Lead、LoginHistory、Opportunity、Task、User の各オブジェクトとすべてのカスタムオブジェクトでサポートされています。この機能を有効にするには、Bulk API クエリのジョブ要求に Sforce-Enable-PKChunking ヘッダーを指定します。

チャンクサイズは、ヘッダーにそのサイズを指定するだけで選択できます。たとえば、Sforce-Enable-PKChunking: chunkSize=50000 というヘッダーは、チャンクサイズが 50000 件のレコードである PK Chunking を有効にします。各チャンクは、個々のバッチとして処理され、1 日あたりのバッチ制限に含まれます。その結果は個々にダウンロードする必要があります。Bulk API クエリに WHERE 句を含めれば、PK Chunking を使用中に絞り込みを実行できます。この方法を使用すると、チャンクに対して返されるレコード数が chunkSize で指定した数を下回ることがあります。

照会するレコード数が 1,000 万件を大幅に下回る場合に PK Chunking を利用するときは、chunkSize を照会するレコード数よりも小さい数に設定します。たとえば、Sforce-Enable-PKChunking: chunkSize=1000 とします。クエリが複数のバッチに分割され、PK Chunking の動作を確認できます。

クエリが正常にチャンクに分割されると、元のバッチの状況が NOT_PROCESSED になります。チャンク分割に失敗した場合は、元のバッチの状況が FAILED になりますが、チャンク分割の試行時に正常にキューに入れられたバッチは通常どおり処理されます。元のバッチの状況が NOT_PROCESSED に変更された場合は、後続のバッチを監視します。後続の各バッチの完了後に、そのバッチの結果を取得できます。その後ジョブを安全に終了します。

切り捨て

Sandbox 組織のカスタムオブジェクトのレコードをただちに削除する場合は、カスタムオブジェクトの切り捨てを試行できます。カスタムオブジェクトの切り捨ては、カスタムオブジェクトからすべてのレコードを完全に削除する迅速な方法であり、オブジェクトとそのメタデータは将来の使用のためにそのまま保持されます。

カスタムオブジェクトの切り捨てを行うと、現在そのカスタムオブジェクトのごみ箱に入れられているレコードや、カスタムオブジェクトの履歴、削除された各レコードに関連する行動、ToDo、メモ、添付ファイルがすべて消去されます。

カスタムオブジェクトを切り捨てると、切り捨てられたオブジェクトおよびそのレコードに回復不能な変更がいくつか行われます。これを元の状態に戻すことはできません。

切り捨てが役立つのは、たとえば、カスタムオブジェクトを作成してテストレコードを取り込んだ場合などです。テストデータを使用した作業が終了したときに、オブジェクトを切り捨ててテストレコードを消去できますが、オブジェクトを維持して本番環境で使用できます。この方法は、レコードを一括削除し、必要に応じてオブジェクトを再作成するよりはるかに迅速です。

以下に、簡単な設定手順を示します。

[Setup (設定)] で、[Quick Find (クイック検索)] ボックスに User Interface (ユーザーインターフェース) と入力し、[User Interface (ユーザーインターフェース)] を選択します (メモ: リストの末尾にあります)。
[Setup (設定)] セクション ([Name Settings (名前の設定)] と [Advanced (詳細)] の間) で、[Enable Custom Object Truncate (カスタムオブジェクトの切り捨てを有効化)] チェックボックスをオンにします。
[Save (保存)] をクリックします。

カスタムオブジェクトを切り捨てると、そのレコードのすべてが完全に削除されます。これらのレコードをごみ箱から復元することはできません。15 日間は、切り捨てられたオブジェクトのコピーが [削除済みオブジェクト] リストに表示されます。この間、オブジェクトとそのレコードは引き続き組織の制限に含まれます。15 日を過ぎると、コピーされたオブジェクトとそのレコードは完全に削除されます。

標準オブジェクトやカスタムオブジェクトのうち、参照項目を使用して別のオブジェクトに参照されているもの、主従関係の主側にあるもの、レポート作成スナップショットで参照されているもの、カスタムインデックスまたは外部 ID が設定されているもの、スキニーテーブルが有効になっているものは切り捨てることができません。また、組織のカスタムオブジェクトの最大許容数に達している場合も、カスタムオブジェクトを切り捨てることができません。

切り捨てのような手法を PK Chunking や Bulk API の物理削除と併用すれば、大量データによる組織の混乱を阻止できます。こうした方法を定期的あるいは必要に応じて活用することが、堅牢なパフォーマンスを持続させるのに賢明なやり方です。

ヘルプをお探しですか?

もっと探す