Azure AI 搜尋服務中的服務限制
儲存體與工作負載的最大限制，以及索引、文件和其他物件的數量上限，皆取決於您是在免費、基本、標準，還是儲存體最佳化定價層中建立 Azure AI 搜尋服務。
免費是 Azure 訂用帳戶隨附的多租用戶共用服務。
基本以較小的規模，為生產工作負載提供專用的計算資源，但與其他租用戶共用一些網路基礎架構。
標準是在專用的機器上執行，在各層級具有更多的儲存和處理容量。 標準共有四個等級︰S1、S2、S3 及 S3 HD。 S3 高密度 (S3 HD) 是針對多租用戶和大量的小型索引 (每個服務有 3,000 個索引) 所設計。 S3 HD 未提供索引子功能，而且資料擷取必須利用將資料從來源推送至索引的 API。
儲存體最佳化會在比標準更多儲存體、儲存體頻寬和記憶體的專用機器上執行。 此階層的目標是變更緩慢的大型索引。 儲存體最佳化分為兩個層級：L1 和 L2。
訂用帳戶限制
您可以建立多個 可計費的 搜尋服務（基本和更高層級），最多每個區域每個層級允許的服務數目上限。 例如，您可以在基本層建立最多 16 個服務，以及相同訂用帳戶和區域內 S1 層的另一個 16 個服務。 然後，您可以在另一個區域中建立額外的16個基本服務，以在同一個訂用帳戶下總共32個基本服務。 如需階層的詳細資訊，請參閱選擇 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 的 240 億
- S3 HD 上的 20 億個
- L1 上的2880億
- L2 上的5760億
在這些限制方面，複雜集合中的每個執行個體都會算成個別文件。
每個檔的大小上限約為 16 MB。 檔大小實際上是索引 API 要求承載大小的限制，也就是 16 MB。 該承載可以是單一檔或一批檔。 針對具有單一文件的批次，文件大小上限為 16 MB 的 JSON。
檔大小適用於 將檔上傳至搜尋服務的推送模式 索引。 如果您使用索引器進行 提取模式 索引編製，來源檔案可以是任何檔案大小，受限於 索引器限制。 針對 Blob 索引器，較高層級的檔案大小限制較大。 例如，S1 限制為 128 MB、S2 限制為 256 MB 等等。
評估文件大小時，請記得只編製那些為搜尋案例增加值的欄位編製索引，並排除您想要執行的查詢中沒有任何用途的來源字段。
向量索引大小限制
當您使用向量欄位為文件編制索引時，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 或 3-10 分鐘 | 2 小時或 24 小時 | 2 小時或 24 小時 | 2 小時或 24 小時 | 2 小時或 24 小時 | N/A | 2 小時或 24 小時 | 2 小時或 24 小時 |
| Blob 索引子︰Blob 大小上限，MB | 16 | 16 | 128 | 256 | 256 | N/A | 256 | 256 |
| Blob 索引器：從 Blob 6 擷取的內容最大字元數 | 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 小時的處理範圍。 如果您有連續執行 24 小時的未排程索引器，您可以假設這些索引器無法移轉至較新的基礎結構。 一般規則是，對於無法在兩小時內完成的編製索引作業，請將索引器排程為 5 分鐘，讓索引器可以快速挑選離開的位置。 在免費層上，運行時間上限為 3-10 分鐘，適用於具有技能集的索引器。
6 字元數目上限是以 Unicode 字碼單位為基礎，特別是 UTF-16。
注意
如索引限制所述，從支援複雜類型的 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 |
| 具有技能集和整合向量化 2 的索引器私人端點支援 | No | .是 | .是 | .是 | 是 | 無 | .是 | Yes |
| 私人端點上限 | N/A | 10 或 30 | 100 | 400 | 400 | N/A | 20 | 20 |
| 相異資源類型上限 3 | N/A | 4 | 7 | 15 | 15 | N/A | 4 | 4 |
1 AI 擴充和影像分析會耗用大量運算資源，並且需要大量的可用處理能力。 因此，會停用較低層級中的私人連線，以確保搜尋服務本身的效能和穩定性。
2024 年 4 月 3 日之後建立的高容量服務，這些服務列在數據分割記憶體下，並在編製索引時執行整合向量化工作負載，支援付費層中的共用私人連結。 系統至少必須偵測內嵌數據的技能。
3 相異資源類型的數目會計算為指定搜尋服務的所有共用私人鏈接資源所使用的唯 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 |
索引別名限制
索引別名數目上限會依階層和服務建立日期而有所不同。 在所有階層中，如果在 2022 年 10 月之後建立服務，則別名數目上限是允許的索引數目上限的兩倍。 如果服務是在 2022 年 10 月之前建立的，限制是允許的索引數目。
| 服務建立日期 | 免費 | 基本 | S1 | S2 | S3 | S3-HD | L1 | L2 |
|---|---|---|---|---|---|---|---|---|
| 2022 年 10 月之前 | 3 | 5 或 15 1 | 50 | 200 | 200 | 每個分割區 1000 個或每個服務 3000 個 | 10 | 10 |
| 2022年10月之後 | 6 | 30 | 100 | 400 | 400 | 每個分割區 2000 個或每個服務 6000 個 | 20 | 20 |
1 在 2017 年 12 月之前建立的基本服務有較低的限制 （5 而不是 15 個） 索引
資料限制 (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 個
語意排名器節流限制
語意排名器 會使用佇列系統來管理並行要求。 此系統可讓搜尋服務每秒獲得最高的查詢數目。 達到並行要求的限制時，會將其他要求放在佇列中。 如果佇列已滿，則會拒絕進一步的要求，而且必須重試。
每秒的語意排名器查詢總數會根據下列因素而有所不同：
- 搜尋服務的階層。 佇列容量和並行要求限制會因層級而異。
- 搜尋服務中的搜尋單位數目。 增加並行語意排名器查詢數目上限的最簡單方式，就是 將更多搜尋單位新增至您的搜尋服務。
- 區域中可用的語意排名器容量總計。
- 使用語意排名器來提供查詢所需的時間量。 這會根據搜尋服務的忙碌程度而有所不同。
下表描述依階層的語意排名器節流限制，受限於區域中的可用容量。 您可以連絡Microsoft支持人員以要求增加限制。
| 資源 | 基本 | S1 | S2 | S3 | S3-HD | L1 | L2 |
|---|---|---|---|---|---|---|---|
| 並行要求上限（每個搜尋單位） | 2 | 3 | 4 | 4 | 4 | 4 | 4 |
| 要求佇列大小上限（每個搜尋單位） | 4 | 6 | 8 | 8 | 8 | 8 | 8 |
API 要求限制
查詢的限制存在，因為未系結的查詢可能會破壞搜尋服務的穩定性。 一般而言，這類查詢會以程式設計方式建立。 如果您的應用程式以程式設計方式產生搜尋查詢，建議您依照此方式設計，以避免產生無大小限制的查詢。
基於類似的原因，承載的限制存在，以確保搜尋服務的穩定性。 此限制適用於整個要求，包含其所有元件。 例如，如果要求批次數個檔或命令，則整個要求必須符合支援的限制。
如果您必須超過支援的限制，您應該 測試工作負載 ，以便知道預期的情況。
除非有說明，否則下列 API 要求會套用至所有可程式化介面，包括 Azure SDK。
一般：
- 支持的承載上限為 16 MB，可透過 REST API 和 SDK 編製索引和查詢要求。
- 長度上限為 8 KB 的 URL（僅適用於 REST API）。
編製索引 API：
- 每個批次的索引上傳、合併或刪除最多支援 1,000 份檔。
查詢 API：
- $orderby 子句中的最多 32 個字段。
- 搜尋子句中最多 100,000 個字元。
- 搜尋中的子句數目上限為 3,000。
- Lucene 強制執行通配符和正則表達式查詢的最大限制。 它會將模式、變化或比對的數目上限為 1,000 個實例。 此限制已就緒，以避免引擎多載。
搜尋字詞：
- 支援的搜尋字詞大小上限為UTF-8編碼文字的32,766位元組（32 KB減2位元組）。 適用於關鍵詞搜尋和向量搜尋的文字屬性。
- 支援的搜尋字詞大小上限是前置詞搜尋和 regex 搜尋的 1,000 個字元。
API 回應限制
- 每一頁搜尋結果最多傳回 1000 個文件
- 每個建議 API 要求最多傳回 100 個建議
搜尋引擎預設會傳回 50 個結果，但您可以 覆寫此參數 上限上限。
API 金鑰限制
API 金鑰可用於服務驗證。 有兩種類型。 系統管理金鑰是在要求標頭中指定，並會授與完整的服務讀寫存取。 查詢金鑰為唯讀並在 URL 上指定，且通常會發佈到用戶端應用程式。
- 每個服務最多 2 個系統管理金鑰
- 每個服務最多 50 個查詢金鑰