Azure 认知搜索中的服务限制Service limits in Azure Cognitive Search

对存储、工作负荷以及索引和其他对象的数量的最大限制取决于你是在“免费”、“基本”、“标准”还是“存储优化”定价层上预配 Azure 认知搜索Maximum limits on storage, workloads, and quantities of indexes and other objects depend on whether you provision Azure Cognitive Search at Free, Basic, Standard, or Storage Optimized pricing tiers.

  • 免费层是 Azure 订阅随附的多租户共享服务。Free is a multi-tenant shared service that comes with your Azure subscription.

  • “基本”层为较小规模的生产工作负荷提供专用计算资源,但与其他租户共享某些网络基础结构。Basic provides dedicated computing resources for production workloads at a smaller scale, but shares some networking infrastructure with other tenants.

  • 标准层在专用计算机上运行,在每个级别上都具有更多存储和处理容量。Standard runs on dedicated machines with more storage and processing capacity at every level. 标准层共有四个级别:S1、S2、S3 和 S3 HD。Standard comes in four levels: S1, S2, S3, and S3 HD. S3 高密度 (S3 HD) 旨在用于多租户方案,以及较大数量的小型索引(每个服务 3000 个索引)。S3 High Density (S3 HD) is engineered for multi-tenancy and large quantities of small indexes (three thousand indexes per service). S3 HD 不提供索引器功能,数据引入必须利用可将数据从源推送到索引的 API。S3 HD does not provide the indexer feature and data ingestion must leverage APIs that push data from source to index.

  • “存储优化”层在总存储量、存储带宽和内存量比“标准”层更高的专用计算机上运行。 Storage Optimized runs on dedicated machines with more total storage, storage bandwidth, and memory than Standard. 此层面向缓慢变化的大型索引。This tier targets large, slow-changing indexes. “存储优化”层分为两个级别:L1 和 L2。Storage Optimized comes in two levels: L1 and L2.

订阅限制Subscription limits

可以在一个订阅中创建多个服务。You can create multiple services within a subscription. 每一个服务都可以在特定层上进行预配。Each one can be provisioned at a specific tier. 你仅受每个层允许的服务数量限制。You're limited only by the number of services allowed at each tier. 例如,在同一订阅中,最多可以在基本层创建 12 个服务,在 S1 层也创建 12 个服务。For example, you could create up to 12 services at the Basic tier and another 12 services at the S1 tier within the same subscription. 有关层的详细信息,请参阅为 Azure 认知搜索选择 SKU 或层For more information about tiers, see Choose an SKU or tier for Azure Cognitive Search.

最大服务数限制可以根据请求提高。Maximum service limits can be raised upon request. 如果需要在同一订阅中使用更多服务,请与 Azure 支持部门联系。If you need more services within the same subscription, contact Azure Support.

资源Resource 免费1Free1 基本Basic S1S1 S2S2 S3S3 S3 HDS3 HD L1L1 L2L2
最大服务数Maximum services 11 1616 1616 88 66 66 66 66
搜索单位 (SU) 的最大规模2Maximum scale in search units (SU)2 空值N/A 3 SU3 SU 36 个 SU36 SU 36 个 SU36 SU 36 个 SU36 SU 36 个 SU36 SU 36 个 SU36 SU 36 个 SU36 SU

1 免费层基于共享资源,而不基于专用资源。1 Free is based on shared, not dedicated, resources. 共享资源不支持纵向扩展。Scale-up is not supported on shared resources.

2 搜索单位是计费单位,以副本 或分区 形式分配。2 Search units are billing units, allocated as either a replica or a partition. 进行存储、索引和查询操作同时需要这两个资源。You need both resources for storage, indexing, and query operations. 若要了解有关 SU 计算的详细信息,请参阅缩放查询和索引工作负荷的资源级别To learn more about SU computations, see Scale resource levels for query and index workloads.

存储限制Storage limits

存储受磁盘空间限制,或者受索引、文档或其他高级资源的最大数目的硬性限制,具体取决于哪一个限制先实施。Storage is constrained by disk space or by a hard limit on the maximum number of indexes, document, or other high-level resources, whichever comes first. 下表描述了存储限制。The following table documents storage limits. 有关索引、文档和其他对象的最大限制,请参阅按资源限制For maximum limits on indexes, documents, and other objects, see Limits by resource.

