JSON検索索引の一部としての永続的データ・ガイド情報

24.2 JSON検索索引の一部としての永続的データ・ガイド情報

JSONデータ・ガイド情報は、JSON検索索引インフラストラクチャの一部として永続的な保存が可能です。この情報は、新しいJSONコンテンツが追加されると自動的に更新されます。このオプションの動作は、JSON検索索引の作成時に指定します。

CREATE SEARCH INDEXをキーワードFOR JSONと一緒に使用して、検索索引、データ・ガイド、またはこの両方を同時に作成できます。デフォルトの動作では、データ・ガイドのサポートなしで検索索引が作成されます。

JSON検索索引の一部としての永続的データ・ガイド情報を作成する場合は、CREATE SEARCH INDEXのPARAMETERS句でDATAGUIDEをONとして指定します。データ・ガイドのサポートは、SEARCH_ON NONEの追加指定によって、検索のサポートを有効にすることなく有効化できます。例24-1に、これを示します。

ALTER INDEX ... REBUILDを使用して、既存のJSON検索索引のデータ・ガイドのサポートを有効または無効にできます。例24-2に、これを示します。この例では、例30-24の検索索引に対するデータ・ガイドのサポートを有効にします。

ノート:

データ・ガイド対応JSON検索索引を作成する、または既存のJSON検索索引をデータ・ガイド対応にするには、データベース権限CTXAPPおよびOracle Databaseリリース12c (12.2.0.1)以降が必要です。

ノート:

データ・ガイドに対応したJSON検索索引は、JSONデータが含まれていることがわかっている列(JSONデータ型の列、または列にis jsonチェック制約がある)にのみ作成できます。後者の場合、索引内のデータ・ガイド情報を更新するには、このチェック制約を有効にする必要があります。

このチェック制約が何かの理由で無効になった場合、次のようにして索引内のデータ・ガイド情報を再構築してチェック制約を再有効化し、自動データ・ガイド・サポート更新を再開する必要があります。

ALTER INDEX index_name REBUILD ('dataguide off');
ALTER INDEX index_name REBUILD ('dataguide on');
ALTER TABLE table_name ENABLE CONSTRAINT is_json_check_constraint_name;

具体的には、SQL*Loader (sqlldr)を使用するとis jsonチェック制約は無効になります。

検索索引インフラストラクチャの一部である永続的データ・ガイド情報を有効にすると、それは常にライブになります。つまり、そのコンテンツは索引が同期されるたびに自動更新されるということです。索引付けされたデータの変更は、検索索引に反映されます。索引が同期された後にのみ、データ・ガイド情報が含まれます。

さらに、検索索引内のデータ・ガイド情報の更新では、常に情報が追加されます。情報が削除されることはありません。これは、索引が文書セット内のデータを正確に反映しないことがよくあるもう1つの理由です。適用先の文書内での削除は、データ・ガイド情報には反映されません。そのような情報が現在のデータを正確に反映する必要がある場合は、JSON検索索引を削除し、新しく作成します。

検索索引内の永続的データ・ガイド情報には、文書セット内での各JSONフィールドの使用頻度などの統計も含めることができます。統計は、文書セットに関する統計を明示的に収集した場合にのみ存在します(JSON検索索引に関して収集するなど)。自動的には更新されません。統計が最新のものであるようにするには、統計を新たに収集します。例24-3は、JSON検索索引po_search_idxによって索引付けされたJSONデータに関する統計を収集します。この索引は、例30-24で作成されます。

ノート:

シャーディング環境でローカル・データ・ガイド対応JSON検索索引が作成されると、個別の各シャードに、そのシャード内に保存されているJSON文書のデータ・ガイド情報が含まれます。この理由から、シャード・カタログ・データベースに対してデータ・ガイド関連操作を起動すると、その操作に効力はありません。

パーティション表のデータ・ガイド対応検索索引に関する考慮事項

