您现在访问的是微软AZURE全球版技术文档网站,若需要访问由世纪互联运营的MICROSOFT AZURE中国区技术文档网站,请访问 https://docs.azure.cn.

选择 Azure 搜索的 SKU 或定价层Choose a SKU or pricing tier for Azure Search

在 Azure 搜索中,服务已在特定的定价层或 SKU 上进行预配In Azure Search, a service is provisioned at a specific pricing tier or SKU. 选项包括“免费”、“基本”或“标准”,其中“标准”在多个配置和容量中均可用。Options include Free, Basic, or Standard, where Standard is available in multiple configurations and capacities.

本文旨在帮助你选择层。The purpose of this article is to help you choose a tier. 如果层容量经证实过低,将需要在更高的层上预配新服务,然后重新加载索引。If a tier's capacity turns out to be too low, you will need to provision a new service at the higher tier and then reload your indexes. 相同的服务无法从一个 SKU 就地升级到另一个。There is no in-place upgrade of the same service from one SKU to another.

备注

选择层并预配搜索服务后,可在该服务内增加副本和分区计数。After you choose a tier and provision a search service, you can increase replica and partition counts within the service. 有关指南,请参阅缩放资源级别以便查询工作负荷并编制索引For guidance, see Scale resource levels for query and indexing workloads.

如何进行定价层决定How to approach a pricing tier decision

在 Azure 搜索中,层确定容量而非功能可用性。In Azure Search, the tier determines capacity, not feature availability. 通常情况下,每个层都会提供功能,包括预览功能。Generally, features are available at every tier, including preview features. 一个例外是,不支持 S3 HD 中的索引器。The one exception is no support for indexers in S3 HD.

提示

我们建议始终预配“免费”服务(每个订阅一个,不会过期)以便可随时用于轻量项目。We recommend that you always provision a Free service (one per subscription, with no expiration) so that its readily available for light-weight projects. 将“免费”服务用于测试和评估;在“基本”或“标准”层上创建第二个可计费服务以便用于生产或更大的测试工作负荷。Use the Free service for testing and evaluation; create a second billable service at the Basic or Standard tier for production or larger test workloads.

容量与运行服务的成本密切相关。Capacity and costs of running the service go hand-in-hand. 本文中的信息可帮助你决定哪一个 SKU 可提供适当的平衡,但如果要使任何一个都有用,将至少需要粗略估计以下内容:Information in this article can help you decide which SKU delivers the right balance, but for any of it to be useful, you need at least rough estimates on the following:

  • 计划创建的索引的数目和大小Number and size of indexes you plan to create
  • 要上传的文档的数目和大小Number and size of documents to upload
  • 查询量的一些概念,即每秒查询次数 (QPS)。Some idea of query volume, in terms of Queries Per Second (QPS). 有关指南,请参阅 Azure 搜索的性能和优化For guidance, see Azure Search performance and optimization.

数目和大小非常重要,因为可以通过对每服务的索引计数进行硬限制,或对服务所使用的资源(存储或副本)上的索引计数进行硬限制,达到最大限制。Number and size are important because maximum limits are reached through a hard limit on the count of indexes per service, or on resources (storage or replicas) used by the service. 服务的实际限制将是首先耗尽的项目:资源或对象。The actual limit for your service is whichever gets used up first: resources or objects.

在进行了评估后,以下步骤应该能简化过程:With estimates in hand, the following steps should simplify the process:

  • 步骤 1 查看以下 SKU 描述,了解可用选项。Step 1 Review the SKU descriptions below to learn about available options.
  • 步骤 2 回答以下问题,以便做出初步的决定。Step 2 Answer the questions below to arrive at a preliminary decision.
  • 步骤 3 通过查看存储和定价的严格限制,最后落实决定。Step 3 Finalize your decision by reviewing hard limits on storage and pricing.

SKU 描述SKU descriptions

下表提供每个层的描述。The following table provides descriptions of each tier.