资源Resource 免费Free 基本1Basic1 S1S1 S2S2 S3S3 S3 HD2S3 HD2 L1L1 L2L2
服务级别协议 (SLA)3Service level agreement (SLA)3 No Yes Yes Yes Yes Yes Yes Yes
每个分区的存储Storage per partition 50 MB50 MB 2 GB2 GB 25 GB25 GB 100 GB100 GB 200 GB200 GB 200 GB200 GB 1 TB1 TB 2 TB2 TB
每个服务的分区数Partitions per service 空值N/A 11 1212 1212 1212 33 1212 1212
分区大小Partition size 空值N/A 2 GB2 GB 25 GB25 GB 100 GB100 GB 200 GB200 GB 200 GB200 GB 1 TB1 TB 2 TB2 TB
副本Replicas 空值N/A 33 1212 1212 1212 1212 1212 1212

1 基本层有一个固定分区。1 Basic has one fixed partition. 在这一层,附加的搜索单元用于为增加的查询工作负荷分配更多副本。At this tier, additional search units are used for allocating more replicas for increased query workloads.

2 S3 HD 的硬性限制为三个分区,低于 S3 的分区限制。2 S3 HD has a hard limit of three partitions, which is lower than the partition limit for S3. 施加的分区限制较低是因为 S3 HD 的索引计数要高得多。The lower partition limit is imposed because the index count for S3 HD is substantially higher. 由于计算资源(存储和处理)和内容(索引和文档)都存在服务限制,因此会先达到内容限制。Given that service limits exist for both computing resources (storage and processing) and content (indexes and documents), the content limit is reached first.

3 为可计费服务提供了针对专用资源的服务级别协议。3 Service level agreements are offered for billable services on dedicated resources. 免费服务和预览功能没有 SLA。Free services and preview features have no SLA. 对于可计费服务,SLA 将在用户为服务预配足够冗余时生效。For billable services, SLAs take effect when you provision sufficient redundancy for your service. 查询(读取)SLA 需要两个或更多副本。Two or more replicas are required for query (read) SLAs. 查询和索引(读-写)SLA 需要三个或更多副本。Three or more replicas are required for query and indexing (read-write) SLAs. 分区数不属于 SLA 相关考虑因素。The number of partitions isn't an SLA consideration.

索引限制Index limits

资源Resource 免费Free 基本 1Basic 1 S1S1 S2S2 S3S3 S3 HDS3 HD L1L1 L2L2
最大索引数Maximum indexes 33 5 或 155 or 15 5050 200200 200200 每个分区 1000,或者每个服务 30001000 per partition or 3000 per service 1010 1010
每个索引的最大简单字段数目Maximum simple fields per index 10001000 100100 10001000 10001000 10001000 10001000 10001000 10001000
每个索引的最大复杂集合字段数目Maximum complex collection fields per index 4040 4040 4040 4040 4040 4040 4040 4040
每个文档的所有复杂集合的最大元素数目 2Maximum elements across all complex collections per document 2 30003000 30003000 30003000 30003000 30003000 30003000 30003000 30003000
复杂字段的最大深度Maximum depth of complex fields 1010 1010 1010 1010 1010 1010 1010 1010
每个索引最大建议器Maximum suggesters per index 11 11 11 11 11 11 11 11
每个索引的最大计分配置文件Maximum scoring profiles per index 100100 100100 100100 100100 100100 100100 100100 100100
每个配置文件的最大函数数量Maximum functions per profile 88 88 88 88 88 88 88 88

2 在 2017 年 12 月之前创建的基本服务对索引数的限制较低(为 5 个而不是 15 个)。1 Basic services created before December 2017 have lower limits (5 instead of 15) on indexes. 基本层是唯一具有下限(每个索引 100 个字段)的 SKU。Basic tier is the only SKU with a lower limit of 100 fields per index.

2 目前,在每个文档的复杂集合中包含极大量的元素会导致存储使用率很高。2 Having a very large number of elements in complex collections per document currently causes high storage utilization. 这是一个已知问题。This is a known issue. 同时,限制 3000 是所有服务层级的安全上限。In the meantime, a limit of 3000 is a safe upper bound for all service tiers. 此限制仅对利用支持复杂类型字段 (2019-05-06) 的最早正式版 (GA) API 的索引操作强制实施。This limit is only enforced for indexing operations that utilize the earliest generally available (GA) API version that supports complex type fields (2019-05-06) onwards. 为了避免造成可能正在使用早期 API 预览版(支持复杂类型字段)的客户端无法正常工作,我们不会对使用这些 API 预览版的索引操作强制实施此限制。To not break clients who might be using earlier preview API versions (that support complex type fields), we will not be enforcing this limit for indexing operations that use these preview API versions. 请注意,API 预览版并不旨在用于生产方案,我们强烈建议客户迁移到最新的 API 正式版。Note that preview API versions are not meant to be used for production scenarios and we highly recommend customers move to the latest GA API version.

