次の方法で共有

BLOB およびファイルにインデックスを作成して複数の検索ドキュメントを生成する

適用対象: BLOB インデクサー、ファイル インデクサー

既定では、インデクサーによって、BLOB またはファイルのコンテンツが単一の検索ドキュメントとして扱われます。 検索インデックスで BLOB をより詳細に表現する場合は、1 つの BLOB またはファイルから複数の検索ドキュメントを作成するように parsingMode 値を設定できます。 多くの検索ドキュメントを生成する parsingMode 値には、delimitedText (CSV の場合)、jsonArray または jsonLines (JSON の場合) が含まれます。

これらの解析モードのいずれかを使用する場合、出現する新しい検索ドキュメントには一意のドキュメント キーが必要であり、その値の取得元を決定する際に問題が発生します。 親 BLOB には metadata_storage_path property の形式で一意の値が少なくとも 1 つ含まれていますが、その値が複数の検索ドキュメントに提供される場合、そのキーはインデックス内で一意ではなくなります。

この問題に対処するために、BLOB インデクサーでは、1 つの BLOB 親から作成された各子検索ドキュメントを一意に識別する AzureSearch_DocumentKey を生成します。 この記事では、この動作のしくみについて説明します。

一対多のドキュメント キー

ドキュメント キーは、インデックス内の各ドキュメントを一意に識別します。 解析モードが指定されず、検索ドキュメント キーのインデクサー定義に明示的なフィールド マッピングがない場合、BLOB インデクサーでは metadata_storage_path property をドキュメント キーとして自動的にマップします。 この既定のマッピングにより、各 BLOB が個別の検索ドキュメントとして表示されます。 また、このフィールド マッピングを手動で作成する必要がなくなります。 通常、同じ名前と型を持つフィールドのみが自動的にマップされます。

一対多の検索ドキュメント シナリオでは、metadata_storage_path property に基づく暗黙的なドキュメント キーを使用することはできません。 回避策として、Azure AI 検索では、BLOB から抽出された個々のエンティティのドキュメント キーを生成できます。 AzureSearch_DocumentKeyという名前のキーが生成され、各検索ドキュメントに追加されます。 インデクサーでは、各 BLOB から作成された "多数のドキュメント" を追跡し、ソース データが時間の経過と同時に変化したときに検索インデックスの更新を対象にすることができます。

既定では、キー インデックス フィールドに対して明示的なフィールド マッピングが指定されていない場合、AzureSearch_DocumentKey フィールド マッピング関数を使用して、base64Encode がそれにマップされます。

例

次のフィールドのインデックス定義があるとします。

  • id
  • temperature
  • pressure
  • timestamp

BLOB コンテナーには次の構造の BLOB があります。

Blob1.json

{ "temperature": 100, "pressure": 100, "timestamp": "2024-02-13T00:00:00Z" }
{ "temperature" : 33, "pressure" : 30, "timestamp": "2024-02-14T00:00:00Z" }

Blob2.json

{ "temperature": 1, "pressure": 1, "timestamp": "2023-01-12T00:00:00Z" }
{ "temperature" : 120, "pressure" : 3, "timestamp": "2022-05-11T00:00:00Z" }

インデクサーを作成し、キー フィールドに対して明示的なフィールド マッピングを指定せずに、parsingMode を jsonLines に設定すると、以下のマッピングが暗黙的に適用されます。

{
    "sourceFieldName" : "AzureSearch_DocumentKey",
    "targetFieldName": "id",
    "mappingFunction": { "name" : "base64Encode" }
}

このセットアップでは、次の図のように明確なドキュメント キーが生成されます (簡潔にするために、base64 でエンコードされた ID が短縮されています)。

身分証明書 温度 圧力 タイムスタンプ
aHR0 ...YjEuanNvbjsx 100 100 2024年2月13日 午前0時0分0秒
aHR0 ...YjEuanNvbjsy 33 30 2024-02-14T00:00:00Z
aHR0 ...YjIuanNvbjsx 1 1 2023-01-12T00:00:00Z
aHR0 ...YjIuanNvbjsy 120 3 2022-05-11T00:00:00Z

インデックス キー フィールドのカスタム フィールド マッピング

前述の例と同じインデックス定義があり、BLOB コンテナーに次の構造の BLOB があるとします。

Blob1.json

recordid, temperature, pressure, timestamp
1, 100, 100,"2024-02-13T00:00:00Z" 
2, 33, 30,"2024-02-14T00:00:00Z"

Blob2.json

recordid, temperature, pressure, timestamp
1, 1, 1,"20123-01-12T00:00:00Z" 
2, 120, 3,"2022-05-11T00:00:00Z"

delimitedTextparsingMode でインデクサーを作成するときに、以下のようにキー フィールドにフィールド マッピング関数を設定するのは自然だと思われるかもしれません。

{
    "sourceFieldName" : "recordid",
    "targetFieldName": "id"
}

しかし、このマッピングでは、インデックスに 4 つのドキュメントは表示されません。recordid フィールドは BLOB 全体で一意ではないためです。 そのため、"1 対多" の解析モードでは、AzureSearch_DocumentKey プロパティからキー インデックス フィールドに適用される暗黙的なフィールド マッピングを利用することをお勧めします。

明示的なフィールド マッピングを設定する場合は、BLOB 全体の個々のエンティティの sourceField がそれぞれ固有であることを確認してください。

注

抽出されたエンティティごとの一意性を確保するために AzureSearch_DocumentKey で使用される手法は変更される可能性があるため、アプリケーションのニーズに応じて、その値に依存しないようにしてください。

データ内のインデックス キー フィールドを指定する

インデックス定義が前の例と同じで、明示的なフィールド マッピングが指定されずに parsingMode が jsonLines に設定されているとし (そのため、マッピングは最初の例のようになります)、BLOB コンテナーに、次の構造の BLOB があるとします。

Blob1.json

id, temperature, pressure, timestamp
1, 100, 100,"2024-02-13T00:00:00Z" 
2, 33, 30,"2024-02-14T00:00:00Z"

Blob2.json

id, temperature, pressure, timestamp
1, 1, 1,"2023-01-12T00:00:00Z" 
2, 120, 3,"2022-05-11T00:00:00Z"

各ドキュメントには、インデックスのkey フィールドとして定義されているid フィールドが含まれています。 この状況では、一意の AzureSearch_DocumentKeyfor the document, but it isn't used as the "key." Instead, the value of theidfield is mapped to thekey' フィールドが生成されます。

以前の例と同様、このマッピングでは、インデックスに 4 つのドキュメントは表示されません。id フィールドは BLOB 全体で一意ではないためです。 このような状況が発生すると、 id を指定する JSON エントリによって、新しいドキュメントをアップロードする代わりに、既存のドキュメントとのマージが発生します。 その後、インデックスには、指定した idを持つエントリの最新の状態が反映されます。

制限事項

この記事で説明するように、インデックス内のドキュメント エントリがファイル内の行から作成された場合、その行をファイルから削除しても、対応するエントリはインデックスから自動的に削除されません。 ドキュメント エントリを削除するには、 REST API の削除操作を使用してインデックスに削除要求を手動で送信する必要があります。

次のステップ

BLOB インデックス作成の基本的な構造とワークフローにまだ慣れていない場合は、最初に Azure AI Search を使用した Azure Blob Storage のインデックス作成 を確認する必要があります。 さまざまな種類の BLOB コンテンツ タイプ の解析モードに関する詳細については、次の記事を参照してください。

CSV BLOB のインデックス作成CSV BLOB のインデックス作成