你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

Azure AI 搜索中的服务限制

对存储、工作负荷以及索引和其他对象的数量的最大限制取决于你是在“免费”、“基本”、“标准”还是“存储优化”定价层上创建 Azure AI 搜索

  • “免费”层是 Azure 订阅随附的多租户共享服务。

  • “基本”层为较小规模的生产工作负荷提供专用计算资源,但与其他租户共享某些网络基础结构。

  • 标准层在专用计算机上运行,在每个级别上都具有更多存储和处理容量。 标准层共有四个级别:S1、S2、S3 和 S3 HD。 S3 高密度 (S3 HD) 旨在用于多租户方案,以及较大数量的小型索引(每个服务 3000 个索引)。 S3 HD 不提供索引器功能,并且数据引入必须使用将数据从源推送到索引的 API。

  • “存储优化”层在总存储量、存储带宽和内存量比“标准”层更高的专用计算机上运行。 此层面向缓慢变化的大型索引。 “存储优化”层分为两个级别:L1 和 L2。

订阅限制

可创建多个可计费的搜索服务(基本层和更高层级),最多可创建每层允许的服务数上限。 例如,在同一订阅中,最多可以在基本层创建 16 个服务,在 S1 层也创建 16 个服务。 有关层的详细信息,请参阅为 Azure AI 搜索选择层(或 SKU)

最大服务数限制可以根据请求提高。 如果需要在同一订阅中使用更多服务,请提交支持请求

资源 免费 1 基本 S1 S2 S3 S3 HD L1 L2
最大服务数 1 16 16 8 6 6 6 6
最大搜索单位数 (SU)2 空值 3 SU 36 个 SU 36 个 SU 36 个 SU 36 个 SU 36 个 SU 36 个 SU

1 每个 Azure 订阅可以有一个免费的搜索服务。 免费层基于与其他客户共享的基础结构。 硬件不是专用的,因此不支持纵向扩展,并且存储限制为 50 MB。

2 搜索单位 (SU) 即计费单位,以副本分区形式分配。 两个都需要。 若要了解有关 SU 组合的详细信息,请参阅估计和管理搜索服务的容量

服务限制

存储、分区和副本的搜索服务限制因服务创建日期而异,支持区域中较新的服务的限制更高。

搜索服务受存储上限限制(分区大小乘以分区数)或者受索引数上限索引器数上限的硬性限制(以先达者为准)。

服务级别协议 (SLA) 适用于对查询工作负荷具有两个或多个副本的计费服务,或者查询和索引工作负荷的三个或更多个副本。 分区数不属于 SLA 相关考虑因素。 有关详细信息,请参阅 Azure AI 搜索中的可靠性

免费服务没有固定分区或副本,它们与其他订阅者共享资源。

2024 年 4 月 3 日之前

资源 免费 基本 S1 S2 S3 S3 HD L1 L2
服务级别协议 (SLA)
存储(分区大小) 50 MB 2 GB 25 GB 100 GB 200 GB 200 GB 1 TB 2 TB
分区 空值 1 12 12 12 3 12 12
副本 空值 3 12 12 12 12 12 12

2024 年 4 月 3 日之后

对于在 2024 年 4 月 3 日之后创建的新服务:

  • 基本层最多可以有三个分区和三个副本,总共有 9 个搜索单位 (SU)。
  • 基本、S1、S2、S3 每个分区的存储量从 3 到 7 倍不等,具体取决于层。
  • 新的搜索服务必须位于受支持的区域中,才能获取基本层和其他层的额外容量。

目前没有就地升级。 应创建新的搜索服务,以便从额外的存储中受益。

资源 免费 基本 S1 S2 S3 S3 HD L1 L2
服务级别协议 (SLA)
存储(分区大小) 50 MB 15 GB 160 GB 350 GB 700 GB 200 GB 1 TB 2 TB
分区 空值 3 12 12 12 3 12 12
副本 空值 3 12 12 12 12 12 12

存储限制较高的受支持区域

在 2024 年 4 月 3 日之后创建的服务必须位于以下区域之一才能获取额外的存储。 观看 Azure AI 搜索中新增功能中的公告,了解如何扩展到其他区域。

国家/地区 为每个分区提供额外容量的区域
美国 美国东部,美国东部 2,美国中部,美国中北部,美国中南部,美国西部,美国西部 2,美国西部 3,美国中西部
英国 英国南部,英国西部 ​
阿拉伯联合酋长国 阿联酋北部​
瑞士 瑞士西部
瑞典 瑞典中部​
波兰 波兰中部​
挪威 挪威东部​
韩国 韩国中部,韩国南部 ​
日本 日本东部,日本西部
意大利 意大利北部​
印度 印度中部,Jio 印度西部 ​
法国 法国中部​
欧洲 北欧​
加拿大 加拿大中部,加拿大东部​
巴西 巴西南部​
亚太区 东亚,东南亚 ​
澳大利亚 澳大利亚东部,澳大利亚东南部​

