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

选择 Azure 搜索的定价层Choose a 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. 它用于补充定价页服务限制页,包含与各层级相关的计费概念和消费模式的摘要。It supplements the pricing page and Service Limits page with a digest of billing concepts and consumption patterns associated with various tiers. 它还建议采用迭代方法来了解哪个层能更好地满足你的需求。It also recommends an iterative approach for understanding which tier best meets your needs.

层级决定容量,而不是功能。Tiers determine capacity, not features. 如果层级容量经证实过低,将需要在更高的层级上预配新服务,然后重新加载索引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.

功能可用性不是主要的层级考虑因素。Feature availability is not a primary tier consideration. 所有层级(包括“免费”层)都提供功能奇偶一致性,除了 S3HD 的索引器支持。All tiers, including the Free tier, offer feature parity, with the exception of indexer support for S3HD. 但是,索引和资源约束可以有效地限制功能的使用范围。However, indexing and resource constraints effectively can limit the extent of feature usage. 例如,认知搜索索引具有长期运行的特性,除非数据集很小,否则会在免费服务中超时。For example, cognitive search indexing has long-running skills that time out on a free service unless the data set happens to be very small.

提示

大多数客户从“免费”层开始进行评估,然后升级到“标准”层进行开发。Most customers start with the Free tier for evaluation and then graduate to Standard for development. 选择层级并预配搜索服务后,可以增加副本和分区计数以进行性能调整。After you choose a tier and provision a search service, you can increase replica and partition counts for performance tuning. 有关何时以及为何调整容量的更多信息,请参阅性能和优化注意事项For more information about when and why you would adjust capacity, see Performance and optimization considerations.

计费概念Billing concepts

选择层级时需要了解的概念包括容量定义、服务限制和服务单位。Concepts you need to understand for tier selection include capacity definitions, service limits, and service units.

CapacityCapacity

容量的结构为副本和分区。Capacity is structured as replicas and partitions. 副本是搜索服务的实例,每个副本托管一个索引的一个负载均衡副本。Replicas are instances of the search service, where each replica hosts one load-balanced copy of an index. 例如,包含 6 个副本的服务具有加载到服务中的每个索引的 6 个副本。For example, a service with 6 replicas has 6 copies of every index loaded in the service. 分区存储索引并自动拆分可搜索的数据:两个分区将索引分成两部分,三个分区分成三部分,以此类推。Partitions store indexes and automatically split searchable data: two partitions split your index in half, three partitions into thirds, and so forth. 在容量方面,分区大小是各层级的主要区别特征。In terms of capacity, partition size is the primary differentiating feature across tiers.

备注

所有“标准”层都支持灵活组合副本和分区,用户可通过改变均衡来增加系统的速度或存储空间All Standard tiers support flexible combinations replica and partitions so that you can weight your system for speed or storage by changing the balance. “基本”层提供三个具有高可用性但只有分区的副本。Basic offers up three replicas for high availability but has only partition. “免费”层不提供专用资源:计算资源由多个免费服务共享。Free tiers do not provide dedicated resources: computing resources are shared by multiple free services.

限制Limits

服务托管资源,如索引、索引器等。Services host resources, such as indexes, indexers, and so forth. 每个层级都会对可以创建的资源数量施加服务限制Each tier imposes service limits on the quantity of resources you can create. 因此,索引数量(以及其他对象)的上限是各层级的第二个区别特征。As such, a cap on the number of indexes (and other objects) is the second differentiating feature across tiers. 在门户中查看每个选项时,请注意索引数量的限制。As you review each option in the portal, note the limits on number of indexes. 其他资源(如索引器、数据源和技能集)受索引限制约束。Other resources, such as indexers, data sources, and skillsets, are pegged to index limits.

搜索单位Search units

要了解的重要计费概念是搜索单位 (SU),即 Azure 搜索的计费单位。The most important billing concept to understand is a search unit (SU), which is the billing unit for Azure Search. 由于 Azure 搜索依赖于副本和分区来运行,因此按其中一个或另一个来计费都是没有意义的。Because Azure Search depends on both replicas and partitions to function, it doesn't make sense to bill by one or the other. 相反,应基于两者的组合来计费。Instead, billing is based on a composite of both. 如果用公式表示,SU 是服务使用的副本和分区的乘积:(R X P = SU)。Formulaically, an SU is the product of replica and partitions used by a service: (R X P = SU). 每个服务至少从 1 个 SU 开始(一个副本乘以一个分区),但更现实可行的模型可能是 3 个副本和 3 个分区的服务,按 9 个 SU 计费。At a minimum, every service starts with 1 SU (one replica multiplied by one partition), but a more realistic model might be a 3-replica, 3-partition service billed as 9 SUs.