Tier 主要方案Primary scenarios
免费Free 共享的服务,不收费,用于评估、调查或少量工作负载。A shared service, at no charge, used for evaluation, investigation, or small workloads. 由于它是与其他订阅者共享的,因此查询吞吐量和索引会因使用该服务的其他用户而异。Because it's shared with other subscribers, query throughput and indexing varies based on who else is using the service. 容量很小(50 MB 或各具有最多 10000 个文档的 3 个索引)。Capacity is small (50 MB or 3 indexes with up 10,000 documents each).
基本Basic 专用硬件上的小量生产工作负荷。Small production workloads on dedicated hardware. 高可用性。Highly available. 容量最多可容纳 3 个副本和 1 个分区 (2 GB)。Capacity is up to 3 replicas and 1 partition (2 GB).
S1S1 标准 1 支持分区 (12) 和副本 (12) 的弹性组合,用于专用硬件上的中等生产工作负荷。Standard 1 supports flexible combinations of partitions (12) and replicas (12), used for medium production workloads on dedicated hardware. 可以根据计费搜索单位最大数目 36 所支持的组合来分配分区和副本。You can allocate partitions and replicas in combinations supported by a maximum number of 36 billable search units. 在此级别,每个分区是 25 GB。At this level, partitions are 25 GB each.
S2S2 标准 2 使用与 S1 相同的 36 个搜索单位来运行较大的生产工作负荷,不过使用较大的分区和副本。Standard 2 runs larger production workloads using the same 36 search units as S1 but with larger sized partitions and replicas. 在此级别,每个分区是 100 GB。At this level, partitions are 100 GB each.
S3S3 标准 3 在更高端的系统上按比例运行更大的生产工作负荷,具体配置如下:在 36 个搜索单位下最高可达 12 个分区或 12 个副本。Standard 3 runs proportionally larger production workloads on higher end systems, in configurations of up to 12 partitions or 12 replicas under 36 search units. 在此级别,每个分区是 200 GB。At this level, partitions are 200 GB each.
S3 HDS3 HD 标准 3 高密度专用于大量的较小索引。Standard 3 High Density is designed for a large number of smaller indexes. 最多可具有 3 个分区,每个各 200 GB。You can have up to 3 partitions, at 200 GB each.

备注

副本和分区最大值会按搜索单位计费(每个服务最多 36 个单位),这会强制执行比表面上所指最大限制更低的有效限制。Replica and partition maximums are billed out as search units (36 unit maximum per service), which imposes a lower effective limit than what the maximum implies at face value. 例如,若要使用最多 12 个副本,最多可以有 3 个分区(12 * 3 = 36 个单位)。For example, to use the maximum of 12 replicas, you could have at most 3 partitions (12 * 3 = 36 units). 同样地,要使用最大分区数,则将副本数减少为 3。Similarly, to use maximum partitions, reduce replicas to 3. 有关允许组合的图表,请参阅在 Azure 搜索中缩放资源级别以便查询工作负荷并编制索引See Scale resource levels for query and indexing workloads in Azure Search for a chart on allowable combinations.

查看每个层的限制Review limits per tier

下图是 Azure 搜索的服务限制中的限制子集。The following chart is a subset of the limits from Service Limits in Azure Search. 它列出最有可能影响 SKU 决策的因素。It lists the factors most likely to impact a SKU decision. 查看以下问题时,可参阅此图表。You can refer to this chart when reviewing the questions below.

资源Resource 免费Free 基本Basic S1S1 S2S2 S3S3 S3 HDS3 HD
服务级别协议 (SLA)Service Level Agreement (SLA) 1No 1 Yes Yes Yes Yes Yes
索引限制Index limits 33 55 5050 200200 200200 1000 21000 2
文档限制Document limits 总计 10,00010,000 total 每个服务 100 万1 million per service 每个分区 1500 万个15 million per partition 每个分区 6000 万60 million per partition 每个分区 1.2 亿120 million per partition 每个索引 100 万1 million per index
分区数上限Maximum partitions 不适用N/A 11 1212 1212 1212 3 23 2
分区大小Partition size 总计 50 MB50 MB total 每个服务 2 GB2 GB per service 每个分区 25 GB25 GB per partition 每个分区 100 GB(每个服务最多 1.2 TB)100 GB per partition (up to a maximum of 1.2 TB per service) 每个分区 200 GB(每个服务最多 2.4 TB)200 GB per partition (up to a maximum of 2.4 TB per service) 200 GB(每个服务最多 600 GB)200 GB (up to a maximum of 600 GB per service)
副本数上限Maximum replicas 不适用N/A 33 1212 1212 1212 1212

1 免费层和预览功能不带服务级别协议 (SLA)。1 Free tier and preview features do not come with service level agreements (SLAs). 对于所有可计费的层,SLA 将在用户为服务提供足够冗余时生效。For all billable tiers, SLAs take effect when you provision sufficient redundancy for your service. 查询(读取)SLA 需要两个或多个副本。Two or more replicas are required for query (read) SLA. 查询和索引(读-写)SLA 需要不少于三个副本。Three or more replicas are required for query and indexing (read-write) SLA. 分区数不属于 SLA 相关考虑因素。The number of partitions is not an SLA consideration.

2 S3 和 S3 HD 受相同高容量基础结构支持,但各采用不同的方式达到其最大限制。2 S3 and S3 HD are backed by identical high capacity infrastructure but each one reaches its maximum limit in different ways. S3 面向较小数目的非常大的索引。S3 targets a smaller number of very large indexes. 在这种情况下,其最大限制是资源限制型(每个服务 2.4 TB)。As such, its maximum limit is resource-bound (2.4 TB for each service). S3 HD 面向较大数目的非常小的索引。S3 HD targets a large number of very small indexes. 在 1,000 个索引的情况下,S3 HD 达到其索引约束形式的限制。At 1,000 indexes, S3 HD reaches its limits in the form of index constraints. 如果 S3 HD 客户需要超过 1,000 个索引,请联系 Microsoft 支持,了解有关如何继续的信息。If you are an S3 HD customer who requires more than 1,000 indexes, contact Microsoft Support for information on how to proceed.

