估计和管理搜索服务的容量

在 Azure AI 搜索中，容量基于可扩展到工作负载的副本和分区。 副本是搜索引擎的副本。 分区是存储单元。 对于这两种资源，每项新搜索服务开始时都各有一种，但你可以单独添加或删除副本和分区，以适应波动的工作负载。 添加容量会增加运行搜索服务的成本。

副本和分区的物理特征（如处理速度和磁盘 IO）因服务层而异。 在标准搜索服务中，副本和分区比基本服务的副本和分区更快、更大。

更改容量不会即时生效。 启用或停用分区最多可能需要一小时，尤其是对于具有大量数据的服务。

缩放搜索服务时，可从下列工具和方法中进行选择：

• Azure 门户
• Azure PowerShell
• Azure CLI
• 管理 REST API

概念：搜索单位、副本、分区

容量以搜索单元表示，它可以按分区和副本的组合进行分配。

查看分区和副本表，了解可能保持在 36 个单位限制下的组合。

何时添加容量

最初为服务分配了由一个分区和一个副本组成的最低级别的资源。 所选的层确定了分区大小和速度，每个层已根据一组适合不同方案的特征进行优化。 如果选择更高端的层，与使用 S1 时相比，所需的分区数可能更少。 需要通过自我引导式测试解答的一个问题是，对于性能而言，使用更大且更昂贵的分区，是否比在较低层上预配的服务中使用两个更廉价的分区更好。

单个服务必须具有足够的资源才能处理所有工作负荷（索引和查询）。 没有任何工作负荷在后台运行。 如果查询请求在性质上不频繁，则可以计划索引编制，但如果不这样做，服务也不会排定任务的优先级。 此外，在内部更新服务或节点时，一定程度的冗余也会销蚀查询性能。

确定是否添加容量的一些准则包括：

• 满足服务级别协议的高可用性标准
• HTTP 503 错误的频率正在增加
• 有很大的查询量

根据惯例，搜索应用程序所需的副本数往往多过分区数，尤其是在服务操作偏向于查询工作负荷的情况下。 每个副本都是索引副本，使服务能根据多个副本对请求进行负载均衡。 所有负载均衡和索引复制均由 Azure AI 搜索管理，随时可以更改为服务分配的副本数量。 最大可在一个标准搜索服务中分配 12 个副本，并在一个基本搜索服务中分配 3 个副本。 可以通过 Azure 门户或某个编程选项分配副本。

额外的分区对密集型索引工作负荷很有用。 额外分区可将读/写操作分配到更多的计算资源。

最后，索引越大，查询所需的时间就越长。 因此，可能发现，每次增加分区都需要按比例少量增加副本。 查询和查询卷的复杂性影响查询执行的速度。

如何更改容量

若要增加或减少搜索服务的容量，请添加或删除分区和副本。

1. 登录到 Azure 门户，并选择搜索服务。

2. 在“设置”中，打开“规模”页以修改副本和分区 。

   以下屏幕截图显示了预配有一个副本和分区的标准服务。 底部的公式指示正在使用多少个搜索单位 (1)。 如果单位价格为 $100（非实际价格），则运行此服务的每月成本平均为 $100。

   

3. 使用滑块增加或减少分区数。 选择“保存”。

   此示例添加第二个副本和分区。 请注意搜索单位计数；现在有 4 个搜索单位，因为计费公式是副本数乘以分区数 (2 x 2)。 将容量翻倍不仅仅会使运行服务的成本翻倍。 如果搜索单位的成本是 $100，则新的每月费用将是 $400。

   有关每个层的当前单位成本，请访问定价页。

   

4. 保存后，你可以查看通知以确认操作是否成功。

   

   容量更改可能需要 15 分钟到几个小时才能完成。 一旦启动更改过程，就无法将其取消；系统不会实时监视副本和分区的调整。 但是，在更改过程中，会一直显示以下消息。

   

如何处理缩放请求

收到缩放请求后，搜索服务会执行以下操作：

1. 检查请求是否有效。
2. 开始备份数据和系统信息。
3. 检查服务是否已处于预配状态（当前正在添加或消除副本或分区）。
4. 启动预配。

缩放服务可能仅需要 15 分钟，也可能超过一小时，具体取决于服务大小和请求范围。 备份可能需要几分钟时间，具体取决于数据量以及分区和副本的数量。

上述步骤并非完全连续。 例如，系统在可安全进行配置时开始预配，这可能是在备份逐渐结束的时候。

缩放期间出错