索引限制

资源 免费 基本 1 S1 S2 S3 S3 HD L1 L2
最大索引数 3 5 或 15 50 200 200 每个分区 1000,或者每个服务 3000 10 10
每个索引的最大简单字段数目 2 1000 100 1000 1000 1000 1000 1000 1000
每个矢量场的最大维度数 3072 3072 3072 3072 3072 3072 3072 3072
每个索引的最大复杂集合 40 40 40 40 40 40 40 40
每个文档的所有复杂集合的最大元素数目 3 3000 3000 3000 3000 3000 3000 3000 3000
复杂字段的最大深度 10 10 10 10 10 10 10 10
每个索引最大建议器 1 1 1 1 1 1 1 1
每个索引的最大计分配置文件 100 100 100 100 100 100 100 100
每个配置文件的最大函数数量 8 8 8 8 8 8 8 8
最大索引大小4 空值 不可用 空值 1.92 TB 2.4 TB 100 GB 空值 空值

2 在 2017 年 12 月之前创建的基本服务对索引数的限制较低(为 5 个而不是 15 个)。 基本层是唯一具有下限(每个索引 100 个字段)的层。

2 字段的上限包括复杂集合中的一级字段和嵌套子字段。 例如,如果一个索引包含 15 个字段,并且有两个复杂集合,每个集合有 5 个子字段,则索引的字段计数为 25。 具有大型字段集合的索引可能会很慢。 将字段和属性限制为你需要的字段和属性,并运行索引和查询测试以确保性能可以接受。

3 元素数存在上限,因为大量元素会导致索引所需的存储大量增加。 复杂集合的元素定义为该集合的成员。 例如,假设有一个“酒店”文档中包含“客房”复杂集合,则将“客房”集合中的每个客房视为一个元素。 编制索引期间,索引编制引擎一次可最多安全地处理整个文档中的 3000 个元素。 api-version=2019-05-06 中引入了此限制,且仅适用于复杂集合,不适用于字符串集合或复杂字段。

4 在大多数层上,最大索引大小都是搜索服务上可用的存储。 对于 S2、S3 和 S3 HD,任何索引的最大大小都是表中提供的数字。 适用于 2024 年 4 月 3 日之后创建的搜索服务。

如果你的服务恰好是在更强大的群集上预配的,你可能会发现最大限制有所不同。 这里的限制代表了共同点。 根据上述规范构建的索引可以跨任何区域的等效服务层移植。

文档限制

在基本、S1、S2、S3、L1 和 L2 搜索服务上,每个索引可以有大约 240 亿个文档。 对于 S3 HD,每个索引的限制为 20 亿个文档。 就这些限制而言,复杂集合的每个实例都计为一个单独的文档。

每个 API 调用的文档大小限制

调用索引 API 时的最大文档大小大约为 16 MB。

文档大小实际上是索引 API 请求主体大小的限制。 由于可以将包含多个文档的批次传递给索引 API,因此大小限制实际上取决于批次中的文档数。 对于具有单个文档的批次,最大文档大小是 16 MB JSON。

在估算文档大小时,请记得仅考虑那些可由搜索服务使用的字段。 应在计算中忽略源文档中的任何二进制文件或图像数据。

矢量索引大小限制

使用矢量字段为文档编制索引时,Azure AI 搜索会使用提供的算法参数构建内部矢量索引。 这些矢量索引的大小取决于为服务层(或SKU)的矢量搜索保留的内存。

该服务对搜索服务中的每个分区强制实施矢量索引大小配额。 每个额外分区都会增加可用的矢量索引大小配额。 此配额是一个硬限制,用于确保你的服务保持健康运行,这意味着一旦超过限制,任何进一步的索引尝试将导致失败。 通过删除一些矢量文档或扩展分区释放可用配额后,可以继续进行索引编制。

此表描述了跨服务层的每个分区的矢量索引大小配额。 就上下文而言,它包括:

  • 每个层级的分区存储限制,在此对上下文重复。
  • 可用于矢量索引(在向索引添加矢量字段时创建)的每个分区的数量(以 GB 为单位)。
  • 每个分区的嵌入(浮点值)的近似数量。

使用GET 服务统计信息检索矢量索引大小配额,或者在 Azure 门户中查看索引页或使用情况选项卡。

矢量限制因服务创建日期和层而异。 要检查搜索服务的年龄并了解有关矢量索引的详细信息,请参阅矢量索引大小并保持在限制之内

2024 年 4 月 3 日之后在受支持区域中创建的服务的矢量限制

2024 年 4 月 3 日之后在受支持区域中创建的搜索服务提供了最高的矢量限制。

