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

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

对存储、工作负荷以及索引、文档和其他对象数量的最大限制,取决于是在“免费”、“基本”、“标准”还是“存储优化”定价层上预配 Azure 搜索Maximum limits on storage, workloads, and quantities of indexes, documents, and other objects depend on whether you provision Azure 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.

  • 标准层在专用计算机上运行,在每个级别上都具有更多存储和处理容量。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.

  • 存储优化层在专用计算机上运行,与标准层相比具有更多的总存储、存储带宽和内存。Storage Optimized runs on dedicated machines with more total storage, storage bandwidth, and memory than Standard. “存储优化”层分为两个级别:L1 和 L2Storage Optimized comes in two levels: L1 and L2

备注

从7月1日起, 所有层都已正式发布, 其中包括存储优化层。As of July 1, all tiers are generally available, including the Storage Optimized tier. 可以在定价详细信息页上找到所有定价。All pricing can be found on the Pricing Details page.

S3 高密度 (S3 HD) 是针对特定工作负荷设计的:多租户和大量的小索引(每个索引一百万个文档,每个服务三千个索引)。S3 High Density (S3 HD) is engineered for specific workloads: multi-tenancy and large quantities of small indexes (one million documents per index, three thousand indexes per service). 此层未提供索引器功能This tier does not provide the indexer feature. 在 S3 HD 上,数据引入必须利用推送方式,使用 API 调用将数据从源推送到索引。On S3 HD, data ingestion must leverage the push approach, using API calls to push data from source to index.

备注

服务已在特定层上进行预配。A service is provisioned at a specific tier. 跳转层以获取容量涉及预配新的服务(不会就地升级)。Jumping tiers to gain capacity involves provisioning a new service (there is no in-place upgrade). 有关详细信息,请参阅选择 SKU 或层For more information, see Choose a SKU or tier. 若要详细了解在已预配的服务内调整容量,请参阅缩放查询和为工作负荷编制索引的资源级别To learn more about adjusting capacity within a service you've already provisioned, see Scale resource levels for query and indexing workloads.

订阅限制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 Search.

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

ResourceResource 免费1Free1 基本Basic S1S1 S2S2 S3S3 S3 HDS3 HD L1L1 L2L2
最大服务数Maximum services 1 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.

ResourceResource 免费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 1 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

ResourceResource 免费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
每个文档的所有复杂集合的最大元素数目Maximum elements across all complex collections per document 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

1 在 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.

文档限制Document limits

自 2018 年 10 月起,在任何区域的任何可计费层(基本、S1,S2、S3、S3 HD)创建的任何新服务都不再有任何文档数限制。As of October 2018, there are no longer any document limits for any new service created at any billable tier (Basic, S1, S2, S3, S3 HD) in any region. 虽然自 2017 年 11 月/12 月以来大多数区域的文档数量不受限制,但仍有五个区域继续实施文档数限制。While most regions have had unlimited document counts since November/December 2017, there were five regions that continued to impose document limits. 根据你创建搜索服务的时间和地点,你可能正在运行仍受文档数限制的服务。Depending on when and where you created a search service, you might be running a service that is still subject to document limits.

若要确定你的服务是否具有文档数限制,请检查你的服务的概述页中的“使用情况”磁贴。To determine whether your service has document limits, check the Usage tile in the overview page of your service. 文档数可能不受限制,也可能基于层受限于某个限制。Document counts are either unlimited, or subject to a limit based on tier.

“使用情况”磁贴

以前具有文档数限制的区域Regions previously having document limits

如果门户指示文档数限制,则你的服务要么是在 2017 年底之前创建的,要么是在使用容量较低的群集托管 Azure 搜索服务的数据中心上创建的:If the portal indicates a document limit, your service was either created before late 2017, or it was created on a data center using lower-capacity clusters for hosting Azure Search services:

  • 澳大利亚东部Australia East
  • 东亚East Asia
  • 印度中部Central India
  • 日本西部Japan West
  • 美国中西部West Central US

对于具有文档数限制的服务,将应用以下上限:For services subject to document limits, the following maximum limits apply:

免费Free 基本Basic S1S1 S2S2 S3S3 S3 HDS3 HD
10,00010,000 1 百万1 million 每个分区 1500 万,或者每个服务 1 亿 8 千万15 million per partition or 180 million per service 每个分区 6 千万,或者每个服务 7 亿 2 千万60 million per partition or 720 million per service 每个分区 1 亿 2 千万,或者每个服务 14 亿120 million per partition or 1.4 billion per service 每个索引 1 百万,或者每个分区 2 亿1 million per index or 200 million per partition

如果你的服务具有阻止你的限制,请创建一个新服务,然后将所有内容重新发布到该服务。If your service has limits that are blocking you, create a new service and then republish all content to that service. 没有任何机制可以在后台无缝地将你的服务重新预配到新硬件上。There is no mechanism for seamlessly reprovisioning your service onto new hardware behind the scenes.

备注

对于 2017 年底后创建的 S3 高密度服务,已去除每个分区 2 亿个文档的限制,但每个索引 100 万个文档的限制保留。For S3 High Density services created after late 2017, the 200 million document per partition has been removed but the 1 million document per index limit remains.

每个 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.

要保持较低的文档大小,务必将不可查询数据从请求中排除。To keep document size down, remember to exclude non-queryable data from the request. 图像和其他二进制数据不可直接查询,并且不应存储在索引中。Images and other binary data are not directly queryable and shouldn't be stored in the index. 要将不可查询的数据集成到搜索结果中,请定义用于存储资源的 URL 引用的不可搜索字段。To integrate non-queryable data into search results, define a non-searchable field that stores a URL reference to the resource.

索引器限制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.

ResourceResource 免费 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
最长运行时间 5Maximum running time 5 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
认知搜索技能集的最长运行时间或具有图像分析的 blob 索引 5Maximum running time for cognitive search skillsets or blob indexing with image analysis 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 4 百万4 million 4 百万4 million 4 百万4 million 不可用N/A 4 百万4 million 4 百万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 认知搜索工作负载和 Azure blob 索引中的 图像分析的运行时间比常规文本索引运行时间短。5 Cognitive search workloads and image analysis in Azure blob indexing have shorter running times than regular text indexing. 图像分析和自然语言处理属于计算密集型,并且消耗了过多的可用处理能力。Image analysis and natural language processing are computationally intensive and consume disproportionate amounts of available processing power. 减少运行时间,以便队列中的其他作业能够运行。Running time was reduced to give other jobs in the queue an opportunity to run.

每秒查询次数 (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 Search performance and optimization.

与“标准”层相比,“存储优化”层预计会有较低的查询吞吐量,较高的延迟。For the Storage Optimized tiers, you should expect a lower query throughput and higher latency than the Standard tiers. 估计会体验到的查询性能的方法与“标准”层相同。The methodology for estimating the query performance you'll experience is the same as the Standard tiers.

用于调用文本分析资源进行实体识别关键短语提取情绪分析语言检测认知搜索管道会受到数据限制。A cognitive search pipeline that makes calls to a Text Analytics resource for entity recognition, key phrase extraction, sentiment analysis, and language detection is subject to data limits. 记录的最大大小应为50000个字符String.LengthThe 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.

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 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