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

在创建搜索服务和锁定特定的定价层之前，请花几分钟时间来了解容量如何工作以及如何调整副本和分区来适应工作负载波动。

在 Azure 认知搜索中，容量基于副本和分区 。 副本是搜索引擎的副本。 分区是存储单元。 对于这两种资源，每项新搜索服务开始时都各有一种，但你可以单独纵向扩展每种资源以适应波动的工作负载。 添加任一资源均可计费。

副本和分区的物理特征（如处理速度和磁盘 IO）因服务层而异。 与在基本层上预配相比，如果在标准层上预配，副本和分区的速度更快、容量更大。

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

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

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

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

容量以搜索单位表示，可以通过分区和副本的组合进行分配，并使用基础分片机制来支持灵活的配置：

下图显示了副本、分区、分片与搜索单位之间的关系。 它显示了一个示例，该示例说明了在具有两个副本和两个分区的服务中，单个索引如何跨越四个搜索单位。 这四个搜索单位每个都只存储索引的一半分片。 左列中的搜索单位存储分片的第一半，构成第一个分区，而右列中的搜索单位存储分片的第二半，构成第二个分区。 由于有两个副本，因此每个索引分片有两个副本。 顶部行中的搜索单位存储着一个副本，构成第一个副本，而底部行中的搜索单位存储着另一个副本，构成第二个副本。

上图只是一个示例。 分区和副本有许多可能的组合，最多可包含 36 个搜索单位（总计）。

在认知搜索中，分片管理是实现细节且不可配置，但知道索引是分片的有助于你了解排名和自动完成行为中的偶然异常：

• 排名异常：搜索评分首先在分片级别计算，然后聚合成单个结果集。 根据分片内容的特征，一个分片中的匹配项的排名可能高于另一个分片中的匹配项。 如果你在搜索结果中发现与预料相反的排名，则很可能是由于分片的影响，尤其是在索引较小的情况下。 你可以通过选择在整个索引中全局计算评分来避免这些排名异常，但这样做会导致性能下降。

• 自动完成异常：自动完成查询（根据仅输入了一部分内容的单词的前几个字符进行匹配）接受一个模糊参数，该参数允许有微小的拼写差异。 对于自动完成，模糊匹配被限制为当前分片中的字词。 例如，如果某个分片包含“Microsoft”，并且输入了部分字词“micor”，则搜索引擎将针对该分片中的“Microsoft”进行匹配，但不会在包含索引剩余部分的其他分片中进行匹配。

接近估计

容量与运行服务的成本密切相关。 层对两个级别施加限制：内容（例如服务上的索引计数）和存储。 请务必考虑到这两者，因为首先达到的限制就是有效的限制。

索引和其他对象的数量通常由业务和工程要求决定。 例如，你可能有用于积极开发、测试和生成的同一索引的多个版本。

存储需求取决于预计要生成的索引的大小。 没有可帮助估计的纯启发和概述。 确定索引大小的唯一方法是生成一个索引。 索引的大小将基于导入的数据、文本分析和索引配置，例如是否启用建议器、筛选和排序。

进行全文搜索时，主要数据结构是倒排索引结构，该结构具有与源数据不同的特征。 对于倒排索引，大小和复杂度由内容决定，不一定是输入的数据量。 具有高度冗余的大型数据源可能会导致比包含高度可变内容的较小数据集更小的索引。 因此，很难根据原始数据集的大小来推断索引大小。

索引上的属性（例如启用筛选器和排序）会影响存储要求。 使用建议器还会产生存储影响。 有关详细信息，请参阅属性和索引大小。

使用“免费”层进行评估

估算容量的一种方法是从“免费”层开始。 回想一下，“免费”服务最多提供 3 个索引、50 MB 存储和 2 分钟索引时间。 根据这些约束估算预计索引大小可能很有难度，具体步骤如下：

• 创建免费服务。

• 准备一个小型的有代表性的数据集。

• 创建索引并加载数据。 如果可在索引器支持的 Azure 数据源中承载数据集，则你可以使用门户中的导入数据向导创建和加载索引。 否则，应使用 REST 和 Postman 或 Visual Studio Code 来创建索引和推送数据。 推送模型要求数据采用 JSON 文档的形式，其中文档中的字段与索引中的字段相对应。

