大容量オブジェクトの設定

大容量オブジェクトのデータ保存オプションを使用するオブジェクトには、カスタムフィールドでレコードのフィルタリングができるように、標準の Vault オブジェクトのほかに追加の設定手順が必要です。大容量オブジェクトには利点と制限があるため、作成する前にこのデータ保存オプションの採用について慎重に検討する必要があります。

大容量オブジェクトの作成

大容量オブジェクトを作成するには、標準の Vault オブジェクトの作成手順に従い、データ保存フィールドで大容量を選択します。

大容量オブジェクトの管理

大容量オブジェクトのレコードは 10,000 件未満ですが、標準 Vault オブジェクトと同じようにオブジェクトを変更できます。しかしながら、10,000 以上のレコードを持つ場合、設定パッケージまたは開発ツール経由を除き、Vault では次の方法で大容量オブジェクトを変更することができません。

• フィールドの追加または削除
• テキスト、ロングテキスト、またはリッチテキストなど、文字数がさまざまなフィールドの長さの変更
• インデックスの作成
• ライフサイクルの有効化
• オブジェクトタイプの有効化または無効化

設定パッケージまたは開発ツール経由で変更を展開する際、大容量オブジェクトは、ステータスフィールドの隣にある管理者 > オブジェクト > [オブジェクト] > 詳細に予定されている変更ステータスを表示します。オブジェクトに予定されている変更がある場合、フィールド、リストレイアウトまたはインデックスは編集できませんが、ユーザは引き続きオブジェクトレコードとやりとりを行うことができます。予定されている変更は以下のステータスがを持つことができます: 展開中、キャンセル中、またはエラー。API ユーザが Vault REST API を使用して進行中の変更のキャンセルを選択した場合のみ、キャンセル中ステータスが表示されます。設定パッケージまたは開発者ツール経由で大容量オブジェクトへ変更を展開する方法をご確認ください。

大容量オブジェクトのフィルタリング

Vault は、検索とフィルタリングが自動で行えるように標準のデータ保存オプションを使用してオブジェクトにインデックスをつけますが、大容量オブジェクトのメタデータは異なり、自動インデックスと、最大 5 つのカスタムインデックスの定義を組み合わせてインデックスをつけます。大容量オブジェクトは標準の Vault 詳細検索を使用しないため、ユーザが必要とするフィルタリングのタイプを考慮することができます。そのうえで、ニーズに合わせてカスタムインデックスを定義できます。

大容量オブジェクトの自動インデックス

Vault は以下のフィールドに自動的にインデックスをつけます: ID、名前、変更日、ステータス、オブジェクトタイプ (該当する場合)、状態 (該当する場合)。Vault は、フィールドが固有になったら、または関係フィールドが追加されたらインデックスを自動作成します。Vault は、後でフィールドが固有でなくなった場合、または関係フィールドが削除された場合に、そのインデックスを削除します。

Vault は、インデックスの元になったフィールドに基づいて自動作成されたインデックスを命名します。例えば、値は一意である必要がありますのチェックボックスを選択した後に order という名前のカスタムフィールドを保存すると、Vault は order__sys というインデックスを作成します。

カスタムフィルタリングインデックスの作成

ユーザが、カスタムの非固有フィールドで大容量オブジェクトレコードをフィルタリングできるようにするインデックスを作成するには:

1. 管理者 > コンテンツ設定 > オブジェクト > [オブジェクト] > インデックスに進みます。
2. 作成をクリックします。
3. ラベルと名前を入力します。
4. フィールド (順番) セクションで、フィールド 1 のドロップダウンでフィールドを選択します。Vault はこのドロップダウンでインデックスが付けられるフィールドしか表示しません。Vault は、255 文字以上のテキスト、ロングテキスト、リッチテキストにはインデックスをつけることができません。
5. 任意の作業: ドロップダウン横の + アイコンをクリックしてその他のフィールドを追加します。フィールド順に関する情報および例は、フィールド順についてで詳細をご確認ください。

フィールド順について

Vault はオブジェクトに定義されたインデックスを使用して検索ページを高速化します。インデックスのエントリは、まずフィールド 1 と選択されたフィールドで並べ替えられ、次にフィールド 1 に相当する値のエントリがフィールド 2 で並べ替えられます。インデックスのフィールドの順序は、そのインデックスがフィルタを含む検索を最適化できるかどうかを判断する際に重要です。

例 1

ユーザが、日付フィールドで日付範囲にフィルタリングをして検索を実行したいと考えているとします。この場合、次の例のように日付で始めるインデックスのみが検索パフォーマンスを最適化できます。例: フィールド 1: 日付、またはフィールド 1: 日付、続いてフィールド 2: 影響を受ける ID。日付を含むものの日付で始まらないインデックス (例: フィールド 1: 影響を受ける ID、続いてフィールド 2: 日付) は、この検索の最適化には使用できません。

例 2

ユーザが、日付フィールドで日付範囲にフィルタリングをして検索を実行したいと考えており、ユーザ ID フィールドに具体的な値が入力されているとします。以下のインデックスを使用して検索を最適化することができます:

• 日付で始まるインデックス。例: フィールド 1: 日付、またはフィールド 1: 日付、続いてフィールド 2: 影響を受ける ID。
• ユーザ ID で始まるインデックス。例: フィールド 1: ユーザ ID、またはフィールド 1: ユーザ ID、続いてフィールド 2: 影響を受ける ID。
• 次の例のような日付とユーザ ID で始まるインデックス:
  • フィールド 1: 日付、続いてフィールド 2: ユーザ ID
  • フィールド 1: ユーザ ID、続いてフィールド 2: 日付
  • フィールド 1: 日付、続いてフィールド 2: ユーザ ID、続いてフィールド 3: 影響を受ける ID

この場合、インデックス 1 または 2 はある程度の最適化を提供することはできますが、インデックス 3 のほうが最適化の程度は高くなります。複数のインデックスを選択できる場合、Vault は最適化の程度が最大になることが予想されるインデックスを選択します。

以下の例のインデックスは、この検索を最適化するために使用できません: 日付またはユーザ ID を含むがいずれでも始まらないインデックス。例: フィールド 1: 影響を受ける ID、続いてフィールド 2: 日付、続いてフィールド 3: ユーザ ID。

例 3

ユーザが、ユーザ ID が特定の値ではないレコードの検索をしたいと考えているとします。一般に、インデックスは「等しくない」のような否定演算子を使用したクエリを最適化するために使用できません。これが通常の使用事例である場合、大容量オブジェクトのデータ保存オプションはオブジェクトに適切ではありません。

関連権限