文档限制Document limits

自 2018 年 10 月起,在任何区域的任何可计费层(基本、S1、S2、S3、S3 HD)创建的任何新服务都不再有任何文档计数限制。As of October 2018, there are no longer any document count limits for any new service created at any billable tier (Basic, S1, S2, S3, S3 HD) in any region. 2018 年 10 月之前创建的旧服务可能仍受文档计数限制的约束。Older services created prior to October 2018 may still be subject to document count limits.

若要确定服务是否有文档数限制,请使用 GET 服务统计信息 REST APITo determine whether your service has document limits, use the GET Service Statistics REST API. 文档数限制会在响应中反映出来,null 表示没有限制。Document limits are reflected in the response, with null indicating no limits.

备注

尽管该服务不会施加文档数限制,但在“基本”、S1、S2 和 S3 搜索服务中,每个索引的分片限制大约为 240 亿个文档。Although there are no document limits imposed by the service, there is a shard limit of approximately 24 billion documents per index on Basic, S1, S2, and S3 search services. 对于 S3 HD,每个索引的分片限制为 20 亿个文档。For S3 HD, the shard limit is 2 billion documents per index. 对于分片限制而言,复杂集合的每个元素都计为一个单独的文档。Each element of a complex collection counts as a separate document in terms of shard limits.

每个 API 调用的文档大小限制Document size limits per API call

调用索引 API 时的最大文档大小大约为 16 MB。The maximum document size when calling an Index API is approximately 16 megabytes.

文档大小实际上是索引 API 请求主体大小的限制。Document size is actually a limit on the size of the Index API request body. 由于可以将包含多个文档的批次传递给索引 API,因此大小限制实际上取决于批次中的文档数。Since you can pass a batch of multiple documents to the Index API at once, the size limit realistically depends on how many documents are in the batch. 对于具有单个文档的批次,最大文档大小是 16 MB JSON。For a batch with a single document, the maximum document size is 16 MB of JSON.

在估算文档大小时,请记得仅考虑那些可由搜索服务使用的字段。When estimating document size, remember to consider only those fields that can be consumed by a search service. 应在计算中忽略源文档中的任何二进制文件或图像数据。Any binary or image data in source documents should be omitted from your calculations.

索引器限制Indexer limits

“最长运行时间”存在的目的是在总体上为服务提供平衡和稳定性,但较大的数据集所需的索引编制时间可能会超过最大值允许的时间。Maximum running times exist to provide balance and stability to the service as a whole, but larger data sets might need more indexing time than the maximum allows. 如果在允许的最长时间内无法完成索引作业,请尝试按计划运行。If an indexing job cannot complete within the maximum time allowed, try running it on a schedule. 计划程序将跟踪索引的状态。The scheduler keeps track of indexing status. 如果计划的索引作业因某种原因而中断,则索引器可以在下一次计划运行时从它上次停止的位置重新开始。If a scheduled indexing job is interrupted for any reason, the indexer can pick up where it last left off at the next scheduled run.

资源Resource 免费 1Free 1 基本 2Basic 2 S1S1 S2S2 S3S3 S3 HD 3S3 HD 3 L1L1 L2L2
最大索引器数Maximum indexers 33 5 或 155 or 15 5050 200200 200200 空值N/A 1010 1010
最大数据源数Maximum datasources 33 5 或 155 or 15 5050 200200 200200 空值N/A 1010 1010
最大技能集数4Maximum skillsets 4 33 5 或 155 or 15 5050 200200 200200 空值N/A 1010 1010
每次调用的最大索引编制负载Maximum indexing load per invocation 10,000 个文档10,000 documents 仅受最大文档的限制Limited only by maximum documents 仅受最大文档的限制Limited only by maximum documents 仅受最大文档的限制Limited only by maximum documents 仅受最大文档的限制Limited only by maximum documents 空值N/A 无限制No limit 无限制No limit
最小计划Minimum schedule 5 分钟5 minutes 5 分钟5 minutes 5 分钟5 minutes 5 分钟5 minutes 5 分钟5 minutes 5 分钟5 minutes 5 分钟5 minutes 5 分钟5 minutes
最长运行时间Maximum running time 1-3 分钟1-3 minutes 24 小时24 hours 24 小时24 hours 24 小时24 hours 24 小时24 hours 空值N/A 24 小时24 hours 24 小时24 hours
包含技能组的索引器的最长运行时间 5Maximum running time for indexers with a skillset 5 3-10 分钟3-10 minutes 2 小时2 hours 2 小时2 hours 2 小时2 hours 2 小时2 hours 空值N/A 2 小时2 hours 2 小时2 hours
Blob 索引器:最大 blob 大小,MBBlob indexer: maximum blob size, MB 1616 1616 128128 256256 256256 空值N/A 256256 256256
Blob 索引器:从 blob 中提取的内容的最大字符数Blob indexer: maximum characters of content extracted from a blob 32,00032,000 64,00064,000 400 万4 million 800 万8 million 1600 万16 million 空值N/A 400 万4 million 400 万4 million

