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

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

创建 Azure 搜索服务时, 会在服务生存期固定的定价层 (或 SKU) 上创建资源When you create an Azure Search service, a resource is created at a pricing tier (or SKU) that's fixed for the lifetime of the service. 层包括“免费”、“基本”、“标准”和“存储优化”。Tiers include Free, Basic, Standard, and Storage Optimized. “标准”和“存储优化”提供多种配置和容量。Standard and Storage Optimized are available with several configurations and capacities.

大多数客户从“免费”层着手,以便能够评估该服务。Most customers start with the Free tier so they can evaluate the service. 评估后, 在开发和生产部署的更高级别中创建第二个服务是很常见的。Post-evaluation, it's common to create a second service at one of the higher tiers for development and production deployments.

尽管所有层(包括“免费”层)通常会提供功能奇偶一致性,但较大的工作负荷可以要求使用较高的层。Although all tiers, including the Free tier, generally offer feature parity, larger workloads can dictate a need for higher tiers. 例如,使用认知服务的 AI 扩充具有长时间运行的技能, 在免费服务的情况下超时, 除非数据集很小。For example, AI enrichment with Cognitive Services has long-running skills that time out on a free service unless the dataset is small.


功能奇偶一致性的例外情况是索引器,它们不可用于 S3 HD。The exception to feature parity is indexers, which are not available on S3 HD.

可用层Available tiers

层反映托管服务(而不是功能)的硬件的特征,并按以下标准进行区分:Tiers reflect the characteristics of the hardware hosting the service (rather than features) and are differentiated by:

  • 可以创建的索引和索引器数量Quantity of indexes and indexers you can create
  • 分区(物理存储)的大小和速度Size and speed of partitions (physical storage)