存储配额 (GB) 每个分区的矢量配额 (GB) 每个分区的大致浮点数(假设开销为 15%)
基本 15 5 11 亿
S1 160 35 82 亿
S2 350 100 235 亿
S3 700 200 470 亿
L1 1,000 12 28 亿
L2 2,000 36 84 亿

请注意,在 4 月 3 日推出中,L1 和 L2 限制保持不变。

2023 年 7 月 1 日至 2024 年 4 月 3 日之间创建的服务的矢量限制

以下限制适用于 2024 年 7 月 1 日至 4 月 3 日之间新建的服务,以下区域除外,这些区域自 2023 年 7 月 1 日之前具有原始限制:

  • 德国中西部
  • 印度西部
  • 卡塔尔中部

所有其他区域都有以下限制:

存储配额 (GB) 每个分区的矢量配额 (GB) 每个分区的大致浮点数(假设开销为 15%)
基本 2 1 2.35 亿
S1 25 3 7 亿
S2 100 12 28 亿
S3 200 36 84 亿
L1 1,000 12 28 亿
L2 2,000 36 84 亿

2023 年 7 月 1 日之前创建的服务的矢量限制

存储配额 (GB) 每个分区的矢量配额 (GB) 每个分区的大致浮点数(假设开销为 15%)
基本 2 0.5 1.15 亿
S1 25 1 2.35 亿
S2 100 6 14 亿
S3 200 12 28 亿
L1 1,000 12 28 亿
L2 2,000 36 84 亿

索引器限制

“最长运行时间”存在的目的是在总体上为服务提供平衡和稳定性,但较大的数据集所需的索引编制时间可能会超过最大值允许的时间。 如果在允许的最长时间内无法完成索引作业,请尝试按计划运行。 计划程序将跟踪索引的状态。 如果计划的索引作业因某种原因而中断,则索引器可以在下一次计划运行时从它上次停止的位置重新开始。

资源 免费 1 基本 2 S1 S2 S3 S3 HD 3 L1 L2
最大索引器数 3 5 或 15 50 200 200 空值 10 10
最大数据源数 3 5 或 15 50 200 200 空值 10 10
最大技能集数4 3 5 或 15 50 200 200 空值 10 10
每次调用的最大索引编制负载 10,000 个文档 仅受最大文档的限制 仅受最大文档的限制 仅受最大文档的限制 仅受最大文档的限制 空值 无限制 无限制
最小计划 5 分钟 5 分钟 5 分钟 5 分钟 5 分钟 5 分钟 5 分钟 5 分钟
最长运行时间 5 1-3 分钟 2 小时或 24 小时 2 小时或 24 小时 2 小时或 24 小时 2 小时或 24 小时 不适用 2 小时或 24 小时 2 小时或 24 小时
包含技能组的索引器的最长运行时间 6 3-10 分钟 2 小时 2 小时 2 小时 2 小时 空值 2 小时 2 小时
Blob 索引器:最大 blob 大小,MB 16 16 128 256 256 空值 256 256
Blob 索引器:从 blob 中提取的内容的最大字符数 32,000 64,000 4 百万 8 百万 1600 万 不可用 4 百万 4 百万

1 对于免费服务,对于 blob 源,索引器最长执行时间为 3 分钟;对于所有其他数据源,索引器最长执行时间为为 1 分钟。 索引器调用每 180 秒一次。 对于调用 Azure AI 服务的 AI 索引,免费服务的限制是每个索引器每天 20 个免费事务,其中一个事务定义为一个成功通过扩充管道传递的文档(提示:可以重置索引器以重置其计数)。

2 在 2017 年 12 月之前创建的基本服务在索引器、数据源和技能集方面的限制较低(为 5 个而不是 15 个)。

3 S3 HD 服务未包括索引器支持。

4 每个技能集最多拥有 30 项技能。

5 关于索引器的 2 或 24 小时最长持续时间:2 小时的最长持续时间是最常见的,这是你应计划的内容。 24 小时限制来自较旧的索引器实现。 如果有连续 24 小时运行的未计划索引器,那是因为这些索引器无法迁移到较新的基础结构。 作为一般规则,对于无法在两小时内完成的索引作业,请将索引器安排到一个 2 小时计划上。 第一个 2 小时间隔完成后,索引器会在开始下一个 2 小时间隔时从中断处继续。

6 技能集执行,特别是图像分析,属于计算密集型功能,会消耗过多的可用处理能力。 这些工作负荷的运行时间已缩短,从而使队列中的其他作业有更多的机会运行。

注意

索引限制中所述,从支持复杂类型 (2019-05-06) 的最新 API 正式版开始,索引器还针对每个文档的所有复杂集合强制实施 3000 个元素的上限。 这意味着,如果你使用早期 API 版本创建了索引器,则不会受此限制约束。 为了保持最高兼容性,使用 API 旧版本创建,然后使用 API 版本 2019-05-06 或更高版本更新的索引器,仍会从这些限制中2019-05-06。 客户应注意使用极大复杂集合所造成的负面影响(如前所述);我们强烈建议使用最新 API 正式版创建任何新索引器。

