次の方法で共有

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 から作成された "多数のドキュメント" を追跡し、ソース データが時間の経過と同時に変化したときに検索インデックスの更新を対象にすることができます。

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

例

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

  • 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 が短縮されています)。

ID 温度 pressure タイムスタンプ
aHR0 ...YjEuanNvbjsx 100 100 2024-02-13T00:00:00Z
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"

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

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

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

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

Note

抽出されたエンティティごとの一意性を確保するために 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"

各ドキュメントに id フィールドが含まれることに注意してください。このフィールドは、インデックスで key フィールドとして定義されます。 このような場合、ドキュメント固有の AzureSearch_DocumentKey が生成されても、これはドキュメントの "キー" として使用されません。 代わりに、id フィールドの値が key フィールドにマップされます

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

次のステップ

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

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