尽管每个层级提供的容量越来越大,但你可以将总容量的一部分联机,其余部分储备待用。Although each tier offers progressively higher capacity, you can bring a portion of total capacity online, holding the rest in reserve. 在计费方面,实际支付的费用取决于联机的分区和副本数量(使用 SU 公式计算)。In terms of billing, it's the number of partitions and replicas that you bring online, calculated using the SU formula, that determines what you actually pay.

每个 SU 的计费率是每小时一次,每个层级的计费率各不相同。Billing rate is hourly per SU, with each tier having a different rate. 有关每层的费率,请参阅 Pricing Details(定价详细信息)。Rates for each tier can be found on Pricing Details.

消费模式Consumption patterns

大多数客户从“免费”服务开始,并无限期保留,然后选择其中一个“标准”层用于重大开发或生产工作负载。Most customers start with the Free service, which they keep indefinitely, and then choose one of the Standard tiers for serious development or production workloads.

Azure 搜索层Azure search tiers

在任意一端,“基本”和“S3 HD”都存在重要但非典型的消费模式。On either end, Basic and S3 HD exist for important but atypical consumption patterns. “基本”适用于小型生产工作负载:它提供 SLA、专用资源、高可用性以及适度的存储(总计 2 GB)。Basic is for small production workloads: it offers SLA, dedicated resources, high availability, but modest storage, topping out at 2 GB total. 此层级专为持续使用可用容量的客户设计。This tier was engineered for customers who consistently under utilized available capacity. 在远端,“S3 HD”适用于 ISV、合作伙伴、多租户解决方案或要求大量小型索引的任何配置的典型工作负载。At the far end, S3 HD is for workloads typical of ISVs, partners, multitenant solutions, or any configuration calling for a large number of small indexes. 显然,“基本”或“S3 HD”层通常就很合适,但如果需要确认,可以发布到 StackOverflow联系 Azure 支持以获取更多指导。It's often self-evident when Basic or S3 HD tier is the right fit, but if you want confirmation you can post to StackOverflow or contact Azure Support for further guidance.

将焦点转移到更常用的“标准”层上,“S1-S3”级别的容量不断增加,分区大小有转折点,并且索引、索引器和推论资源数量达到最大值:Shifting focus to the more commonly used standard tiers, S1-S3 are a progression of increasing levels of capacity, with inflection points on partition size and maximums on numbers of indexes, indexers, and corollary resources:

S1S1 S2S2 S3S3
分区大小partition size 25 GB25 GB 100 GB100 GB 250 GB250 GB
索引和索引器限制index and indexer limits 5050 200200 200200

当需要专用资源和多个分区时,通常选择“S1”。S1 is a common choice when dedicated resources and multiple partitions become a necessity. 假设共有 12 个分区,每个分区 25 GB,如果通过副本最大化分区,则“S1”上每项服务的限制总计为 300 GB(请参阅分配分区和副本以获得更多均衡组合)。With partitions of 25 GB for up to 12 partitions, the per-service limit on S1 is 300 GB total if you maximize partitions over replicas (see Allocate partitions and replicas for more balanced compositions.)

门户和定价页将重点放在分区大小和存储上,但对于每个层级,所有计算能力(磁盘容量、速度、CPU)随着价格呈线性增长。Portal and pricing pages put the focus on partition size and storage, but for each tier, all compute capabilities (disk capacity, speed, CPUs) grow linearly with price. “S2”副本快于“S1”,“S3”快于“S2”。An S2 replica is faster than S1, and S3 is faster than S2. “S3”层以非常快的 I/O 速度打破了一般的线性计算定价模式。S3 tiers break the generally linear compute-pricing pattern with disproportionately faster I/O. 如果预计 I/O 会成为瓶颈,那么“S3”会为你提供比更低层级更多的 IOPS。If you anticipate I/O as the bottleneck, an S3 gives you much more IOPS than lower tiers.

“S3”和“S3 HD”受相同高容量基础结构支持,但各采用不同的方式达到其最大限制。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.

备注

以前,文档限制是一个考虑因素,但它将不再适用于 2018 年 1 月以后提供的大多数 Azure 搜索服务。Previously, document limits were a consideration but are no longer applicable for most Azure Search services provisioned after January 2018. 有关文档限制仍适用的条件的详细信息,请参阅服务限制:文档限制For more information about conditions for which document limits still apply, see Service limits: document limits.

评估容量Evaluate capacity

容量与运行服务的成本密切相关。Capacity and costs of running the service go hand-in-hand. 各层级在两个级别(存储和资源)施加限制,应同时考虑两个级别,因为无论先达到哪个级别的限制都是有效的限制。Tiers impose limits on two levels (storage and resources), so you should think about both because whichever one you reach first is the effective limit.

