为用于生成多个搜索文档的 Blob 和文件编制索引

适用对象：Blob 索引器、文件索引器

默认情况下，索引器将一个 blob 或文件的内容视为单个搜索文档。 如果要在搜索索引中进行更精细的表示，则可以将 parsingMode 值设置为从一个 blob 或文件创建多个搜索文档。 导致许多搜索文档的 parsingMode 值包括 （对于 delimitedText）和 或 jsonArray（对于 jsonLines）。

当你使用这些分析模式中的任何一种时，出现的新搜索文档必须具有唯一的文档键，并在确定值的来源时出现问题。 父 blob 至少具有一个采用 metadata_storage_path property 形式的唯一值，但如果它将该值分配给多个搜索文档，则该键在索引中不再唯一。

若要解决此问题，blob 索引器将生成一个 AzureSearch_DocumentKey，用于唯一标识从单个 blob 父项创建的每个子搜索文档。 本文介绍此功能的工作原理。

文档键唯一标识索引中的每个文档。 如果未指定分析模式，并且搜索文档键的索引器定义中没有显式字段映射，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）。

假设索引定义与前面的示例相同，并且 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 中不是唯一的。 因此，我们建议对“一对多”分析模式，应用从 AzureSearch_DocumentKey 属性到键索引字段的隐式字段映射。

如果确实想要设置显式字段映射，请确保 sourceField 对于所有 Blob 中的每个实体都是不同的。

在假设索引定义与上一示例相同，并且 parsingMode 设置为 ，但未指定任何显式字段映射，因此映射类似于第一个示例中的映射的情况下，假设 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 the键字段。

与上一示例类似，此映射不会生成索引中显示的 4 个文档，因为 id 字段在各 Blob 中不是唯一的。 在这种情况下，任何指定 id 的 JSON 条目都会与现有文档合并，而不是上传一个新文档。 然后，索引将反映具有指定id的条目的最新状态。

如果尚未熟悉 blob 索引编制的基本结构和工作流，则应先使用 Azure AI 搜索为 Azure Blob 存储编制索引。 请查看以下文章，详细了解不同 blob 内容类型的分析模式。