次の方法で共有

複数の検索ドキュメントを生成するための BLOB とファイルのインデックス作成

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

既定では、インデクサーは BLOB またはファイルの内容を 1 つの検索ドキュメントとして扱います。 検索インデックスをより詳細に表現する場合は、 parsingMode 値を 設定して、1 つの BLOB またはファイルから複数の検索ドキュメントを作成できます。 多くの検索ドキュメントに含まれる 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 Search では、BLOB から抽出された個々のエンティティのドキュメント キーを生成できます。 AzureSearch_DocumentKeyという名前のキーが生成され、各検索ドキュメントに追加されます。 インデクサーは、各 BLOB から作成された "多数のドキュメント" を追跡し、ソース データが時間の経過と同時に変化したときに検索インデックスの更新を対象にすることができます。

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

Example

次のフィールドを持つインデックス定義を想定します。

  • 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 timestamp
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"
}

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

明示的なフィールド マッピングを設定する場合は、 sourceField が すべての BLOB の個々のエンティティごとに異なっていることを確認します。

注

抽出されたエンティティごとに一意性を確保する 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_DocumentKeyfor the document, but it isn't used as the "key." Instead, the value of theidfield is mapped to thekey' フィールドが生成されます。

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

制限事項

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

次のステップ

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

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

  • Last updated on