在 Azure AI 搜索中，容量基于可扩展到工作负载的副本和分区。 副本是搜索引擎的副本。 分区是存储单元。 对于这两种资源，每项新搜索服务开始时都各有一种，但你可以单独添加或删除副本和分区，以适应波动的工作负载。 添加容量会增加运行搜索服务的成本。
副本和分区（例如处理速度和磁盘 IO）的物理特征因 定价层而异。 在标准搜索服务中，副本和分区比基本服务的副本和分区更快、更大。
更改容量不会即时生效。 启用或停用分区最多可能需要一小时，尤其是对于具有大量数据的服务。
缩放搜索服务时，可从下列工具和方法中进行选择：
概念：搜索单位、副本、分区
容量以搜索单元表示，它可以按分区和副本的组合进行分配。
| 概念 | 定义 |
|---|---|
| 搜索单位 | 总可用容量（36 个单位）的单一增量。 至少需要一个单位才能运行服务。 第一个副本和分区对是第一个搜索单位。 但副本或分区的每个额外实例将会消耗一个额外的搜索单位。 例如，从一个副本和分区（一个搜索单元）开始，添加第二个副本，现在使用两个搜索单元。 搜索单位也是 Azure AI 搜索服务的计费单位。 |
| 副本 | 是搜索服务的实例，主要用于对查询操作进行负载均衡。 每个副本承载着索引的一个副本。 如果分配三个副本，则可以使用索引的三个副本来为查询请求提供服务。 |
| 分区 | 为读/写操作（例如，在重建或刷新索引时进行的此类操作）提供物理存储和 I/O。 每个分区都有总体索引的一个切片。 如果分配三个分区，则索引将划分为三个部分。 |
查看分区和副本表，了解可能保持在 36 个单位限制下的组合。
何时添加容量
最初为服务分配了由一个分区和一个副本组成的最低级别的资源。 所选的层确定了分区大小和速度，每个层已根据一组适合不同方案的特征进行优化。 如果选择更高端的层，与使用 S1 时相比，所需的分区数可能更少。 需要通过自我定向测试回答的一个问题是，更大且更昂贵的分区是否比在较低层预配的服务上的两个更便宜的分区产生更好的性能。
单个服务必须具有足够的资源才能处理所有工作负荷（索引和查询）。 没有任何工作负荷在后台运行。 可以为查询请求自然频率较低的时间计划索引，但服务不会将一个任务优先于另一个任务。 此外，在内部更新服务或节点时，一定程度的冗余也会销蚀查询性能。
确定是否添加容量的准则包括：
- 满足服务级别协议的高可用性条件。
- HTTP 503（服务不可用）错误的频率正在增加。
- HTTP 429（请求过多）错误的频率正在增加，这表示存储不足。
- 预计会有大量的查询量。
- 一次性升级到较新的基础结构和更大的分区是不够的。
- 当前分区数量不足以应付索引工作负载。
根据惯例，搜索应用程序所需的副本数往往多过分区数，尤其是在服务操作偏向于查询工作负荷的情况下。 每个副本都是索引副本，使服务能根据多个副本对请求进行负载均衡。 Azure AI 搜索管理索引的所有负载均衡和复制，可以随时更改为服务分配的副本数。 最大可在一个标准搜索服务中分配 12 个副本，并在一个基本搜索服务中分配 3 个副本。 可以通过 Azure 门户或某个编程选项分配副本。
额外的分区对密集型索引工作负荷很有用。 额外分区可将读/写操作分配到更多的计算资源。
最后，索引越大，查询所需的时间就越长。 因此，可能发现，每次增加分区都需要按比例少量增加副本。 查询的复杂性和查询量影响查询执行的速度。
注意
添加更多的副本或分区会增加运行服务的成本，并可能在结果的排序方式上引入细微变化。 请务必查看定价计算器来了解添加更多节点对计费造成的影响。 以下图表可帮助你交叉参考特定配置所需的搜索单位数。 有关额外副本如何影响查询处理的详细信息，请参阅 “排序结果”。
如何更改容量
若要增加或减少搜索服务的容量，请添加或删除分区和副本。
添加或删除分区和副本
登录到 Azure 门户 并选择搜索服务。
在左窗格中，选择“设置”>“缩放”。
以下屏幕截图显示了预配有一个副本和分区的标准服务。 底部的公式指示正在使用多少个搜索单位 (1)。 如果单位价格为 $100（非实际价格），则运行此服务的每月成本平均为 $100。
使用滑块增加或减少分区数。 选择“保存”。
此示例添加第二个副本和分区。 请注意搜索单位计数；现在有 4 个搜索单位，因为计费公式是副本数乘以分区数 (2 x 2)。 将容量翻倍不仅仅会使运行服务的成本翻倍。 如果搜索单位的成本是 $100，则新的每月费用将是 $400。
有关每个层的当前单位成本，请访问 定价页。
检查通知以确认操作是否已启动。
此作可能需要几个小时才能完成。 启动更改过程后，就无法将其取消；系统不会实时监视副本和分区的调整。 但是，在更改过程中，会显示以下消息。
更改定价层
注意
2025-02-01 预览版支持基本层和标准层（S1、S2 和 S3）层之间的更改。 目前，只能从更低层级切换到更高层级，例如从基本层切换到 S1。 你的区域也不能在更高的层上具有容量约束。
定价层确定搜索服务的最大存储。 如果需要更多 容量，可以切换到满足存储需求的不同定价层。
除了容量，更改定价层还会影响服务的工作负荷和最大限制。 在继续之前，请比较您当前层的服务限制和所需层的服务限制。 其中包括以下限制：
- 分区存储
- 索引
- 向量
- 索引器
- 共享专用链接资源
- 同义词
- 索引别名
- 语义排序器限制
通常，切换到更高的层会增加 存储限制 和 矢量限制、增加请求吞吐量并降低延迟。
若要更改价格层级，请执行以下步骤：
登录到 Azure 门户 并选择搜索服务。
在左窗格中，选择“设置”>“缩放”。
在当前层下，选择“ 更改定价层”。
在 “选择定价层 ”页上，从列表中选择更高的层。 目前，只能在基本、S1、S2 和 S3 之间向上移动。 其他定价层不可用，且显示为灰色。
若要切换到更高的层，请选择 “选择”。
此作可能需要几个小时才能完成。 启动后无法取消该过程，并且没有对层更改进行实时监视。 但是，在“概述”页上，“预配”状态表示您的服务正在进行操作。
如何处理缩放请求
收到缩放请求后，搜索服务会执行以下操作：
- 检查请求是否有效。
- 开始备份数据和系统信息。
- 检查服务是否已处于预配状态（当前正在添加或消除副本或分区）。
- 启动预配。
缩放服务可能仅需要 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 日之前创建的搜索服务上，基本服务只能有一个分区和最多三个副本，最大限制为 3 个 SU。 唯一可调整的资源是副本。
在 2024 年 4 月 3 日之后在 受支持的区域中创建的搜索服务上，基本服务最多可以有三个分区和三个副本。 最大 SU 限制为 9，用于支持分区和副本的完整补充。
对于任何计费层上的搜索服务（无论创建日期如何），至少需要两个副本才能在查询上实现高可用性。
有关每个层和货币的计费费率，请参阅“Azure AI 搜索定价页”。
使用计费层估算容量
要生成的索引的大小决定了存储需求。 没有可帮助估计的纯启发和概述。 确定索引大小的唯一方法是生成一个索引。 其大小取决于标记化和嵌入，以及是否启用了提示器、筛选和排序功能，或能否利用矢量压缩功能。
建议对计费层（基本或更高）进行估算。 免费层在多个客户共享的物理资源上运行，受不可控因素影响。 只有计费搜索服务的专用资源才能容纳更大的采样和处理时间，以便在开发期间更现实地估计索引数量、大小和查询量。
检查每个层级的服务限制以确定较低层级是否可以支持需要的索引数量。 请考虑是否需要索引的多个副本才能用于活动开发、测试和生产。
搜索服务受对象限制（索引数、索引器、技能集等）和存储限制的约束。 先达到的限制是有效限制。
在可计费层中创建服务。 层针对某些工作负荷进行优化。 例如，存储优化层的限制为 10 个索引，因为它旨在支持少量的大型索引。
如果你不确定预计负载有多大，请从较低的“基本”或“S1”层着手。
起点高，如果测试包括大规模索引和查询负载，请从 S2 甚至 S3 开始。
如果你要为大量的数据编制索引并且查询负载相对较低（例如，使用与内部商务应用程序时），请从“优化存储”层 L1 或 L2 着手。
生成初始索引以确定将源数据转换为索引的方式。 这是估计索引大小的唯一方法。 字段定义的属性会影响物理存储要求：
对于关键字搜索，将字段标记为可筛选且可排序会增加索引大小。
对于矢量搜索，可以设置参数以减小矢量大小。
在 Azure 门户中监视存储、服务限制、查询量和延迟。 Azure 门户会显示每秒查询数、限制的查询数和搜索延迟。 所有这些值可帮助你确定是否选择了合适的层。
添加副本以实现高可用性或缓解查询性能缓慢。
没有有关需要多少个副本来适应查询负载的指导。 查询性能取决于查询复杂性和争用资源的工作负荷。 尽管添加副本会明显提高性能，但结果不一定有线性改善：添加三个副本并不保证带来三倍的吞吐量。 有关评估解决方案的 QPS 的指导，请参阅分析性能和监视查询。
如果包含从不进行搜索的数据，则存储要求可能会过高。 理想情况下，文档仅包含搜索体验所需的数据。
服务级别协议注意事项
服务级别协议 (SLA) 不涵盖免费层和预览功能。 对于所有可计费的层，SLA 将在用户为服务提供足够冗余时生效。
两个或多个副本满足查询（读取）SLA。
三个或多个副本满足查询和索引（读写）SLA。
分区数不影响 SLA。