共用方式為

Azure AI 搜尋服務中的服務限制

  • 發行項

儲存體與工作負載的最大限制，以及索引、文件和其他物件的數量上限，皆取決於您是在免費、基本、標準，還是儲存體最佳化定價層中建立 Azure AI 搜尋服務。

  • 免費是 Azure 訂用帳戶隨附的多租用戶共用服務。

  • 基本以較小的規模，為生產工作負載提供專用的計算資源，但與其他租用戶共用一些網路基礎架構。

  • 標準是在專用的機器上執行，在各層級具有更多的儲存和處理容量。 標準共有四個等級︰S1、S2、S3 及 S3 HD。 S3 高密度 (S3 HD) 是針對多租用戶和大量的小型索引 (每個服務有 3,000 個索引) 所設計。 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 N/A 3 SU 36 SU 36 SU 36 SU 36 SU 36 SU 36 SU

1 每個 Azure 訂用帳戶可以有一項免費搜尋服務。 免費層取決於與其他客戶共用的基礎結構。 由於硬體並非專用，因此不支援擴大，且儲存體限制為 50 MB。

2 搜尋單位 (SU) 是可計費單位，會以複本或資料分割形式配置。 兩者您都需要。 若要深入了解 SU 組合，請參閱估計和管理搜尋服務的容量。

服務限制

下表涵蓋服務層級的 SLA、分割區計數和複本計數。

資源 免費 基本 S1 S2 S3 S3 HD L1 L2
服務等級協定 (SLA) No .是 .是 .是 .是 .是 .是 Yes
資料分割 N/A 3 1 12 12 12 3 12 12
複本 N/A 3 12 12 12 12 12 12

1 基本層支援三個分割區和三個複本，適用於在 2024 年 4 月 3 日之後所建立新搜尋服務上的總計 9 個搜尋單位 (SU)。 較舊的基本服務僅限於一個分割區和三個複本。

搜尋服務受限於儲存體限制上限 (分割區大小乘以分割區數目)，或依循索引數目上限或索引子數目上限的硬性限制 (視何者先到達)。

服務等級協定 (SLA) 適用於有兩個或多個查詢工作負載複本的可計費服務，或具有三個或多個查詢和編製索引工作負載複本的可計費服務。 分割區數目不是 SLA 考量。 如需詳細資訊，請參閱 Azure AI 搜尋服務中的可靠性。

免費服務沒有固定的分割區或複本，且會與其他訂閱者共用資源。

分割區儲存 (GB)

個別服務儲存空間限制會因兩個方面而有所不同：服務建立日期和區域。 在大多數支援區域中，較新的服務有較高的限制。

下表顯示儲存配額隨時間增加的進度 (以 GB 為單位)。 從 2024 年 4 月開始，在註腳中列出的區域中，較高容量分割區已上線。 較高的容量僅限於新的搜尋服務。 目前沒有就地升級。

服務建立日期 基本 S1 S2 S3/HD L1 L2
2024 年 4 月 3 日之前 2 25 100 200 1,024 2,048
2024 年 4 月 3 日至 2024 年 5 月 17 日 1 15 160 512 1,024 1,024 2,048
2024 年 5 月 17 日之後 2 15 160 512 1,024 2,048 4,096

1 這些區域中基本、S1、S2、S3 的容量儲存空間較高。 美洲：巴西南部、加拿大中部、加拿大東部、美國東部、美國東部 2、美國中部、美國中北部、美國中南部、美國西部、美國西部 2、美國西部 3、美國中西部。 歐洲：法國中部. 義大利北部、北歐、挪威東部、波蘭中部、瑞士北部、瑞典中部、英國南部、英國西部. 中東：阿拉伯聯合大公國北部。 非洲：南非北部。 亞太地區：澳大利亞東部、澳大利亞東南部、印度中部、Jio 印度西部、東亞、東南亞、日本東部、日本西部、南韓中部、南韓南部。

2 L1 和 L2 的容量儲存空間較高。 更多區域可在每個可計費層提供更高的容量。 歐洲：德國北部、德國中西部、瑞士西部。 Azure Government：德克薩斯州、亞利桑那州、佛吉尼亞州。 非洲：南非北部。 亞太地區：中國北部 3、中國東部 3。

少數區域仍會在較舊的基礎結構上執行，受限於 4 月 3 日的限制。 建立新的服務之前，請檢查支援的區域，以確定您選擇的區域提供額外的容量。

索引限制