パーティション表のローカルなデータ・ガイド対応JSON検索索引のデータ・ガイド情報は、パーティション化されません。すべてのパーティションで共有されます。

索引内のデータ・ガイド情報は加算的なものであるため、パーティションの削除、マージ、分割、切捨ては索引には影響しません。

パーティション表をパーティション化されていない表と交換すると、パーティション表の索引のデータ・ガイド情報が更新されます。ただし、パーティション化されていない表のデータ・ガイド対応索引は再構築する必要があります。

ハッシュ表データをシリアライズする場合は永続的なデータ・ガイド情報を使用しない

Javaハッシュ表または連想配列(JavaScriptにあるものなど)をJSONオブジェクトとしてシリアライズする場合、永続的なデータ・ガイド情報の使用を避けます。

GSONやJacksonなどの一般的なライブラリで提供されるデフォルトのハッシュ表シリアライズでは、ハッシュ表のキー・エントリから取得されたオブジェクト・フィールド名と、対応するJavaハッシュ表の値から取得されたフィールド値を持つテキストのJSONドキュメントが生成されます。単一のJavaハッシュ表エントリをシリアライズすると、新しい一意のJSONフィールドと値が生成されます。

永続的なデータ・ガイド情報は、データの形状を反映し、新しいJSON文書が挿入されると自動的に更新されます。各ハッシュ表のキー値のペアによって、JSON検索索引の個別のエントリが作成されます。そのため、このようなシリアライズによって、索引に保持される情報のサイズが大幅に増える可能性があります。サイズが大きいことに加え、多くの索引が更新されるためにパフォーマンスに悪影響がおよび、DMLが遅くなります。

ハッシュ表をシリアライズする、またはかわりに連想配列をオブジェクトのJSON配列としてシリアライズする場合、それぞれにハッシュ表キー・エントリから導出されたフィールドが含まれ、そのような問題は起きません。

ハッシュ表またはJSONオブジェクトとしての連想配列のデフォルトのシリアライズは、開発者によって割り当てられたフィールド名を持つオブジェクトと区別できません。JSONデータ・ガイドは、メタデータのようなフィールド名のどれが開発者が割り当てたものであり、データのようなフィールド名のどれがハッシュ表または連想配列から導出されたものかを識別できません。すべてのフィールド名は、開発者が指定したのと同様に、基本的にメタデータとして扱われます。

たとえば:

animalNameをハッシュ・キーとして持ち、一連の動物プロパティを値として持つハッシュ表を使用してアプリケーション・オブジェクトを構築する場合、デフォルトのシリアライズは、各ハッシュ表エントリについて個別のフィールド("cat"、"mouse"、...)を持ち、対応する動物プロパティを持つオブジェクトになるフィールド値を持つ単一のJSONオブジェクトになります。これは、通常ハッシュ・キーから導出されたフィールド("cat"、"mouse"、...)数が多数になるため、データ・ガイドのサイズとパフォーマンスの面で問題になる可能性があります。
かわりに、animal構造体のアプリケーション配列を構築し、それぞれに1つのフィールドanimalName (値"cat"または"mouse"...を持つ)を持たせた場合、シリアライズはオブジェクトのJSON配列となり、それぞれに同じフィールドanimalNameを持ちます。対応するデータ・ガイドにサイズやパフォーマンスの問題はありません。

例24-1 JSONデータ・ガイドの検索用でない永続的サポートの有効化

CREATE SEARCH INDEX po_dg_only_idx
  ON j_purchaseorder (data) FOR JSON
    PARAMETERS ('DATAGUIDE ON SEARCH_ON NONE');

例24-2 既存のJSON検索索引のJSONデータ・ガイド・サポートの有効化

ALTER INDEX po_search_idx REBUILD PARAMETERS ('DATAGUIDE ON');

例24-3 JSON検索索引を使用したJSONデータに関する統計情報の収集

EXEC DBMS_STATS.gather_index_stats(docuser, po_search_idx, NULL, 100);