1 对于免费服务,对于 blob 源,索引器最长执行时间为 3 分钟;对于所有其他数据源,索引器最长执行时间为为 1 分钟。1 Free services have indexer maximum execution time of 3 minutes for blob sources and 1 minute for all other data sources. 对于调用认知服务的 AI 索引,免费服务的限制是每天 20 个免费事务(一个事务定义为一个成功通过扩充管道的文档)。For AI indexing that calls into Cognitive Services, free services are limited to 20 free transactions per day, where a transaction is defined as a document that successfully passes through the enrichment pipeline.

2 在 2017 年 12 月之前创建的基本服务在索引器、数据源和技能集方面的限制较低(为 5 个而不是 15 个)。2 Basic services created before December 2017 have lower limits (5 instead of 15) on indexers, data sources, and skillsets.

3 S3 HD 服务未包括索引器支持。3 S3 HD services do not include indexer support.

4 每个技能集最多拥有 30 项技能。4 Maximum of 30 skills per skillset.

5 AI 扩充和图像分析属于计算密集型功能,会消耗过多的可用处理能力。5 AI enrichment and image analysis are computationally intensive and consume disproportionate amounts of available processing power. 这些工作负荷的运行时间已缩短,从而使队列中的其他作业有更多的机会运行。Running time for these workloads has been shortened to give other jobs in the queue more opportunity to run.

备注

索引限制中所述,从支持复杂类型 (2019-05-06) 的最新 API 正式版开始,索引器还针对每个文档的所有复杂集合强制实施 3000 个元素的上限。As stated in the Index limits, indexers will also enforce the upper limit of 3000 elements across all complex collections per document starting with the latest GA API version that supports complex types (2019-05-06) onwards. 这意味着,如果你使用早期 API 版本创建了索引器,则不会受此限制约束。This means that if you've created your indexer with a prior API version, you will not be subject to this limit. 为了保持最高兼容性,使用早期 API 版本创建并使用 API 版本 2019-05-06 或更高版本更新了的索引器,仍会从这些限制中排除To preserve maximum compatibility, an indexer that was created with a prior API version and then updated with an API version 2019-05-06 or later, will still be excluded from the limits. 客户应注意使用极大复杂集合所造成的负面影响(如前所述);我们强烈建议使用最新 API 正式版创建任何新索引器。Customers should be aware of the adverse impact of having very large complex collections (as stated previously) and we highly recommend creating any new indexers with the latest GA API version.

同义词限制Synonym limits

同义词映射的最大数量因层而异。Maximum number of synonym maps varies by tier. 每个规则最多可以有 20 个扩展,一个扩展就是一个意义相同的词。Each rule can have up to 20 expansions, where an expansion is an equivalent term. 例如,在指定“猫”的情况下,与“猫咪”、“猫科动物”和“猫属”(猫的属)的关联将算作 3 个扩展。For example, given "cat", association with "kitty", "feline", and "felis" (the genus for cats) would count as 3 expansions.

资源Resource 免费Free 基本Basic S1S1 S2S2 S3S3 S3-HDS3-HD L1L1 L2L2
最大同义词映射数Maximum synonym maps 33 33 55 1010 2020 2020 1010 1010
每个映射的最大规则数Maximum number of rules per map 50005000 2000020000 2000020000 2000020000 2000020000 2000020000 2000020000 2000020000

每秒查询次数 (QPS)Queries per second (QPS)

每个客户必须独立制定 QPS 估计值。QPS estimates must be developed independently by every customer. 索引大小和复杂性、查询大小和复杂性以及流量大小是 QPS 的主要决定因素。Index size and complexity, query size and complexity, and the amount of traffic are primary determinants of QPS. 当此类因素未知时,没有方法能提供有意义的估计值。There is no way to offer meaningful estimates when such factors are unknown.