您选择的层决定了计费费率。The tier you select determines the billable rate. Azure 门户中的以下屏幕截图显示可用层, 而不是定价 (可在门户中找到, 也可以在定价页上找到)。The following screenshot from Azure portal shows the available tiers, minus pricing (which you can find in the portal and on the pricing page. "免费"、"基本" 和 "标准" 是最常用的层。Free, Basic, and Standard are the most common tiers.

免费在群集上创建受限的搜索服务, 与其他订阅者共享。Free creates a limited search service on a cluster, shared with other subscribers. 你可以完成小型项目, 包括快速入门和教程, 但无法缩放服务或运行大量工作负荷。You can complete small projects, including quickstarts and tutorials, but you cannot scale the service or run significant workloads. "基本" 和 "标准" 是最常用的可计费层, 默认值为 "标准"。Basic and Standard are the most commonly used billable tiers, with Standard being the default.

Azure 搜索定价层Pricing tiers of Azure Search

某些层针对某些类型的工作进行了优化。Some tiers are optimized for certain types of work. 例如,标准3高密度 (S3 HD) 是 S3 的托管模式, 其中基础硬件针对大量的小型索引进行了优化, 适用于多租户方案。For example, Standard 3 High Density (S3 HD) is a hosting mode for S3, where the underlying hardware is optimized for a large number of smaller indexes and is intended for multitenancy scenarios. S3 HD 的每单位费用与 S3 相同,但硬件经过优化,可基于大量的小型索引快速读取文件。S3 HD has the same per-unit charge as S3, but the hardware is optimized for fast file reads on a large number of smaller indexes.

存储优化层提供更大的存储容量, 其价格低于每 TB 标准级别。Storage Optimized tiers offer larger storage capacity at a lower price per TB than the Standard tiers. 主要弊端是查询延迟更高,应根据具体的应用程序要求确认这种延迟。The primary tradeoff is higher query latency, which you should validate for your specific application requirements. 若要详细了解此层的性能注意事项,请参阅性能和优化注意事项To learn more about the performance considerations of this tier, see Performance and optimization considerations.

预配服务时,可以在定价页Azure 搜索中的服务限制以及门户页上找到有关各个层的详细信息。You can find out more about the various tiers on the pricing page, in the Service limits in Azure Search article, and on the portal page when you're provisioning a service.

计费事件Billable events

基于 Azure 搜索构建的解决方案可能会按以下方式产生成本:A solution built on Azure Search can incur costs in the following ways:

  • 最小配置的服务基本成本Base cost of service at minimal configuration
  • 增加时增加成本 (添加副本或分区)Incremental cost when scaling up (adding replicas or partitions)
  • 出站数据传输的带宽费用Bandwidth charges for outbound data transfer
  • 利用认知服务资源的认知搜索Cognitive search leveraging Cognitive Services resources

服务成本Service costs

与可以 "暂停" 以避免收费的虚拟机或其他资源不同, Azure 搜索服务在专用于专用的硬件上始终可用。Unlike virtual machines or other resources that can be "paused" to avoid charges, an Azure Search service is always available on hardware dedicated for your exclusive use. 因此, 创建服务是一种可计费事件, 该事件在你创建服务时开始, 在你删除服务时结束。As such, creating a service is a billable event that starts when you create the service, and ends when you delete the service.

最小费用是第一个搜索单位 (1 个副本 x 个分区)。The minimum charge is the first search unit (one replica x one partition). 在服务的整个生命周期内,此最低费用都是固定的,因为服务不能在低于此配置的组件上运行。This minimum is fixed for the lifetime of the service because the service can't run on anything less than this configuration. 除了最小值以外, 还可以单独添加副本和分区。Beyond the minimum, you can add replicas and partitions independently of each other. 通过副本和分区增加容量增加时, 会根据以下公式增加帐单: (副本 x 分区 x 速率), 根据所选的定价层, 你需要支付的费用取决于所选的定价层。Incremental increases in capacity through replicas and partitions will increase your bill based on the following formula: (replicas x partitions x rate), where the rate you're charged depends on the pricing tier you select.

在估算搜索解决方案的费用时,请记住,定价和容量不是线性的。When you're estimating the cost of a search solution, keep in mind that pricing and capacity aren't linear. (容量翻倍不是支付两倍的费用,而是要支付更高的费用)有关该公式的工作方式示例,请参阅如何分配副本和分区(Doubling capacity more than doubles the cost.) For an example of how of the formula works, see How to allocate replicas and partitions.

带宽费用Bandwidth charges

使用 Azure 搜索索引器可能会影响计费,具体取决于服务的位置。Using Azure Search indexers might affect billing, depending on the location of your services. 如果在数据所在的同一区域中创建 Azure 搜索服务,则可以完全消除数据流出费用。You can eliminate data egress charges entirely if you create the Azure Search service in the same region as your data. 下面是带宽定价页中的一些信息:Here's some information from the bandwidth pricing page:

  • Microsoft 不会向 Azure 上的任何服务或来自 Azure 搜索的任何出站数据收费。Microsoft doesn't charge for any inbound data to any service on Azure, or for any outbound data from Azure Search.
  • 在 multiservice 解决方案中, 如果所有服务都位于同一区域, 则不会对跨网络数据进行收费。In multiservice solutions, there's no charge for data crossing the wire when all services are in the same region.

如果服务在不同的区域中,则会针对出站数据收费。Charges do apply for outbound data if services are in different regions. 这些费用实际上不是 Azure 搜索帐单的一部分。These charges aren't actually part of your Azure Search bill. 此处之所以提到这些费用,是因为如果你使用数据或 AI 扩充索引器从不同的区域提取数据,将会在总体帐单中看到这些费用。They're mentioned here because if you're using data or AI-enriched indexers to pull data from different regions, you'll see costs reflected in your overall bill.

认知搜索 AI 扩充与认知服务Cognitive search AI enrichment with Cognitive Services

对于与认知服务的 AI 扩充, 应计划将可计费的 azure 认知服务资源附加到在 Azure 搜索所在的同一区域中, 以实现即用即付处理。For AI enrichment with Cognitive Services, you should plan to attach a billable Azure Cognitive Services resource, in the same region as Azure Search, at the S0 pricing tier for pay-as-you-go processing. 附加认知服务不会产生固定的费用。There's no fixed cost associated with attaching Cognitive Services. 只需支付所需的处理费。You pay only for the processing you need.

操作Operation 计费影响Billing impact
文档破解, 文本提取Document cracking, text extraction 免费Free
文档破解, 图像提取Document cracking, image extraction 根据从文档中提取的图像数量进行计费。Billed according to the number of images extracted from your documents. 索引器配置中,imageAction 是触发图像提取的参数。In an indexer configuration, imageAction is the parameter that triggers image extraction. 如果 imageAction 设置为“none”(默认值),则不收取图像提取费用。If imageAction is set to "none" (the default), you won't be charged for image extraction. Azure 搜索的 "定价详细信息" 页上介绍了图像提取速率。The rate for image extraction is documented on the pricing details page for Azure Search.
预先构建认知技能Pre-built cognitive skills 按照与你使用认知服务直接执行任务相同的费率进行计费。Billed at the same rate as if you had performed the task by using Cognitive Services directly.
自定义技能Custom skills 自定义技能是您提供的功能。A custom skill is functionality you provide. 使用自定义技术的成本完全取决于自定义代码是否调用其他计量服务。The cost of using a custom skill depends entirely on whether custom code is calling other metered services.

计费公式 (R x P = SU)Billing formula (R x P = SU)

对于 Azure 搜索操作,要了解的最重要计费概念是搜索单位 (SU)。The most important billing concept to understand for Azure Search operations is the search unit (SU). 由于 Azure 搜索必须同时使用副本和分区进行索引编制和查询,因此无法按其中的一个进行计费。Because Azure Search depends on both replicas and partitions for indexing and queries, it doesn't make sense to bill by just one or the other. 相反,应基于两者的组合来计费。Instead, billing is based on a composite of both.

SU 是服务使用的副本数和分区数的乘积: (R x P = SU)SU is the product of the replicas and partitions used by a service: (R x P = SU).

每个服务至少从 1 个 SU(1 个分区乘以 1 个副本)开始。Every service starts with one SU (one replica multiplied by one partition) as the minimum. 任何服务的最大 SU 值为 36。The maximum for any service is 36 SUs. 可通过多种方式来实现此最大值:例如,6 个分区 x 6 个副本,或 3 个分区 x 12 个副本。This maximum can be reached in multiple ways: 6 partitions x 6 replicas, or 3 partitions x 12 replicas, for example. 通常使用小于总容量的值(例如,3 副本、3 分区的服务按 9 个 SU 计费)。It's common to use less than total capacity (for example, a 3-replica, 3-partition service billed as 9 SUs). 有关有效的组合,请参阅分区和副本组合图表。See the Partition and replica combinations chart for valid combinations.

费率按每个 SU、按小时计算。The billing rate is hourly per SU. 每个层的费率渐进式提高。Each tier has a progressively higher rate. 层越高,分区越大且速度越快,因此,每小时的总费率更高。Higher tiers come with larger and speedier partitions, and this contributes to an overall higher hourly rate for that tier. 可以在定价详细信息页上查看每个层的费率。You can view the rates for each tier on the pricing details page.

大多数客户只是联机使用一部分总容量,将剩余的容器保持预留状态。Most customers bring just a portion of total capacity online, holding the rest in reserve. 在计费方面,支付的每小时费用取决于联机的分区和副本数量(使用 SU 公式计算)。For billing, the number of partitions and replicas that you bring online, calculated by the SU formula, determines what you pay on an hourly basis.

如何管理和降低成本How to manage and reduce costs

除了以下建议, 请访问计费和成本管理In addition to the following suggestions, visit Billing and cost management.

  • 在同一区域中创建所有资源, 或在尽可能少的区域中创建所有资源, 以最大程度地减少或消除带宽费用。Create all resources in the same region, or in as few regions as possible, to minimize or eliminate bandwidth charges.

  • 将所有服务合并为一个资源组, 例如 Azure 搜索、认知服务和解决方案中使用的任何其他 Azure 服务。Consolidate all services into one resource group, such as Azure Search, Cognitive Services, and any other Azure services used in your solution. 在 Azure 门户中, 找到资源组, 并使用成本管理命令了解实际和预计支出。In the Azure portal, find the resource group and use the Cost Management commands for insight into actual and projected spending.

  • 考虑将 Azure Web 应用用于前端应用程序, 以便请求和响应保留在数据中心边界内。Consider Azure Web App for your front-end application so that requests and responses stay within the data center boundary.

  • 增加资源密集型操作 (如索引), 然后对常规查询工作负荷进行调整。Scale up for resource-intensive operations like indexing, and then readjust downwards for regular query workloads. 首先使用 Azure 搜索的最低配置 (一个 SU 由一个分区和一个副本), 然后监视用户活动以确定使用模式, 这些模式将指示需要更多的容量。Start with the minimum configuration for Azure Search (one SU composed of one partition and one replica), and then monitor user activity to identify usage patterns that would indicate a need for more capacity. 如果有可预测的模式, 则可以将缩放与活动同步 (需要编写代码来自动执行此操作)。If there is a predictable pattern, you might be able to synchronize scale with activity (you would need to write code to automate this).

不能关闭搜索服务来减少帐单。You can't shut down a search service to reduce your bill. 专用资源始终运行,是在服务的生存期内专门分配给你使用的。Dedicated resources are always operational, allocated for your exclusive use for the lifetime of your service. 就服务本身而言, 降低帐单的唯一方法是将副本和分区减少到仍能提供可接受的性能和SLA 符合性的级别, 或在较低层创建服务 (S1 小时费率低于 S2 或 S3 速率)。In terms of the service itself, the only way to lower your bill is to reduce replicas and partitions to a level that still provides acceptable performance and SLA compliance, or create a service at a lower tier (S1 hourly rates are lower than S2 or S3 rates). 假设你预配了一个面向低端负载预测的服务。若要扩充该服务,可以创建另一个具有较大层的服务,在该服务上重建索引,然后删除第一个服务。Assuming you provision your service at the lower end of your load projections, if you outgrow the service, you can create a second larger-tiered service, rebuild your indexes on the second service, and then delete the first one.

如何评估容量需求How to evaluate capacity requirements

在 Azure 搜索中,容量的结构包括副本和分区。In Azure Search, capacity is structured as replicas and partitions.

  • 副本是搜索服务的实例。Replicas are instances of the search service. 每个副本托管索引的一个负载均衡副本。Each replica hosts one load-balanced copy of an index. 例如,包含 6 个副本的服务具有加载到服务中的每个索引的 6 个副本。For example, a service with six replicas has six 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 split it into thirds, and so on. 在容量方面,分区大小是各层级的主要区别特征。In terms of capacity, partition size is the primary differentiating feature among tiers.


所有“标准”和“存储优化”层都支持副本和分区的灵活组合,因此你可以通过改变平衡方式来优化系统以提高速度或存储All Standard and Storage Optimized tiers support flexible combinations of replicas and partitions so you can optimize your system for speed or storage by changing the balance. “基本”层最多提供三个副本来实现高可用性,但只有一个分区。The Basic tier offers up to three replicas for high availability but has only one partition. “免费”层不提供专用资源:计算资源由多个订阅者共享。Free tiers don't provide dedicated resources: computing resources are shared by multiple subscribers.

评估容量Evaluating capacity

容量与服务运行费用直接相关。Capacity and the costs of running the service are directly related. 层在两个级别施加限制:存储和资源。Tiers impose limits on two levels: storage and resources. 应该同时考虑到此两者,因为首先达到的限制就是实施的限制。You should think about both because whichever limit you reach first is the effective limit.

业务需求通常决定了所需的索引数。Business requirements typically dictate the number of indexes you'll need. 例如,你可能需要对一个较大的文档存储库使用全局索引。For example, you might need a global index for a large repository of documents. 或者,你可能需要多个基于区域、应用或商业利基的索引。Or you might need 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 structure, which has different characteristics than source data. 对于倒排索引,大小和复杂度由内容决定,不一定是输入的数据量。For an inverted index, size and complexity are determined by content, not necessarily by the amount of data that you feed into it. 具有高度冗余的大型数据源可能会导致比包含高度可变内容的较小数据集更小的索引。A large data source with high redundancy could result in a smaller index than a smaller dataset that contains highly variable content. 因此,很难根据原始数据集的大小来推断索引大小。So it's rarely possible to infer index size based on the size of the original dataset.


即使估算将来的索引和存储需求类似于猜测,但也值得一试。Even though estimating future needs for indexes and storage can feel like guesswork, it's worth doing. 如果层级容量经证实过低,将需要在更高的层级上预配新服务,然后重新加载索引If a tier's capacity turns out to be too low, you'll need to provision a new service at a higher tier and then reload your indexes. 服务无法从一个 SKU 就地升级到另一个。There's no in-place upgrade of a service from one SKU to another.

步骤 1:使用“免费”层进行粗略估算Step 1: Develop rough estimates by using the Free tier

估算容量的一种方法是从“免费”层开始。One approach for estimating capacity is to start with the Free tier. 回想一下,“免费”服务最多提供 3 个索引、50 MB 存储和 2 分钟索引时间。Remember that the Free service offers up to three indexes, 50 MB of storage, and 2 minutes of indexing time. 根据这些约束估算预计索引大小可能很有难度。It can be challenging to estimate a projected index size with these constraints. 下面是可以采用的一种方法:Here's an approach that you can take:

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

步骤 2:使用可计费层进行改进的估算Step 2: Develop refined estimates by 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. 然后,随着开发项目的不断成熟,团队通常知道现有的服务对于预计生产工作负荷而言是容量超量还是不足。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 number of indexes you need. 在“基本”、“S1”和“S2”层中,索引数限制分别为 15、50 和 200。Across the Basic, S1, and S2 tiers, index limits are 15, 50, and 200, respectively. “存储优化”层的索引数限制为 10 个,因为它旨在支持少量的极大型索引。The Storage Optimized tier has a limit of 10 indexes because it's designed to support a low number of very large indexes.

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

    • 如果你处于学习曲线的开始位置,请从较低的“基本”或“S1”层着手。Start low, at Basic or S1, if you're at the beginning of your learning curve.
    • 如果你知道会出现较大的索引和查询负载,请从较高的“S2”甚至“S3”层着手。Start high, at S2 or even S3, if you know you're going to have large-scale indexing and query loads.
    • 如果你要为大量的数据编制索引并且查询负载相对较低(例如,使用与内部商务应用程序时),请从“优化存储”层 L1 或 L2 着手。Start with Storage Optimized, at L1 or L2, if you're indexing a large amount of data and query load is relatively low, as with an internal business application.
  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 these values can help you decide if you selected the right tier. 此外可以通过启用搜索流量分析,要配置对点击率分析等值的深度监视。You also can configure deep monitoring of values like clickthrough analysis by enabling search traffic analytics.

索引数量和大小对于分析而言同等重要。Index number and size are equally important to your analysis. 这是因为,需要通过充分利用存储(分区)或通过最大化对资源(索引、索引器等)的限制来达到最大限制(以先发生者为准)。This is 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 inflated if documents contain extraneous data. 理想情况下,文档仅包含搜索体验所需的数据。Ideally, documents contain only the data that you need for the search experience. 二进制数据不可搜索,因此应单独存储(也许可以存储在 Azure 表或 Blob 存储中)。Binary data isn't searchable and should be stored separately (maybe in an Azure table or blob storage). 然后在索引中添加一个字段,用于保存对外部数据的 URL 引用。A field should then be added 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're bulk uploading multiple documents in one request). 有关详细信息,请参阅 Azure 搜索中的服务限制For more information, see Service limits in Azure Search.