資源 免費 基本 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
每個向量欄位的最大維度 4098 4098 4098 4098 4098 4098 4098 4098
每個索引的複雜集合數上限 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.88 TB 2.34 TB 100 GB N/A N/A

1 2017 年 12 月之前建立的基本服務，在索引方面具有較低的限制 (5 個，而不是 15 個)。 基本層級是限制較低的唯一層級，每個索引 100 個欄位。

2 欄位的上限包括複雜集合中的第一層欄位和巢狀子欄位。 例如，如果索引包含 15 個欄位，且有兩個各包含五個子欄位的複雜集合，則索引的欄位計數為 25。 包含非常大型欄位集合的索引可能會很慢。 將欄位和屬性限制為只有您需要的欄位和屬性，並執行編製索引和查詢測試，以確保效能可接受。

3 元素都會有上限，因為具有大量元素會大幅增加索引所需的儲存體。 複雜集合的元素會定義為該集合的成員。 例如，假設一份包含 Rooms 複雜集合的 Hotel 文件，Rooms 集合中的每個房間都會視為是一個元素。 在編製索引期間，編製索引引擎可以安全地處理整個文件中最多 3000 個元素。 此限制是在 api-version=2019-05-06 中引進，僅適用於複雜集合，但不適用於字串集合或複雜欄位。

4 在大部分階層上，索引大小上限是搜尋服務上的所有可用儲存體。 針對 S2、S3 和 S3 HD，任何索引的大小上限是資料表中提供的數字。 適用於在 2024 年 4 月 3 日之後建立的搜尋服務。

如果您的服務是佈建在更強大的叢集上，您可能會發現限制的上限有一些變化。 此處的限制代表通用分母。 建置到上述規格的索引可在任何區域中的對等服務層級之間移植。

文件限制

每個索引的文件數目上限為：

  • 基本、S1、S2、S3、L1 和 L2 搜尋服務上 240 億個。
  • S3 HD 上 20 億個。

在這些限制方面，複雜集合中的每個執行個體都會算成個別文件。

呼叫「索引 API」時的文件大小上限大約是 16 MB。

文件大小是索引 API 要求主體大小的實際限制。 由於您可以一次將多份文件整批傳遞給「索引 API」，因此大小限制實際上取決於批次中的文件數量。 針對具有單一文件的批次，文件大小上限為 16 MB 的 JSON。

評估文件大小時，請記得只考慮那些將值新增至搜尋案例的欄位，並排除您想要執行的查詢中沒有任何用途的任何來源欄位。

向量索引大小限制

當您使用向量欄位為文件編制索引時，Azure AI 搜尋服務會使用您提供的演算法參數建構內部向量索引。 這些向量索引的大小會受限於保留給服務層 (或 SKU) 向量搜尋的記憶體。 如需管理和最大化向量儲存的指導，請參閱向量索引大小並維持不超過限制。

向量限制會因下列因素而異：

從 2024 年 4 月起，在提供額外容量的區域 (其中的大部分區域) 的新搜尋服務會存在更高的向量限制。

下表顯示向量配額隨時間增加的進度 (以 GB 為單位)。 配額是依據每個分割區，因此，如果您將新的標準 (S1) 服務調整為 6 個分割區，則向量配額總計為 35 乘以 6。

服務建立日期 基本 S1 S2 S3/HD L1 L2
2023 年 7 月 1 日之前 1 0.5 1 6 12 12 36
2023 年 7 月 1 日至 2024 年 4月 3 日 2 1 3 12 36 12 36
2024 年 4 月 3 日至 2024年 5 月 17 日 3 5 35 150 300 12 36
2024 年 5 月 17 日之後 4 5 35 150 300 150 300

1 早期預覽期間的初始向量限制。

2 稍後預覽期間內的向量限制。 三個地區沒有更高的限制：德國中西部、印度西部、卡達中部。

3 根據支援層和區域的較大分割區，有較高的向量配額。

4 根據分割區大小更新，更多層級和區域的向量配額較高。

服務會針對搜尋服務中的每個分割區強制執行向量索引大小配額。 每個額外分割區都會增加可用的向量索引大小配額。 此配額是硬性限制，可確保您的服務保持狀況良好，這表示超過限制之後，進一步嘗試編製索引會導致失敗。 一旦刪除了某些向量文件或在擴大了分割區來釋出可用的配額，您就可以繼續編製索引。

重要

較高的向量限制會繫結至較大的分割區大小。 在舊版基礎結構上執行的區域受限於 7-4 月的限制。 檢閱區域清單，以取得分割區儲存體限制的狀態。