针对专用资源(基本层和标准层)上运行的服务进行计算时,估计值更可预测。Estimates are more predictable when calculated on services running on dedicated resources (Basic and Standard tiers). 由于能够控制更多参数,因此可以更精确地评估 QPS。You can estimate QPS more closely because you have control over more of the parameters. 有关如何进行估算的指导,请参阅 Azure 认知搜索的性能和优化For guidance on how to approach estimation, see Azure Cognitive Search performance and optimization.

与“标准”层相比,“存储优化”层(L1 和 L2)的查询吞吐量应更低,延迟应更高。For the Storage Optimized tiers (L1 and L2), you should expect a lower query throughput and higher latency than the Standard tiers.

数据限制(AI 扩充)Data limits (AI enrichment)

调用文本分析资源进行实体识别关键短语提取情绪分析语言检测个人信息检测AI 扩充管道会受到数据限制的约束。An AI enrichment pipeline that makes calls to a Text Analytics resource for entity recognition, key phrase extraction, sentiment analysis, language detection, and personal-information detection is subject to data limits. 记录的最大大小应为 50,000 个字符(通过 String.Length 进行测量)。The maximum size of a record should be 50,000 characters as measured by String.Length. 如果需要在将数据发送到情绪分析器之前拆分数据,请使用文本拆分技能If you need to break up your data before sending it to the sentiment analyzer, use the Text Split skill.

限制Throttling limits

当系统接近峰值容量时,搜索查询和索引请求会受到限制。Search query and indexing requests are throttled as the system approaches peak capacity. 对不同 API 的限制行为各不相同。Throttling behaves differently for different APIs. 系统会根据服务的负载动态限制查询 API(搜索/建议/自动完成)和索引 API。Query APIs (Search/Suggest/Autocomplete) and indexing APIs throttle dynamically based on the load on the service. 索引 API 有静态的请求速率限制。Index APIs have static request rate limits.

索引相关操作的静态速率请求限制:Static rate request limits for operations related to an index:

  • 列出索引 (GET /indexes):每个搜索单位每秒限制为 5 个List Indexes (GET /indexes): 5 per second per search unit
  • 获取索引 (GET /indexes/myindex):每个搜索单位每秒限制为 10 个Get Index (GET /indexes/myindex): 10 per second per search unit
  • 创建索引 (POST /indexes):每个搜索单位每分钟限制为 12 个Create Index (POST /indexes): 12 per minute per search unit
  • 创建或更新索引 (PUT /indexes/myindex):每个搜索单位每秒限制为 6 个Create or Update Index (PUT /indexes/myindex): 6 per second per search unit
  • 删除索引 (DELETE /indexes/myindex):每个搜索单位每分钟限制为 12 个Delete Index (DELETE /indexes/myindex): 12 per minute per search unit

API 请求限制API request limits

  • 每个请求最大 16 MB 1Maximum of 16 MB per request 1
  • 最大 8 KB URL 长度Maximum 8 KB URL length
  • 每个索引上传、合并或删除的批次最多包含 1000 个文档Maximum 1000 documents per batch of index uploads, merges, or deletes
  • $Orderby 子句中最多 32 字段Maximum 32 fields in $orderby clause
  • 最大搜索词大小为 UTF-8 编码文本的 32,766 字节(32 KB 减 2 个字节)Maximum search term size is 32,766 bytes (32 KB minus 2 bytes) of UTF-8 encoded text

1 在 Azure 认知搜索中,请求正文受 16 MB 上限的约束,这会针对不受理论限制约束的单个字段或集合的内容施加实际限制(有关字段组合和限制的详细信息,请参阅支持的数据类型)。1 In Azure Cognitive Search, the body of a request is subject to an upper limit of 16 MB, imposing a practical limit on the contents of individual fields or collections that are not otherwise constrained by theoretical limits (see Supported data types for more information about field composition and restrictions).

API 响应限制API response limits

  • 每页搜索结果最多返回 1000 个文档Maximum 1000 documents returned per page of search results
  • 每个建议 API 请求最多返回 100 条建议Maximum 100 suggestions returned per Suggest API request

API 密钥限制API key limits

API 密钥用于服务身份验证。API keys are used for service authentication. 有两种类型。There are two types. 管理密钥在请求标头中指定,并授予对服务的完全读写访问权限。Admin keys are specified in the request header and grant full read-write access to the service. 查询密钥是只读密钥并在 URL 上指定,并且通常分发给客户端应用程序。Query keys are read-only, specified on the URL, and typically distributed to client applications.

  • 每个服务最多 2 个管理密钥Maximum of 2 admin keys per service
  • 每个服务最多 50 个查询密钥Maximum of 50 query keys per service