本文演示如何创建搜索服务，使用户能够基于文档内容以及与文件关联的任何元数据搜索文档。
可以通过在 Azure AI 搜索中使用多个索引器来实现此服务。
本文使用示例工作负载来演示如何创建基于 Azure Blob 存储中的文件的单个搜索索引。 文件元数据存储在 Azure 表存储中。
体系结构
下载此体系结构的 PowerPoint 文件。
数据流
- 文件存储在 Blob 存储中，可能与有限数量的元数据（例如文档的作者）一起存储。
- 其他元数据存储在表存储中，表存储可以为每个文档存储的信息量大大增加。
- 索引器读取每个文件的内容以及任何 blob 元数据，并将数据存储在搜索索引中。
- 另一个索引器从表中读取其他元数据，并将其存储在同一搜索索引中。
- 搜索查询将发送到搜索服务。 查询基于文档内容和文档元数据返回匹配的文档。
组件
- Blob 存储为文件数据（包括 PDF、HTML 和 CSV 等格式的数据以及 Microsoft 365 文件）提供经济高效的云存储。
- 表存储为非关系结构化数据提供存储。 在此方案中，它用于存储每个文档的元数据。
- Azure AI 搜索是一种完全托管的搜索服务，提供用于构建丰富搜索体验的基础结构、API 和工具。
备选方法
此方案使用 Azure AI 搜索中的索引器自动发现受支持的数据源（如 blob 和表存储）中的新内容，然后将其添加到搜索索引。 或者，可以使用 Azure AI 搜索提供的 API 将数据推送到搜索索引。 但是，如果这样做，则需要编写代码以将数据推送到搜索索引中，还需要从要搜索的二进制文档中分析和提取文本。 Blob 存储索引器支持多种文档格式，这大大简化了文本提取和索引编制过程。
此外，如果使用索引器，可以选择将数据作为索引管道的一部分进行扩充。 例如，可以使用 Azure AI 服务对文档中的图像执行光学字符识别 (OCR) 或视觉分析、检测文档语言或翻译文档。 还可以定义自己的自定义技能 ，以与业务方案相关的方式扩充数据。
此体系结构使用 Blob 和表存储，因为它们经济高效。 此设计还支持将文档和元数据组合存储在单个存储帐户中。 文档本身支持的替代数据源包括 Azure Data Lake Storage 和 Azure 文件存储。 文档元数据可以存储在保存结构化数据的任何其他受支持的数据源中，例如 Azure SQL Database 和 Azure Cosmos DB。
方案详细信息
搜索文件内容
此解决方案使用户能够基于文件内容和为每个文档单独存储的其他元数据来搜索文档。 除了搜索文档的文本内容外，用户还可能想要搜索文档的作者、文档类型（如纸张或报表），或其业务影响（高、中或低）。
Azure AI 搜索是一种完全托管的搜索服务，可以创建包含要允许用户搜索的信息的搜索索引。
由于在此方案中搜索的文件是二进制文档，因此可以将它们存储在 Blob 存储中。 如果这样做，可以使用 Azure AI 搜索中的内置 Blob 存储索引器自动从文件中提取文本并将其内容添加到搜索索引。
搜索文件元数据
如果要包含有关文件的其他信息，可以直接将元数据 与 blob 关联，而无需使用单独的存储。 内置的 Blob 存储搜索索引器甚至可以读取此元数据并将其置于搜索索引中。 这使用户能够搜索元数据以及文件内容。 但是，每个 blob 的元数据量限制为 8 KB，因此，可以置于每个 blob 中的信息量相当小。 可以选择仅将最关键的信息直接存储在 blob 中。 在此方案中，只有文档的作者存储在 blob 中。
若要克服此存储限制，可以将其他元数据置于具有受支持的索引器（如表存储）的另一个数据源中。 可以将文档类型、业务影响和其他元数据值添加为表中的单独列。 如果将内置的表存储索引器配置为与 Blob 索引器相同的搜索索引，则会针对搜索索引中的每个文档组合 Blob 和表存储元数据。
对单个搜索索引使用多个数据源
为了确保两个索引器都指向搜索索引中的同一文档，搜索索引中的文档键设置为文件的唯一标识符。 然后，此唯一标识符用于引用两个数据源中的文件。 默认情况下，Blob 索引器使用 metadata_storage_path 作为文档键。 属性 metadata_storage_path 将文件的完整 URL 存储在 Blob 存储中，例如 https://contoso.blob.core.windows.net/files/paper/Resilience in Azure.pdf。 索引器对值执行 Base64 编码，以确保文档键中没有无效字符。 结果将得到一个唯一的文档键，如 aHR0cHM6...mUucGRm0。
如果将 metadata_storage_path 添加为表存储中的列，你将确切知道其他列中的元数据属于哪个 blob，因此可以在表中使用任意 PartitionKey 和 RowKey 值。 例如，可以使用 blob 容器名称作为 PartitionKey，使用 blob Base64 编码的完整 URL 作为 RowKey，确保这些密钥中也没有无效字符。
然后，可以使用表索引器中的字段映射将 metadata_storage_path 列（或表存储中的另一列）映射到搜索索引中的 metadata_storage_path 文档键字段。 如果在字段映射上应用 base64 编码函数，则最终会得到相同文档键（前面示例中的 aHR0cHM6...mUucGRm0），并且表存储中的元数据将添加到从 blob 存储中提取的同一文档中。
注意
表索引器文档指出，不得定义到表中备用唯一字符串字段的字段映射。 这是因为索引器默认连接 PartitionKey 和 RowKey 作为文档键。 由于你已经依赖 blob 索引器配置的文档密钥（blob Base64 编码的完整 URL），因此请创建字段映射，以确保两个索引器引用搜索索引中的同一文档是适合的，并且受此方案支持。
或者，可以将 RowKey（设置 blob Base64 编码的完整 URL）直接映射到 metadata_storage_path 文档键，而无需单独存储该 URL，并将 Base64 编码为字段映射的一部分。 但是，将未编码的 URL 保留在单独的列中可以明确它所引用的 blob，并允许你选择任何分区键和行键，而不会影响搜索索引器。
可能的用例
此方案适用于需要能够根据文档内容和其他元数据搜索文档的应用程序。
注意事项
这些注意事项实施 Azure 架构良好的框架的支柱原则，即一套可用于改进工作负载质量的指导原则。 有关详细信息，请参阅 Microsoft Azure 架构良好的框架。
可靠性
可靠性可确保应用程序符合你对客户的承诺。 有关详细信息，请参阅可靠性支柱概述。
如果至少有两个副本，则 Azure AI 搜索可为读取（查询）操作提供高服务级别协议 (SLA)。 如果有至少三个副本，则它将为更新（更新搜索索引）提供高 SLA。 因此，如果希望用户能够可靠地执行搜索，则应预配至少两个副本；如果还需要将索引的实际更改视为高可用性操作，则应预配至少三个副本。
Azure 存储会始终存储数据的多个副本，以帮助保护它免受计划内和计划外事件的影响。 Azure 存储提供了用于跨区域复制数据的其他冗余选项。 这些安全措施适用于 blob 和表存储中的数据。
安全性
安全性针对蓄意攻击及滥用宝贵数据和系统提供保障措施。 有关详细信息，请参阅安全性支柱概述。
Azure AI 搜索提供可靠的安全控制，可帮助你实现网络安全、身份验证和授权、数据驻留和保护，以及有助于维护安全性、隐私性和合规性的管理控制。
请尽可能使用 Microsoft Entra 身份验证来提供对搜索服务本身的访问权限，并通过使用托管标识将搜索服务连接到其他 Azure 资源（例如此方案中的 blob 和表存储）。
可以使用专用终结点从搜索服务连接到存储帐户。 使用专用终结点时，索引器可以使用专用连接，而无需公开访问 blob 和表存储。
成本优化
成本优化就是减少不必要的费用和提高运营效率。 有关详细信息，请参阅成本优化支柱概述。
有关运行此方案的成本的信息，请参阅 Azure 定价计算器中的此预配置估算。 此处所述的所有服务都在此估算中配置。 该估算适用于 Blob 存储中总文档大小为 20 GB 和表存储中元数据为 1 GB 的工作负载。 使用两个搜索单位来满足用于读取目的的 SLA，如本文的可靠性部分所述。 若要了解自己的特定用例的定价变化情况，请按预期用法更改相应的变量。
如果查看估算，可以看到 Blob 和表存储的成本相对较低。 大部分成本由 Azure AI 搜索产生，因为它执行实际的索引编制和计算工作以运行搜索查询。
部署此方案
若要部署此示例工作负载，请参阅为 Azure AI 搜索中的文件内容和元数据编制索引。 使用此示例可以：
- 创建所需的 Azure 服务。
- 将一些示例文档上传到 Blob 存储。
- 在 blob 上填充作者元数据值。
- 将文档类型和业务影响元数据值存储在表存储中。
- 创建用于维护搜索索引的索引器。
作者
本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。
主要作者：
- Jelle Druyts | 首席客户体验工程师
其他参与者：
- Mick Alberts | 技术文档撰写人
若要查看非公开的 LinkedIn 个人资料，请登录到 LinkedIn。