业务需求通常决定需要的索引数。Business requirements typically dictate the number of indexes you will need. 例如,针对大型文档存储库的全局索引,或者基于区域、应用程序或业务利基的多个索引。For example, a global index for a large repository of documents, or perhaps multiple indexes based on region, application, or business niche.

若要确定索引大小,必须生成一个索引To determine the size of an index, you have to build one. Azure 搜索中的数据结构主要是倒排索引,它具有与源数据不同的特征。The data structure in Azure Search is primarily an inverted index, which has different characteristics than source data. 对于倒排索引,大小和复杂度由内容决定,不一定是输入的数据量。For an inverted index, size and complexity are determined by content, not necessarily the amount of data you feed into it. 具有大量冗余的大型数据源可能会导致比包含高度可变内容的较小数据集更小的索引。A large data source with massive redundancy could result in a smaller index than a smaller dataset containing highly variable content. 在这种情况下,很难根据原始数据集的大小来推断索引大小。As such, it's rarely possible to infer index size based on the size of the original data set.

使用“免费”层进行初步估计Preliminary estimates using the Free tier

估计容量的一种方法是从“免费”层开始。One approach for estimating capacity is to start with the Free tier. 回想一下,“免费”服务最多提供 3 个索引、50 MB 存储和 2 分钟索引时间。Recall that the Free service offers up to 3 indexes, 50 MB of storage, and 2 minutes of indexing time. 使用这些约束来估计预计的索引大小可能具有挑战性,但以下示例介绍了一种方法:It can be challenging to estimate a projected index size with these constraints, but the following example illustrates an approach:

假设示例既具有代表性,又占整个数据源的 10%,如果所有文档都编入索引,则 30 MB 索引将变为大约 300 MB。Assuming the sample was both representative and ten percent of the entire data source, a 30 MB index becomes approximately 300 MB if all documents are indexed. 有了此初始数量,你可以将此数额增加一倍到两个索引(开发和生产)的预算,总共 600MB 的存储需求。Armed with this preliminary number, you might double that amount to budget for two indexes (development and production), for a total of 600 MB in storage requirements. “基本”层可以轻松满足此需求,因此你将从“基本”层开始。This is easily satisfied by the Basic tier, so you would start there.

使用可计费层进行高级估计Advanced estimates using a billable tier

有些客户更喜欢从可以适应更大采样和处理时间的专用资源开始,然后在开发期间对索引数量、大小和查询量进行现实估计。Some customers prefer to start with dedicated resources that can accommodate larger sampling and processing times, and then develop realistic estimates of index quantity, size, and query volumes during development. 最初,服务是根据最佳预计提供的,然后随着开发项目的成熟,团队通常会知道现有服务是否超出或低于预计的生产工作负载的容量。Initially, a service is provisioned based on a best-guess estimate, and then as the development project matures, teams usually know whether the existing service is over or under capacity for projected production workloads.

  1. 检查每个层级的服务限制以确定较低层级是否可以支持需要的索引数量。Review service limits at each tier to determine whether lower tiers can support the quantity of indexes you need. 在“基本”-“S1”- “S2”层级中,索引限制分别为 15-50-200。Across the Basic-S1- S2 tiers, index limits are 15-50-200, respectively.

  2. 在可计费层中创建服务Create a service at a billable tier:

    • 起点低,如果你处于学习曲线的开始位置,请从“基本”或“S1”开始。Start low, on Basic or S1 if you are at the beginning of your learning curve.
    • 起点高,如果需要大规模索引和查询负载,请从“S2”甚至“S3”开始。Start high, at S2 or even S3, if large-scale indexing and query loads are self-evident.
  3. 生成初始索引以确定将源数据转换为索引的方式。Build an initial index to determine how source data translates to an index. 这是估计索引大小的唯一方法。This is the only way to estimate index size.

  4. 在门户中监视存储、服务限制、查询量和延迟Monitor storage, service limits, query volume, and latency in the portal. 门户向你显示每秒查询、受限查询和搜索延迟;所有这些内容都有助于决定你是否处于正确的层级。The portal shows you queries per second, throttled queries, and search latency; all of which can help you decide if you are at the right tier. 除门户指标外,你还可以通过启用搜索流量分析来配置深层监视,例如点击链接分析。Aside from portal metrics, you can configure deep monitoring, such as clickthrough analysis, by enabling search traffic analytics.

索引数目和大小与分析同等相关,因为通过充分利用存储(分区)或通过最大化对资源(索引、索引器等)的限制来达到最大限制(以先发生者为准)。Index number and size are equally relevant to your analysis because maximum limits are reached through full utilization of storage (partitions) or by maximum limits on resources (indexes, indexers, and so forth), whichever comes first. 门户可帮助你跟踪两者,并在“概述”页面上并排显示当前使用情况和最大限制。The portal helps you keep track of both, showing current usage and maximum limits side by side on the Overview page.

备注