索引器可访问专用终结点上通过共享专用链接资源 API 管理的其他 Azure 资源。 本部分介绍与此功能相关的限制。

资源 免费 基本 S1 S2 S3 S3 HD L1 L2
专用终结点索引器支持 No
使用技能组的索引器的专用终结点支持1 No No No
最大专用终结点 不可用 10 或 30 100 400 400 不可用 20 20
最大不同资源类型2 不可用 4 7 15 15 不可用 4 4

1 AI 扩充和图像分析属于计算密集型功能,会消耗过多的可用处理能力。 因此,在较低层上禁用了专用连接以确保搜索服务本身的性能和稳定性。

2 不同资源类型的数量计算得出为在给定搜索服务的所有共享专用链接资源中使用的唯一 groupId 值的数目,不管资源的状态如何。

同义词限制

同义词映射的最大数量因层而异。 每个规则最多可以有 20 个扩展,一个扩展就是一个意义相同的词。 例如,在指定“猫”的情况下,与“猫咪”、“猫科动物”和“猫属”(猫的属)的关联将算作 3 个扩展。

资源 免费 基本 S1 S2 S3 S3-HD L1 L2
最大同义词映射数 3 3 5 10 20 20 10 10
每个映射的最大规则数 5000 20000 20000 20000 20000 20000 20000 20000

索引别名限制

索引别名的最大数量因层而异。 在所有层中,别名的最大数量是允许的最大索引数量的两倍。

资源 免费 基本 S1 S2 S3 S3-HD L1 L2
最大别名数量 6 10 或 30 100 400 400 每个分区 2000 个,或者每个服务 6000 个 20 20

数据限制(AI 扩充)

调用 Azure AI 语言资源进行实体识别实体链接关键短语提取情绪分析语言检测个人信息检测AI 扩充管道存在数据限制。 记录的最大大小应为 50,000 个字符,通过 String.Length 进行测量。 如果需要在将数据发送到情绪分析器之前拆分数据,请使用文本拆分技能

限制

当系统接近峰值容量时,API 请求会受到限制。 对不同 API 的限制行为各不相同。 系统会根据服务的负载动态限制查询 API(搜索/建议/自动完成)和索引 API。 索引 API 和服务操作 API 具有静态请求速率限制。

索引相关操作的静态速率请求限制:

  • 列出索引 (GET /indexes):每个搜索单位每秒限制为 3 个
  • 获取索引 (GET /indexes/myindex):每个搜索单位每秒限制为 10 个
  • 创建索引 (POST /indexes):每个搜索单位每分钟限制为 12 个
  • 创建或更新索引 (PUT /indexes/myindex):每个搜索单位每秒限制为 6 个
  • 删除索引 (DELETE /indexes/myindex):每个搜索单位每分钟限制为 12 个

服务相关操作的静态速率请求限制:

  • 服务统计信息 (GET /servicestats):每搜索单位每秒 4 个

API 请求限制

  • 每个请求最大 16 MB 1
  • 最大 8-KB URL 长度
  • 每个索引上传、合并或删除的批次最多包含 1,000 个文档
  • $Orderby 子句中最多 32 字段
  • 搜索子句中最多 100,000 个字符
  • search(用 AND 或 OR 分隔的表达式)中的最大子句数为 1024。
  • 最大搜索词大小为 UTF-8 编码文本的 32,766 字节(32 KB 减 2 个字节)
  • 前缀搜索正则表达式搜索的最大搜索词大小为 1,000 个字符
  • 通配符搜索正则表达式搜索在由 Lucene 处理时限制为最多 1000 个状态。

1 在 Azure AI 搜索中,请求正文受 16 MB 上限的约束,这会针对不受理论限制约束的单个字段或集合的内容施加实际限制(有关字段组合和限制的详细信息,请参阅支持的数据类型)。

对查询大小和组合存在限制,因为不受限制的查询会使搜索服务不稳定。 通常,这样的查询是以编程方式创建的。 如果应用程序以编程方式生成搜索查询,则建议将其设计为不会生成无限大小的查询。

API 响应限制

  • 每页搜索结果最多返回 1,000 个文档
  • 每个建议 API 请求最多返回 100 条建议

API 密钥限制

API 密钥用于服务身份验证。 有两种类型。 管理密钥在请求标头中指定,并授予对服务的完全读写访问权限。 查询密钥是只读密钥并在 URL 上指定,并且通常分发给客户端应用程序。

  • 每个服务最多 2 个管理密钥
  • 每个服务最多 50 个查询密钥