为用于生成多个搜索文档的 Blob 和文件编制索引
默认情况下,索引器将一个 blob 或文件的内容视为单个搜索文档。 如果要在搜索索引中进行更精细的表示,则可以将 parsingMode 值设置为从一个 blob 或文件创建多个搜索文档。 导致许多搜索文档的 parsingMode 值包括 delimitedText
(对于 CSV)和 jsonArray
或 jsonLines
(对于 JSON)。
当你使用这些分析模式中的任何一种时,出现的新搜索文档必须具有唯一的文档键,并在确定值的来源时出现问题。 父 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 创建的“许多文档”,并在源数据随时间变化时面向搜索索引更新。
默认情况下,如果未指定键索引字段的显式字段映射,系统会使用 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 | 温度 | 压力 | 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"
}
但是,此映射不会生成索引中显示的 4 个文档,因为 recordid
字段在各 Blob 中不是独一无二的。 因此,我们建议对“一对多”分析模式,应用从 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_DocumentKey
,它也不会用作文档的“键”, 而是会将 id
字段的值映射到 key
字段
与上一示例类似,此映射不会生成索引中显示的 4 个文档,因为 id
字段在各 Blob 中不是独一无二的。 在这种情况下,任何指定 id
的 json 条目都会导致合并现有文档而不是上传新文档,索引的状态会反映具有指定 id
的最新读取条目。
后续步骤
如果尚未熟悉 blob 索引编制的基本结构和工作流,则应先使用 Azure AI 搜索为 Azure Blob 存储编制索引。 请查看以下文章,详细了解不同 blob 内容类型的分析模式。