如果文档包含无关数据,存储要求可能会过高。Storage requirements can be over-inflated if documents contain extraneous data. 理想情况下,文档仅包含搜索体验所需的数据。Ideally, documents contain only the data you need for the search experience. 二进制数据不可搜索,应该分开存储(或许存储在 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 搜索中的服务限制提供详细信息。Service limits in Azure Search has more information.

查询量注意事项Query volume considerations

每秒查询数 (QPS) 是在性能调整过程中突出显示的一个指标,但通常不是层级考虑因素,除非你期望在一开始就有很高的查询量。Queries-per-second (QPS) is a metric that gains prominence during performance tuning, but is generally not a tier consideration unless you expect very high query volume at the outset.

所有标准层都可以实现副本与分区的均衡,通过额外的负载均衡副本和并行处理分区来支持更快的查询周转速度。All of the standard tiers can deliver a balance of replicas to partitions, supporting faster query turnaround through additional replicas for loading balancing and additional partitions for parallel processing. 你可以在预配服务后调整新能。You can tune for performance after the service is provisioned.

期待从一开始就拥有强大的持续查询量的客户,应该考虑由更强大的硬件支持的更高层级。Customer who expect strong sustained query volumes from the outset should consider higher tiers, backed by more powerful hardware. 如果无法实现这些查询量,你可以使分区和副本脱机,或者甚至切换到较低层级的服务。You can then take partitions and replicas offline, or even switch to a lower tier service, if those query volumes fail to materialize. 有关如何计算查询吞吐量的详细信息,请参阅 Azure 搜索性能和优化For more information on how to calculate query throughput, see Azure Search performance and optimization.

服务级别协议Service level agreements

“免费”层和预览功能不带服务级别协议 (SLA)The 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.

层级评估提示Tips for tier evaluation

  • 了解如何生成高效的索引,以及哪些刷新方法影响最小。Learn how to build efficient indexes, and which refresh methodologies are the least impactful. 建议搜索流量分析以获取有关查询活动的见解。We recommend search traffic analytics for the insights gained on query activity.

  • 允许围绕查询构建指标并收集有关使用模式的数据(在营业时间进行查询,在非高峰时段进行索引),并使用这些数据来通知将来的服务预配决策。Allow metrics to build around queries and collect data around usage patterns (queries during business hours, indexing during off-peak hours), and use this data to inform future service provisioning decisions. 虽然无法每小时或每天收集数据,但可以动态调整分区和资源,以适应计划的查询量更改,或者无计划的但持续更改(如果级别维持足够长以保证执行操作)。While not practical at an hourly or daily level, you can dynamically adjust partitions and resources to accommodate planned changes in query volumes, or unplanned but sustained changes if levels hold long enough to warrant taking action.

  • 请记住,预配不足的唯一缺点是,如果实际需求超出预期,则可能必须关闭某项服务。Remember that the only downside of under-provisioning is that you might have to tear down a service if actual requirements are greater than you estimated. 为避免服务中断,可以在更高层级的相同订阅中创建新服务,并将其并行运行,直到所有应用和请求都指向新的终结点。To avoid service disruption, you would create a new service in the same subscription at a higher tier and run it side by side until all apps and requests target the new endpoint.

后续步骤Next steps

从“免费”层开始,使用数据子集生成初始索引以了解其特征。Start with a Free tier and build an initial index using a subset of your data to understand its characteristics. Azure 搜索中的数据结构是倒排索引,其大小和复杂度由内容决定。The data structure in Azure Search is an inverted index, where size and complexity of an inverted index is determined by content. 请记住,高度冗余的内容往往会导致比高度不规则的内容更小的索引。Remember that highly redundant content tends to result in a smaller index than highly irregular content. 在这种情况下,确定索引存储要求的是它的内容特征而不是数据集的大小。As such, it's content characteristics rather than the size of the data set that determines index storage requirements.

一旦初步了解索引大小,就可以在本文中讨论的一个层级(“基本”层或“标准”层)提供可计费服务Once you have an initial idea of index size, provision a billable service at one of the tiers discussed in this article, either Basic or a Standard tier. 放宽对数据子集的任何人为约束,并重建索引以包含实际希望可搜索的所有数据。Relax any artificial constraints on data subsets and rebuild your index to include all of the data you actually want to be searchable.

根据需要分配分区和副本以获取所需性能和规模。Allocate partitions and replicas as needed to get the performance and scale you require.

如果性能和容量都合适,那么你已完成操作。If performance and capacity are fine, you are done. 否则,请在与你的需求更接近的不同层级上重新创建搜索服务。Otherwise, re-create a search service at a different tier that more closely aligns with your needs.

备注

有关你的问题的更多帮助,请发布到 StackOverflow联系 Azure 支持For more help with your questions, post to StackOverflow or contact Azure Support.