错误消息“目前不允许执行服务更新操作，因为我们正在处理前一个请求”产生的原因是在服务已在处理前一个请求的情况下，重复请求了纵向缩减或扩展。

通过检查服务状态来验证预配状态，以解决此错误：

1. 使用管理 REST API、Azure PowerShell 或 Azure CLI 来获取服务状态。
2. 调用 Get Service (REST) 或 PowerShell 或 CLI 的等效项。
3. 查看 "provisioningState": "provisioning" 的响应

如果状态为“正在预配”，请等待请求完成。 在尝试另一个请求之前，状态应为“成功”或“失败”。 备份没有状态。 备份是一种内部操作，不太可能是任何缩放操作中断的因素。

如果搜索服务似乎停滞在预配状态，请检查不可用、查询量为零且没有索引更新的孤立索引。 不可用的索引可能会阻止对服务容量的更改。 具体而言，查找 CMK 加密的索引，其密钥不再有效。 应删除索引或还原密钥，使索引重新联机并取消阻止缩放操作。

分区和副本组合

以下图表适用于标准层和更高层。 它显示所有可能的分区和副本组合，每个服务的最大搜索单位数为 36。

基本搜索服务具有较低的搜索单位计数。

• 在 2024 年 4 月 3 日之前创建的搜索服务上，基本搜索服务可以包含一个分区以及最多三个副本，上限为三个 SU。 唯一可调整的资源是副本。

• 在 2024 年 4 月 3 日之后在受支持的区域中创建的搜索服务，基本服务最多可以有三个分区和三个副本。 最大 SU 限制为 9，用于支持分区和副本的完整补充。

对于任何计费层上的搜索服务（无论创建日期如何），至少需要两个副本才能在查询上实现高可用性。

有关每个层和货币的计费费率，请参阅“Azure AI 搜索定价页”。

使用计费层估算容量

存储需求取决于预计要生成的索引的大小。 没有可帮助估计的纯启发和概述。 确定索引大小的唯一方法是生成一个索引。 其大小取决于标记化和嵌入，以及是否启用了提示器、筛选和排序功能，或能否利用矢量压缩功能。

建议对计费层（基本或更高）进行估算。 免费层在多个客户共享的物理资源上运行，受不可控因素影响。 只有计费搜索服务的专用资源才能容纳更大的采样和处理时间，以便在开发期间更现实地估计索引数量、大小和查询量。

1. 检查每个层级的服务限制以确定较低层级是否可以支持需要的索引数量。 请考虑是否需要索引的多个副本才能用于活动开发、测试和生产。

   搜索服务受对象限制（索引数、索引器、技能集等）和存储限制的约束。 先达到的限制是有效限制。

2. 在可计费层中创建服务。 层针对某些工作负荷进行优化。 例如，“存储优化”层的索引数限制为 10 个，因为它旨在支持少量的极大型索引。

   • 如果你不确定预计负载有多大，请从较低的“基本”或“S1”层着手。

   • 起点高，如果测试包括大规模索引和查询负载，请从 S2 甚至 S3 开始。

   • 如果你要为大量的数据编制索引并且查询负载相对较低（例如，使用与内部商务应用程序时），请从“优化存储”层 L1 或 L2 着手。

3. 生成初始索引以确定将源数据转换为索引的方式。 这是估计索引大小的唯一方法。 字段定义的属性会影响物理存储要求：

   • 对于关键字搜索，将字段标记为可筛选且可排序会增加索引大小。

   • 对于矢量搜索，可以设置参数以减少存储。

4. 在门户中监视存储、服务限制、查询量和延迟。 门户会显示每秒查询数、限制的查询数和搜索延迟。 所有这些值可帮助你确定是否选择了合适的层。

5. 添加副本以实现高可用性或缓解查询性能缓慢。

   没有有关需要多少个副本来适应查询负载的指导。 查询性能取决于查询复杂性和争用资源的工作负荷。 尽管添加副本会明显提高性能，但结果不一定有线性改善：添加三个副本并不保证带来三倍的吞吐量。 有关评估解决方案的 QPS 的指导，请参阅分析性能和监视查询。

如果包含从不进行搜索的数据，则存储要求可能会过高。 理想情况下，文档仅包含搜索体验所需的数据。

服务级别协议注意事项

服务级别协议 (SLA) 不涵盖免费层和预览功能。 对于所有可计费的层，SLA 将在用户为服务提供足够冗余时生效。

• 两个或多个副本满足查询（读取）SLA。

• 三个或多个副本满足查询和索引（读写）SLA。

分区数不影响 SLA。

后续步骤