你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
估计和管理搜索服务的容量
在 Azure AI 搜索中，容量基于可扩展到工作负载的副本和分区。 副本是搜索引擎的副本。 分区是存储单元。 对于这两种资源，每项新搜索服务开始时都各有一种，但你可以单独添加或删除副本和分区，以适应波动的工作负载。 添加容量会增加运行搜索服务的成本。
副本和分区的物理特征（如处理速度和磁盘 IO）因服务层而异。 在标准搜索服务中，副本和分区比基本服务的副本和分区更快、更大。
更改容量不会即时生效。 启用或停用分区最多可能需要一小时，尤其是对于具有大量数据的服务。
缩放搜索服务时，可从下列工具和方法中进行选择：
注意
在 2024 年 4 月和 5 月之后创建的较新服务可按相同的计费费率获得更大容量的分区。 有关详细信息，请参阅分区大小升级的服务限制。
概念：搜索单位、副本、分区
容量以搜索单元表示，它可以按分区和副本的组合进行分配。
| 概念 | 定义 |
|---|---|
| 搜索单位 | 总可用容量（36 个单位）的单一增量。 至少需要一个单位才能运行服务。 第一个副本和分区对是第一个搜索单位。 但副本或分区的每个额外实例将会消耗一个额外的搜索单位。 例如，你从一个副本和分区（一个搜索单元）开始，添加第二个副本，现在将会消耗两个搜索单位。 搜索单位也是 Azure AI 搜索服务的计费单位。 |
| 副本 | 是搜索服务的实例，主要用于对查询操作进行负载均衡。 每个副本承载着索引的一个副本。 如果分配三个副本，则可以使用索引的三个副本来为查询请求提供服务。 |
| 分区 | 为读/写操作（例如，在重建或刷新索引时进行的此类操作）提供物理存储和 I/O。 每个分区都有总体索引的一个切片。 如果分配三个分区，则索引将划分为三个部分。 |
查看分区和副本表，了解可能保持在 36 个单位限制下的组合。
何时添加容量
最初为服务分配了由一个分区和一个副本组成的最低级别的资源。 所选的层确定了分区大小和速度，每个层已根据一组适合不同方案的特征进行优化。 如果选择更高端的层，与使用 S1 时相比，所需的分区数可能更少。 需要通过自我引导式测试解答的一个问题是，对于性能而言，使用更大且更昂贵的分区，是否比在较低层上预配的服务中使用两个更廉价的分区更好。
单个服务必须具有足够的资源才能处理所有工作负荷（索引和查询）。 没有任何工作负荷在后台运行。 如果查询请求在性质上不频繁，则可以计划索引编制，但如果不这样做，服务也不会排定任务的优先级。 此外，在内部更新服务或节点时，一定程度的冗余也会销蚀查询性能。
确定是否添加容量的一些准则包括：
- 满足服务级别协议的高可用性标准
- HTTP 503 错误的频率正在增加
- 有很大的查询量
根据惯例，搜索应用程序所需的副本数往往多过分区数，尤其是在服务操作偏向于查询工作负荷的情况下。 每个副本都是索引副本，使服务能根据多个副本对请求进行负载均衡。 所有负载均衡和索引复制均由 Azure AI 搜索管理，随时可以更改为服务分配的副本数量。 最大可在一个标准搜索服务中分配 12 个副本，并在一个基本搜索服务中分配 3 个副本。 可以通过 Azure 门户或某个编程选项分配副本。
额外的分区对密集型索引工作负荷很有用。 额外分区可将读/写操作分配到更多的计算资源。
最后，索引越大，查询所需的时间就越长。 因此，可能发现，每次增加分区都需要按比例少量增加副本。 查询和查询卷的复杂性影响查询执行的速度。
注意
添加更多的副本或分区会增加运行服务的成本，并可能在结果的排序方式上引入细微变化。 请务必查看定价计算器来了解添加更多节点对计费造成的影响。 以下图表可帮助你交叉参考特定配置所需的搜索单位数。 有关其他副本如何影响查询处理的详细信息，请参阅排序结果。
如何更改容量
若要增加或减少搜索服务的容量，请添加或删除分区和副本。
登录到 Azure 门户，并选择搜索服务。
在“设置”中，打开“规模”页以修改副本和分区 。
以下屏幕截图显示了预配有一个副本和分区的标准服务。 底部的公式指示正在使用多少个搜索单位 (1)。 如果单位价格为 $100（非实际价格），则运行此服务的每月成本平均为 $100。
使用滑块增加或减少分区数。 选择“保存”。
此示例添加第二个副本和分区。 请注意搜索单位计数；现在有 4 个搜索单位，因为计费公式是副本数乘以分区数 (2 x 2)。 将容量翻倍不仅仅会使运行服务的成本翻倍。 如果搜索单位的成本是 $100，则新的每月费用将是 $400。
有关每个层的当前单位成本，请访问定价页。
保存后，你可以查看通知以确认操作是否成功。
容量更改可能需要 15 分钟到几个小时才能完成。 一旦启动更改过程，就无法将其取消；系统不会实时监视副本和分区的调整。 但是，在更改过程中，会一直显示以下消息。
注意
预配服务后，无法升级到更高的层。 必须在新层中创建搜索服务，并重新加载索引。 有关服务预配的帮助，请参阅在门户中创建 Azure AI 搜索服务。
如何处理缩放请求
收到缩放请求后，搜索服务会执行以下操作：
- 检查请求是否有效。
- 开始备份数据和系统信息。
- 检查服务是否已处于预配状态（当前正在添加或消除副本或分区）。
- 启动预配。
缩放服务可能仅需要 15 分钟，也可能超过一小时，具体取决于服务大小和请求范围。 备份可能需要几分钟时间，具体取决于数据量以及分区和副本的数量。
上述步骤并非完全连续。 例如，系统在可安全进行配置时开始预配，这可能是在备份逐渐结束的时候。
缩放期间出错
错误消息“目前不允许执行服务更新操作，因为我们正在处理前一个请求”产生的原因是在服务已在处理前一个请求的情况下，重复请求了纵向缩减或扩展。
通过检查服务状态来验证预配状态，以解决此错误：
- 使用管理 REST API、Azure PowerShell 或 Azure CLI 来获取服务状态。
- 调用 Get Service (REST) 或 PowerShell 或 CLI 的等效项。
- 查看 "provisioningState": "provisioning" 的响应
如果状态为“正在预配”，请等待请求完成。 在尝试另一个请求之前，状态应为“成功”或“失败”。 备份没有状态。 备份是一种内部操作，不太可能是任何缩放操作中断的因素。
如果搜索服务似乎停滞在预配状态，请检查不可用、查询量为零且没有索引更新的孤立索引。 不可用的索引可能会阻止对服务容量的更改。 具体而言，查找 CMK 加密的索引，其密钥不再有效。 应删除索引或还原密钥，使索引重新联机并取消阻止缩放操作。
分区和副本组合
以下图表适用于标准层和更高层。 它显示所有可能的分区和副本组合，每个服务的最大搜索单位数为 36。
| 1 个分区 | 2 个分区 | 3 个分区 | 4 个分区 | 6 个分区 | 12 个分区 | |
|---|---|---|---|---|---|---|
| 1 个副本 | 1 个 SU | 2 SU | 3 SU | 4 SU | 6 SU | 12 SU |
| 2 个副本 | 2 SU | 4 SU | 6 SU | 8 SU | 12 SU | 24 SU |
| 3 个副本 | 3 SU | 6 SU | 9 SU | 12 SU | 18 SU | 36 个 SU |
| 4 个副本 | 4 SU | 8 SU | 12 SU | 16 SU | 24 SU | 不适用 |
| 5 副本 | 5 SU | 10 SU | 15 SU | 20 SU | 30 SU | 不适用 |
| 6 个副本 | 6 SU | 12 SU | 18 SU | 24 SU | 36 个 SU | 不适用 |
| 12 副本 | 12 SU | 24 SU | 36 个 SU | 空值 | 不可用 | 空值 |
基本搜索服务具有较低的搜索单位计数。
在 2024 年 4 月 3 日之前创建的搜索服务上，基本搜索服务可以包含一个分区以及最多三个副本，上限为三个 SU。 唯一可调整的资源是副本。
在 2024 年 4 月 3 日之后在受支持的区域中创建的搜索服务，基本服务最多可以有三个分区和三个副本。 最大 SU 限制为 9，用于支持分区和副本的完整补充。
对于任何计费层上的搜索服务（无论创建日期如何），至少需要两个副本才能在查询上实现高可用性。
有关每个层和货币的计费费率，请参阅“Azure AI 搜索定价页”。
使用计费层估算容量
存储需求取决于预计要生成的索引的大小。 没有可帮助估计的纯启发和概述。 确定索引大小的唯一方法是生成一个索引。 其大小取决于标记化和嵌入，以及是否启用了提示器、筛选和排序功能，或能否利用矢量压缩功能。
建议对计费层（基本或更高）进行估算。 免费层在多个客户共享的物理资源上运行，受不可控因素影响。 只有计费搜索服务的专用资源才能容纳更大的采样和处理时间，以便在开发期间更现实地估计索引数量、大小和查询量。
检查每个层级的服务限制以确定较低层级是否可以支持需要的索引数量。 请考虑是否需要索引的多个副本才能用于活动开发、测试和生产。
搜索服务受对象限制（索引数、索引器、技能集等）和存储限制的约束。 先达到的限制是有效限制。
在可计费层中创建服务。 层针对某些工作负荷进行优化。 例如，“存储优化”层的索引数限制为 10 个，因为它旨在支持少量的极大型索引。
如果你不确定预计负载有多大，请从较低的“基本”或“S1”层着手。
起点高，如果测试包括大规模索引和查询负载，请从 S2 甚至 S3 开始。
如果你要为大量的数据编制索引并且查询负载相对较低（例如，使用与内部商务应用程序时），请从“优化存储”层 L1 或 L2 着手。
生成初始索引以确定将源数据转换为索引的方式。 这是估计索引大小的唯一方法。 字段定义的属性会影响物理存储要求：
在门户中监视存储、服务限制、查询量和延迟。 门户会显示每秒查询数、限制的查询数和搜索延迟。 所有这些值可帮助你确定是否选择了合适的层。
添加副本以实现高可用性或缓解查询性能缓慢。
没有有关需要多少个副本来适应查询负载的指导。 查询性能取决于查询复杂性和争用资源的工作负荷。 尽管添加副本会明显提高性能，但结果不一定有线性改善：添加三个副本并不保证带来三倍的吞吐量。 有关评估解决方案的 QPS 的指导，请参阅分析性能和监视查询。
对于倒排索引，大小和复杂度由内容决定，不一定是输入的数据量。 具有高度冗余的大型数据源可能会导致比包含高度可变内容的较小数据集更小的索引。 因此，很难根据原始数据集的大小来推断索引大小。
如果包含从不进行搜索的数据，则存储要求可能会过高。 理想情况下，文档仅包含搜索体验所需的数据。
服务级别协议注意事项
服务级别协议 (SLA) 不涵盖免费层和预览功能。 对于所有可计费的层，SLA 将在用户为服务提供足够冗余时生效。
两个或多个副本满足查询（读取）SLA。
三个或多个副本满足查询和索引（读写）SLA。
分区数不影响 SLA。