查询量注意事项Query volume considerations

每秒查询数 (QPS) 在性能优化期间是一个重要的指标,但如果你预期查询量一开始就很高,则通常只需考虑到层。Queries per second (QPS) is an important metric during performance tuning, but it's generally only a tier consideration if you expect high query volume at the outset.

“标准”层可以提供平衡的副本数和分区数。The Standard tiers can provide a balance of replicas and partitions. 可以添加副本来实现负载均衡,或添加分区进行并行处理,以此增大查询周转时间。You can increase query turnaround by adding replicas for load balancing or add partitions for parallel processing. 然后,可以在预配服务后优化性能。You can then tune for performance after the service is provisioned.

如果你预期持续查询量一开始就很高,应考虑更高的由更强大硬件支持的“标准”层。If you expect high sustained query volumes from the outset, you should consider higher Standard 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 don't occur. 有关如何计算查询吞吐量的详细信息,请参阅 Azure 搜索性能和优化For more information on how to calculate query throughput, see Azure Search performance and optimization.

“存储优化”层可用于大数据工作负荷,当查询延迟要求不太重要时,可以支持更大的总体可用索引存储。The Storage Optimized tiers are useful for large data workloads, supporting more overall available index storage for when query latency requirements are less important. 仍应使用更多的副本进行负载均衡,并使用更多的分区进行并行处理。You should still use additional replicas for load balancing and additional partitions for parallel processing. 然后,可以在预配服务后优化性能。You can then tune for performance after the service is provisioned.

