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

创建 Azure 认知搜索服务时,资源是在某个定价层或 SKU 中创建的,该定价层或 SKU 在该服务的整个生存期内是固定的。When you create an Azure Cognitive 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.

按层划分的功能可用性Feature availability by tier

几乎每个功能都可在每个层(包括免费层)上使用,但如果不为其提供足够的容量,则资源密集型功能或工作流可能无法正常工作。Almost every feature is available on every tier, including Free, but a feature or workflow that is resource intensive might not work well unless you give it sufficient capacity. 例如,AI 扩充包含长时间运行的技能,除非数据集较小,否则这些技能在免费服务中会超时。For example, AI enrichment has long-running skills that time out on a free service unless the dataset is small.

下表描述了与层相关的功能约束。The following table describes tier-related feature constraints.

功能Feature 限制Limitations
索引器indexers 索引器在 S3 HD 上不可用。Indexers are not available on S3 HD.
客户托管的加密密钥Customer-managed encryption keys 在免费层上不可用。Not available on the Free tier.

层 (SKU)Tiers (SKUs)

可以通过以下方式区分层:Tiers 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 for smaller projects, including quickstarts and tutorials. 在内部,副本和分区可被多个订阅者共享。Internally, replicas and partitions are shared among multiple subscribers. 不能缩放免费服务,也不能运行繁重的工作负荷。You cannot scale a free service or run significant workloads.

“基本”和“标准”层是最常用的计费层,其中“标准”层是默认的层。 Basic and Standard are the most commonly used billable tiers, with Standard being the default. 控制专用资源后,你可以部署较大的项目,优化性能并设置容量。With dedicated resources under your control, you can deploy larger projects, optimize performance, and set the capacity.

Azure 认知搜索的定价层Pricing tiers of Azure Cognitive 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 Cognitive Search article, and on the portal page when you're provisioning a service.

计费事件Billable events

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

  • 在全天候运行且使用最低配置(一个分区和副本)的情况下,服务本身产生的固定成本Fixed cost of the service itself, running 24x7, at minimum configuration (one partition and replica)
  • 纵向扩展时的增量成本(添加副本或分区)Incremental cost when scaling up (add replicas or partitions)
  • 带宽费用(出站数据传输)Bandwidth charges (outbound data transfer)
  • 认知搜索(附加认知服务进行 AI 扩充,或者使用 Azure 存储来存储知识)Cognitive search (attaching Cognitive Services for AI enrichment, or using Azure storage for knowledge store)

服务成本Service costs

与可以“暂停”以避免产生费用的虚拟机或其他资源不同,Azure 认知搜索服务在专门供你使用的硬件上始终可用。Unlike virtual machines or other resources that can be "paused" to avoid charges, an Azure Cognitive 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 1 个分区)。The minimum charge is the first search unit (one replica x one partition) at the billable rate. 在服务的整个生命周期内,此最低费用都是固定的,因为服务不能在低于此配置的组件上运行。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 Cognitive 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 Cognitive 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 Cognitive Search.
  • 在多服务解决方案中,如果所有服务位于同一个区域,将不会对通过网络传输的数据收费。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 Cognitive 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 扩充AI enrichment with Cognitive Services

对于 AI 扩充,应该计划在 S0 定价层上的 Azure 认知搜索所在的同一区域中附加一个计费的认知服务资源,用于即用即付处理。For AI enrichment, you should plan to attach a billable Azure Cognitive Services resource, in the same region as Azure Cognitive 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 Cognitive Search.
内置认知技能Built-in 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.

可以利用增量扩充(预览版)功能来提供缓存,使得在未来修改技能组后只需运行必要的认知技能,从而使索引器更高效,为你节省时间和金钱。The incremental enrichment (preview) feature allows you to provide a cache that enables the indexer to be more efficient at running only the cognitive skills that are necessary if you modify your skillset in the future, saving you time and money.

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

对于 Azure 认知搜索操作,要了解的最重要计费概念是搜索单位 (SU)。The most important billing concept to understand for Azure Cognitive Search operations is the search unit (SU). 由于 Azure 认知搜索必须同时使用副本和分区进行索引编制和查询,因此无法按其中的一个进行计费。Because Azure Cognitive 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 costs

以下建议可帮助你至少保持成本:The following suggestions can help you keep costs at a minimum:

  • 在同一区域或者在尽可能少的区域中创建所有资源,以最大程度地减少甚至消除带宽费用。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 Cognitive 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 Cognitive 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).

此外,请访问计费和成本管理获取与支出相关的内置工具和功能。Additionally, visit Billing and cost management for built-in tools and features related to spending.

不可能临时关闭搜索服务。Shutting down a search service on a temporary basis is not possible. 专用资源始终运行,是在服务的生存期内专门分配给你使用的。Dedicated resources are always operational, allocated for your exclusive use for the lifetime of your service. 删除服务这项操作是永久性的,也会删除其关联的数据。Deleting a service is permanent and also deletes its associated data.

就服务本身而言,降低费用的唯一方法是将副本和分区数减少到一个较低的水平,但仍能提供可接受的性能并遵从 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 Cognitive 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 go hand in hand. 层在两个级别施加限制:存储和资源。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. 其大小将基于导入的数据和索引配置,例如是否启用建议器、筛选和排序。Its size will be based on imported data and index configuration such as whether you enable suggesters, filtering, and sorting. 有关配置对大小的影响的详细信息,请参阅创建基本索引For more information about configuration impact on size, see Create a basic index .

进行全文搜索时,主要数据结构是倒排索引结构,该结构具有与源数据不同的特征。For full text search, the primary data structure is 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.

使用“免费”层进行评估Estimate with 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, but these are the steps:

估算出粗略的数字后,可将此数量增大一倍来得出两个索引(开发和生产)的预算,然后相应地选择层。With a rough estimate in hand, you might double that amount to budget for two indexes (development and production) and then choose your tier accordingly.

使用计费层进行评估Estimate with a billable tier

专用资源可以适应更大的采样和处理时间,并可以在开发期间对索引数量、大小和查询量进行更贴近实际的估算。Dedicated resources can accommodate larger sampling and processing times for more realistic estimates of index quantity, size, and query volumes during development. 某些客户会直接选择计费层,然后在开发项目成熟后重新进行评估。Some customers jump right in with a billable tier and then re-evaluate as the development project matures.

  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 not sure about the projected load.
    • 如果你知道会出现较大的索引和查询负载,请从较高的“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.

索引数量和大小对于分析而言同等重要。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 Cognitive 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 Cognitive 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

  • 允许围绕查询生成指标,并围绕使用模式收集数据(在营业期间执行查询,在非高峰期执行索引编制)。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 under provisioning 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 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 Cognitive 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.