• 收集有关索引的信息，如大小。 功能和属性会影响存储。 例如，添加建议器（“边键入边搜索”查询）会提高存储要求。

  可以使用同一个数据集尝试创建索引的多个版本，并在每个字段中使用不同的属性，以了解存储要求的变化。 有关详细信息，请参阅“创建基本索引”中的“存储影响”。

估算出粗略的数字后，可将此数量增大一倍来得出两个索引（开发和生产）的预算，然后相应地选择层。

使用计费层进行评估

专用资源可以适应更大的采样和处理时间，并可以在开发期间对索引数量、大小和查询量进行更贴近实际的估算。 某些客户会直接选择计费层，然后在开发项目成熟后重新进行评估。

1. 检查每个层级的服务限制以确定较低层级是否可以支持需要的索引数量。 在“基本”、“S1”和“S2”层中，索引数限制分别为 15、50 和 200。 “存储优化”层的索引数限制为 10 个，因为它旨在支持少量的极大型索引。

2. 在可计费层中创建服务：

   • 如果你不确定预计负载有多大，请从较低的“基本”或“S1”层着手。
   • 起点高，如果测试包括大规模索引和查询负载，请从 S2 甚至 S3 开始。
   • 如果你要为大量的数据编制索引并且查询负载相对较低（例如，使用与内部商务应用程序时），请从“优化存储”层 L1 或 L2 着手。

3. 生成初始索引以确定将源数据转换为索引的方式。 这是估计索引大小的唯一方法。

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

5. 如果需要高可用性或遇到查询性能缓慢问题，请添加副本。

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

查询量注意事项

每秒查询数 (QPS) 在性能优化期间是一个重要的指标，但如果你预期查询量一开始就很高，则通常只需考虑到层。

“标准”层可以提供平衡的副本数和分区数。 可以添加副本来实现负载均衡，或添加分区进行并行处理，以此增大查询周转时间。 然后，可以在预配服务后优化性能。

如果你预期持续查询量一开始就很高，应考虑更高的由更强大硬件支持的“标准”层。 如果不会这些这种查询量，可以使分区和副本脱机，甚至切换到更低层的服务。 有关如何计算查询吞吐量的详细信息，请参阅 Azure 认知搜索性能和优化。

“存储优化”层可用于大数据工作负荷，当查询延迟要求不太重要时，可以支持更大的总体可用索引存储。 仍应使用更多的副本进行负载均衡，并使用更多的分区进行并行处理。 然后，可以在预配服务后优化性能。

服务级别协议

服务级别协议 (SLA) 不涵盖免费层和预览功能。 对于所有可计费的层，SLA 将在用户为服务提供足够冗余时生效。 需要为查询（读取）SLA 提供两个或更多个副本。 需要为查询和索引（读写）SLA 提供三个或更多个副本。 分区数不影响 SLA。

容量计划提示

• 允许围绕查询生成指标，并围绕使用模式收集数据（在营业期间执行查询，在非高峰期执行索引编制）。 使用此数据做出明智的服务预配决策。 尽管这种做法不是在每小时或每日都可行，但可以动态调整分区和资源，以应对查询量的计划内变化。 此外，还可以应对计划外的但持续性的变化，前提是变化程度持续足够长的时间，以致有必要采取措施。

• 请记住，预配不足的唯一缺点是，如果实际需求超出预测，则可能必须关闭某项服务。 为避免服务中断，可以在更高层级创建新服务，并让其并排运行，直到所有应用和请求都指向新的终结点。

何时添加容量

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

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

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

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

根据惯例，搜索应用程序所需的副本数往往多过分区数，尤其是在服务操作偏向于查询工作负荷的情况下。 每个副本都是索引副本，使服务能根据多个副本对请求进行负载均衡。 所有负载均衡和索引复制均由 Azure 认知搜索管理，随时可以更改为服务分配的副本数量。 最大可在一个标准搜索服务中分配 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 服务
3. 查看 "provisioningState": "provisioning" 的响应

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

分区和副本组合

“基本”服务可以包含一个分区以及最多三个副本，上限为三个 SU。 唯一可调整的资源是副本。 至少需要两个副本才能实现查询的高可用性。

所有“标准”和“存储优化”搜索服务都可以采用副本和分区的以下组合，但这些层允许的限制不能超过 36 个 SU 的限制。

Azure 网站上详细说明了 SU、定价和容量。 有关详细信息，请参阅 Pricing Details（定价详细信息）。

后续步骤