服务级别协议Service-level agreements

免费层和预览功能不提供服务级别协议 (sla)The Free tier and preview features don't provide service-level agreements (SLAs). 对于所有可计费的层,SLA 将在用户为服务提供足够冗余时生效。For all billable tiers, SLAs take effect when you provision sufficient redundancy for your service. 查询 (读取) Sla 需要两个或多个副本。You need to have two or more replicas for query (read) SLAs. 需要有三个或更多的副本用于查询和索引 (读写) Sla。You need to have three or more replicas for query and indexing (read-write) SLAs. 分区数不会影响 Sla。The number of partitions doesn't affect SLAs.

层级评估提示Tips for tier evaluation

  • 了解如何生成高效的索引,并了解哪些刷新方法的影响最小。Learn how to build efficient indexes, and learn which refresh methods have the least impact. 使用搜索流量分析获取有关查询活动的见解。Use search traffic analytics to gain insights on query activity.

  • 允许围绕查询生成指标,并围绕使用模式收集数据(在营业期间执行查询,在非高峰期执行索引编制)。Allow metrics to build around queries, and collect data around usage patterns (queries during business hours, indexing during off-peak hours). 使用此数据做出明智的服务预配决策。Use this data to inform service provisioning decisions. 尽管这种做法不是在每小时或每日都可行,但可以动态调整分区和资源,以应对查询量的计划内变化。Though it's not practical at an hourly or daily cadence, you can dynamically adjust partitions and resources to accommodate planned changes in query volumes. 此外,还可以应对计划外的但持续性的变化,前提是变化程度持续足够长的时间,以致有必要采取措施。You can also accommodate unplanned but sustained changes if levels hold long enough to warrant taking action.

  • 请记住,预配不足的唯一缺点是,如果实际要求超出预测,则可能必须关闭某项服务。Remember that the only downside of underprovisioning is that you might have to tear down a service if actual requirements are greater than your predictions. 为避免服务中断,可以在更高层级的相同订阅中创建新服务,并将其并行运行,直到所有应用和请求都指向新的终结点。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 by using a subset of your data to understand its characteristics. Azure 搜索中的数据结构是一种倒排索引结构。The data structure in Azure Search is an inverted index structure. 倒排索引的大小和复杂性由内容决定。The 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. 因此,确定索引存储要求的是它的内容特征而不是数据集的大小。So content characteristics rather than the size of the dataset determine index storage requirements.

初始估算索引大小后,根据本文中所述的某个层预配可计费的服务:“基本”、“标准”或“存储优化”。After you have an initial estimate of your index size, provision a billable service on one of the tiers discussed in this article: Basic, Standard, or Storage Optimized. 放宽对数据大小的任何人为约束,并重建索引以包含可搜索的所有数据。Relax any artificial constraints on data sizing and rebuild your index to include all the data that you 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're done. 否则,请在与你的需求更接近的不同层级上重新创建搜索服务。Otherwise, re-create a search service at a different tier that more closely aligns with your needs.


如果有疑问, 请发布到StackOverflow联系 Azure 支持部门If you have questions, post to StackOverflow or contact Azure support.