索引子限制

執行時間上限是為了提供整體服務的平衡和穩定性，但較大的資料集所需的編制索引時間可能比允許的上限還多。 如果編製索引作業無法在允許的時間上限內完成，請嘗試按照排程執行編製索引作業。 排程器會追蹤索引狀態。 如果排定的索引作業因故中斷，索引子可以在下次排定的執行時間繼續從上次停止處進行。

資源 免費 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 4 百萬 800 萬 1600 萬 N/A 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 技能組執行 (尤其是影像分析) 屬於運算密集任務，需要大量的可用處理能力。 這些工作負載的執行階段已縮短，可讓佇列中的其他作業有更多機會執行。

注意

如索引限制所述，從支援複雜類型的 GA API 版本 (2019-05-06) 開始，索引子也會在每個文件的所有複雜集合中，執行 3000 個元素的上限。 這表示如果您已使用先前的 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」(貓) 與「kitty」(小貓)、「feline」(貓科) 和「felis」(貓屬) 的關聯性計算為 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 擴充)

AI 擴充管線可呼叫 Azure AI 語言資源以進行實體辨識、實體連結、關鍵片語擷取、情感分析、語言偵測，以及個人資訊偵測，會受到資料限制的約束。 記錄的大小上限應該是 50,000 個字元 (以 String.Length 為測量單位)。 如果您需要先分割資料，再將該資料傳送至情感分析器，請使用文字分割技能。

節流限制

API 要求會因為系統接近尖峰容量而受到節流。 節流行為會因不同的 API 而異。 查詢 API (搜尋/建議/自動完成) 和編製索引 API 會根據服務，動態地進行節流。 索引 API 和服務作業 API 有靜態要求速率限制。

索引相關的作業靜態速率要求限制：

  • 列出索引 (GET /indexes)：每個搜尋單位每秒 3 個
  • Get 索引 (GET /indexes/myindex)：每個搜尋單位每秒 10 個
  • Create 索引 (POST /indexes)：每個搜尋單位每分鐘 12 個
  • Create 或 Update 索引 (PUT /indexes/myindex)：每個搜尋單位每秒 6 個
  • Delete 索引 (DELETE /indexes/myindex)：每個搜尋單位每分鐘 12 個

服務相關的作業靜態速率要求限制：

  • 服務統計資料 (GET /servicestats)：每個搜尋單位每秒 4 個

使用語意重新排名器進行 L2 重新排名，具有預期的量：

  • 每個複本最多 10 個並行查詢。 如果您預期輸送量需求接近、位於或高於此層級，請提出支援票證，以便我們可以為您的工作負載佈建。

API 要求限制

  • 每個要求最多 16 MB 1
  • 最長 8 KB 的 URL 長度
  • 每個索引上傳、合併、或刪除批次最多包含 1000 個文件
  • $orderby 子句中最多 32 個欄位
  • 搜尋子句中最多 100,000 個字元
  • search 中的子句數目上限 (以 AND 或 OR 分隔的運算式) 為 1024
  • 最大搜尋詞彙的大小是 utf-8 編碼文字的 32,766 個位元組 (32 KB 減 2 個位元組)
  • 前置詞搜尋和 RegEx 搜尋的搜尋字詞大小上限為 1000 個字元
  • 萬用字元搜尋和規則運算式搜尋在由 Lucene 處理時，限制為最多 1000 個狀態。

1 在 Azure AI 搜尋服務中，要求主體的上限是 16 MB，這會針對不受理論上限制約束之個別欄位或集合的內容強加實際限制 (如需有關欄位組合和限制的詳細資訊，請參閱支援的資料類型)。

因為未繫結的查詢可能會讓搜尋服務變得不穩定，所以查詢大小和組合會有所限制。 一般而言，這類查詢會以程式設計方式建立。 如果您的應用程式以程式設計方式產生搜尋查詢，建議您依照此方式設計，以避免產生無大小限制的查詢。

API 回應限制

  • 每一頁搜尋結果最多傳回 1000 個文件
  • 每個建議 API 要求最多傳回 100 個建議

API 金鑰限制

API 金鑰可用於服務驗證。 有兩種類型。 系統管理金鑰是在要求標頭中指定，並會授與完整的服務讀寫存取。 查詢金鑰為唯讀並在 URL 上指定，且通常會發佈到用戶端應用程式。

  • 每個服務最多 2 個系統管理金鑰
  • 每個服務最多 50 個查詢金鑰