Azure AI 搜尋中的服務限制
記憶體、工作負載和索引數量和其他物件的最大限制取決於您是否在免費、基本、標準或 儲存體 優化定價層建立 Azure AI 搜尋。
免費 是 Azure 訂用帳戶隨附的多租用戶共享服務。
Basic 會以較小的規模提供生產工作負載的專用運算資源，但與其他租用戶共用一些網路基礎結構。
標準 會在每一個層級具有更多記憶體和處理能力的專用計算機上執行。 標準有四個層級：S1、S2、S3 和 S3 HD。 S3 高密度 （S3 HD） 是針對 多租使用者 和大量小型索引所設計（每個服務 3,000 個索引）。 S3 HD 不提供 索引器功能 ，且數據擷取必須使用將數據從來源推送至索引的 API。
儲存體 Optimized 在專用計算機上執行，其總記憶體、記憶體頻寬和記憶體比標準還要多。 此層的目標是大型且變更緩慢的索引。 儲存體 Optimized 有兩個層級：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 | N/A | 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) | No | .是 | .是 | .是 | .是 | .是 | .是 | Yes |
| 儲存體 (分割區大小) | 50 MB | 2 GB | 25 GB | 100 GB | 200 GB | 200 GB | 1 TB | 2 TB |
| 資料分割 | N/A | 1 | 12 | 12 | 12 | 3 | 12 | 12 |
| 複本 | N/A | 3 | 12 | 12 | 12 | 12 | 12 | 12 |
2024年4月3日之後
針對在 2024 年 4 月 3 日之後建立的新服務：
- 基本層最多可以有三個分割區和三個複本，總共有九個搜尋單位（SU）。
- 基本、S1、S2、S3 每個分割區都有較多的記憶體，範圍從 3 到 7 倍，視層級而定。
- 新的搜尋服務必須位於 支持的區域中 ，才能取得基本層和其他層的額外容量。
目前沒有就地升級。 您應該 建立新的搜尋服務 ，以受益於額外的記憶體。
| 資源 | 免費 | 基本 | S1 | S2 | S3 | S3 HD | L1 | L2 |
|---|---|---|---|---|---|---|---|---|
| 服務等級協定 (SLA) | No | .是 | .是 | .是 | .是 | .是 | .是 | Yes |
| 儲存體 (分割區大小) | 50 MB | 15 GB | 160 GB | 350 GB | 700 GB | 700 GB | 1 TB | 2 TB |
| 資料分割 | N/A | 3 | 12 | 12 | 12 | 3 | 12 | 12 |
| 複本 | N/A | 3 | 12 | 12 | 12 | 12 | 12 | 12 |
具有較高記憶體限制的支援區域
在 2024 年 4 月 3 日之後建立的服務必須位於下列其中一個區域，才能取得額外的記憶體。 觀看 Azure AI 搜尋新功能中的公告，以擴充至其他區域。
| Country | 每個分割區提供額外容量的區域 |
|---|---|
| 美國 | 美國東部、美國東部 2、美國中部、美國中北部、美國中南部、美國西部、美國西部 2、美國西部 3、美國中西部 |
| 英國 | 英國南部、英國西部 |
| 阿拉伯聯合大公國 | 阿聯酋北部 |
| 瑞士 | 瑞士西部 |
| 瑞典 | 瑞典中部 |
| 波蘭 | 波蘭中部 |
| 挪威 | 挪威東部 |
| 南韓 | 韓國中部、韓國 |
| 日本 | 日本東部、日本西部 |
| 義大利 | 義大利北部 |
| 印度 | 印度中部、印度西部 |
| 法國 | 法國中部 |
| 歐洲 | 北歐 |
| 加拿大 | 加拿大中部、加拿大東部 |
| Bazil | 巴西南部 |
| 亞太地區 | 東亞、東南亞 |
| 澳大利亞 | 澳大利亞東部、澳大利亞東南部 |
索引限制
| 資源 | 免費 | 基本 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 | N/A | N/A | N/A | 1.92 TB | 2.4 TB | 100 GB | N/A | N/A |
1 在 2017 年 12 月之前建立的基本服務對索引有較低的限制（5 而不是 15 個）。 基本層是每個索引下限為 100 個字段的唯一層級。
2 欄位的上限包括複雜集合中的第一層欄位和巢狀子字段。 例如，如果索引包含 15 個字段，而且兩個複雜集合各有五個子欄位，則索引的字段計數為 25。 具有非常大型欄位集合的索引可能很慢。 將欄位和屬性限制為僅您需要的欄位和屬性 ，並執行索引編製和查詢測試，以確保可接受效能。
3 元素有上限，因為有大量元素會大幅增加索引所需的儲存空間。 複雜集合的項目定義為該集合的成員。 例如，假設 Hotel 檔具有 Rooms 複雜集合，則 Rooms 集合中的每個房間都會被視為元素。 在編製索引期間，索引引擎可以在整個檔中安全地處理最多 3,000 個專案。 這項限制 是在 中 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 | 23,5 億 |
| S3 | 700 | 200 | 47,000 萬 |
| 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 | N/A | 10 | 10 |
| 數據源上限 | 3 | 5 或 15 | 50 | 200 | 200 | N/A | 10 | 10 |
| 技能集 上限 4 | 3 | 5 或 15 | 50 | 200 | 200 | N/A | 10 | 10 |
| 每次叫用的索引編製負載上限 | 10,000 份文件 | 僅限受最大檔限制 | 僅限受最大檔限制 | 僅限受最大檔限制 | 僅限受最大檔限制 | N/A | 無限制 | 無限制 |
| 最小排程 | 5 分鐘 | 5 分鐘 | 5 分鐘 | 5 分鐘 | 5 分鐘 | 5 分鐘 | 5 分鐘 | 5 分鐘 |
| 運行時間 上限 5 | 1-3 分鐘 | 2 或 24 小時 | 2 或 24 小時 | 2 或 24 小時 | 2 或 24 小時 | N/A | 2 或 24 小時 | 2 或 24 小時 |
| 技能集 6 的索引器運行時間上限 | 3-10 分鐘 | 2 小時 | 2 小時 | 2 小時 | 2 小時 | N/A | 2 小時 | 2 小時 |
| Blob 索引器：Blob 大小上限、MB | 16 | 16 | 128 | 256 | 256 | N/A | 256 | 256 |
| Blob 索引器：從 Blob 擷取的內容字元上限 | 32,000 | 64,000 | 400 萬 | 800 萬 | 1600 萬 | N/A | 400 萬 | 400 萬 |
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 特別是技能集執行和影像分析，會耗用大量計算，並耗用不成比例的可用處理能力。 這些工作負載的運行時間已縮短，讓佇列中的其他作業有更多執行機會。
注意
如索引限制中所述，索引器也會在每個檔的所有複雜集合中強制執行 3000 個元素的上限，從支援複雜類型 （2019-05-06） 的最新版本開始。 這表示如果您已使用先前的 API 版本建立索引器，則不會受限於此限制。 為了保留最大的相容性，使用舊版 API 建立的索引器，然後使用 API 版本或更新版本 2019-05-06 更新，仍會 從限制中排除 。 客戶應該注意具有非常大型複雜集合的負面影響（如先前所述），強烈建議使用最新的 GA API 版本建立任何新的索引器。
共用私人鏈接資源限制
索引器可以透過透過共用私人鏈接資源 API 管理的私人端點存取其他 Azure 資源。 本節描述與這項功能相關聯的限制。
| 資源 | 免費 | 基本 | S1 | S2 | S3 | S3 HD | L1 | L2 |
|---|---|---|---|---|---|---|---|---|
| 私人端點索引器支援 | No | .是 | .是 | .是 | .是 | 無 | .是 | Yes |
| 具有技能集1 的索引器的私人端點支援 | No | 無 | 無 | .是 | .是 | 無 | .是 | Yes |
| 私人端點上限 | N/A | 10 或 30 | 100 | 400 | 400 | N/A | 20 | 20 |
| 相異資源類型上限 2 | N/A | 4 | 7 | 15 | 15 | N/A | 4 | 4 |
1 AI 擴充和影像分析會耗用大量計算，並耗用不成比例的可用處理能力。 因此，較低層會停用私人連線，以確保搜尋服務本身的效能和穩定性。
2 相異資源類型的數目會計算為指定搜尋服務的所有共用私人鏈接資源所使用的唯 groupId 一值數目，而不論資源的狀態為何。
同義字限制
同義字對應的數目上限會依階層而異。 每個規則最多可以有 20 個擴充，其中擴充是相等的詞彙。 例如，假設有 “cat”， association with “kitty”、“feline” 和 “felis” （cats 的 genus） 會算為 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 個字元，用於 前置詞搜尋 和 regex 搜尋
- 通配符搜尋和正則表達式搜尋限制在 Lucene 處理時最多 1000 個狀態。
1 在 Azure AI 搜尋中，要求主體受限於 16 MB 的上限，對未受理論限制的個別欄位或集合內容施加實際限制（如需字段組合和限制的詳細資訊，請參閱 支持的數據類型 ）。
查詢大小和組合的限制存在，因為未系結的查詢可能會破壞搜尋服務的穩定性。 一般而言，這類查詢會以程序設計方式建立。 如果您的應用程式以程式設計方式產生搜尋查詢，建議您以這種方式設計它，使其不會產生未繫結大小的查詢。
API 回應限制
- 每頁搜尋結果最多傳回 1,000 份檔
- 每個建議 API 要求最多傳回 100 個建議
API 金鑰限制
API 金鑰用於服務驗證。 有兩種類型。 管理員 金鑰是在要求標頭中指定，並授與服務的完整讀寫許可權。 查詢金鑰是只讀的，在 URL 上指定，而且通常會散發至用戶端應用程式。
- 每個服務最多 2 個系統管理金鑰
- 每個服務最多 50 個查詢金鑰