消除不满足要求的 SKUEliminate SKUs that don't meet requirements

以下问题有助于根据工作负荷做出正确的 SKU 决策。The following questions can help you arrive at the right SKU decision for your workload.

  1. 是否有服务级别协议 (SLA) 要求?Do you have Service Level Agreement (SLA) requirements? 可以使用任何计费层(基本以上),但必须为冗余配置服务。You can use any billable tier (Basic on up), but you must configure your service for redundancy. 查询(读取)SLA 需要两个或多个副本。Two or more replicas are required for query (read) SLA. 查询和索引(读-写)SLA 需要不少于三个副本。Three or more replicas are required for query and indexing (read-write) SLA. 分区数不属于 SLA 相关考虑因素。The number of partitions is not an SLA consideration.
  2. 需要多少索引How many indexes do you require? 其中一个纳入 SKU 决策的最大变量是每个 SKU 支持的索引数。One of the biggest variables factoring into a SKU decision is the number of indexes supported by each SKU. 索引支持在较低的定价层明显属于不同级别。Index support is at markedly different levels in the lower pricing tiers. 索引数方面的要求可能是 SKU 决策的主要决定因素。Requirements on number of indexes could be a primary determinant of a SKU decision.
  3. 有多少个文档将加载到每个索引?How many documents will be loaded into each index? 文档的数量和大小将确定索引的最终大小。The number and size of documents will determine the eventual size of the index. 假设可估算预计的索引大小,则可以将该数字与每个 SKU 的分区大小进行比较,并根据存储该索引大小所需的分区数进行扩展。Assuming you can estimate the projected size of the index, you can compare that number against the partition size per SKU, extended by the number of partitions required to store an index of that size.
  4. 什么是预期的查询负载What is the expected query load? 了解存储要求后,请考虑查询工作负荷。Once storage requirements are understood, consider query workloads. S2 和两个 S3 SKU 提供几乎相等的吞吐量,但 SLA 要求会排除任何预览 SKU。S2 and both S3 SKUs offer near-equivalent throughput, but SLA requirements will rule out any preview SKUs.
  5. 如果正在考虑 S2 或 S3 层,请确定是否需要索引器If you are considering the S2 or S3 tier, determine whether you require indexers. 索引器在 S3 HD 层上还不能使用。Indexers are not yet available for the S3 HD tier. 另一种方法是对索引更新使用推送模型,在该模型中编写应用程序代码以将数据集推送到索引。Alternative approach is to use a push model for index updates, where you write application code to push a data set to an index.

大多数客户可以根据对四个问题的答案来纳入或排除特定的 SKU。Most customers can rule a specific SKU in or out based on their answers to the above questions. 如果仍然不确定要使用哪一个 SKU,可以将问题发布到 MSDN 或 StackOverflow 论坛,也可以联系 Azure 支持以寻求进一步的指导。If you still aren't sure which SKU to go with, you can post questions to MSDN or StackOverflow forums, or contact Azure Support for further guidance.

决策验证:SKU 是否提供足够的存储和 QPS?Decision validation: does the SKU offer sufficient storage and QPS?

最后一步是重新访问定价页服务限制中的每个服务和每个索引部分,仔细检查对订阅帐户与服务限制的估计。As a last step, revisit the pricing page and the per-service and per-index sections in Service Limits to double-check your estimates against subscription and service limits.

如果价格或存储要求超出界限,用户可能希望对多个较小服务之间的工作负荷进行重构(举例来说)。If either the price or storage requirements are out of bounds, you might want to refactor the workloads among multiple smaller services (for example). 在更细微的级别上,可以将索引重新设计为更小,或使用筛选器让查询更有效。On more granular level, you could redesign indexes to be smaller, or use filters to make queries more efficient.

备注

如果文档包含无关数据,存储要求可能会过高。Storage requirements can be over-inflated if documents contain extraneous data. 在理想情况下,文档仅包含可搜索的数据或元数据。Ideally, documents contain only searchable data or metadata. 二进制数据不可搜索,应该分开存储(或许存储在 Azure 表或 blob 存储中),并且在索引中要有一个字段用于保存外部数据的 URL 参考。Binary data is non-searchable and should be stored separately (perhaps in an Azure table or blob storage) with a field in the index to hold a URL reference to the external data. 个别文档的最大大小是 16 MB(如果在一次请求中批量上传了多个文档,则小于 16 MB)。The maximum size of an individual document is 16 MB (or less if you are bulk uploading multiple documents in one request). 有关详细信息,请参阅 Azure 搜索中的服务限制See Service limits in Azure Search for more information.

后续步骤Next step

在了解哪些 SKU 最适合后,请继续执行以下步骤:Once you know which SKU is the right fit, continue on with these steps: