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) 適用於有兩個或多個查詢工作負載複本的可計費服務，或具有三個或多個查詢和編製索引工作負載複本的可計費服務。 分割區數目不是 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 日之後
- 基本層支援三個分割區和三個複本，總共有九個搜尋單位（SU）。 它也有較大的分割區。
- S1、S2、S3 和 S3 HD 有較大的分割區，範圍從 3 到 7 倍，視層級而定。
- 較高的容量僅限於支持區域中的新搜尋服務。 目前沒有就地升級。
| 資源 | 免費 | 基本 | S1 | S2 | S3 | S3 HD | L1 | L2 |
|---|---|---|---|---|---|---|---|---|
| 服務等級協定 (SLA) | No | .是 | .是 | .是 | .是 | .是 | .是 | Yes |
| 儲存體 (分割區大小) | 50 MB | 15 GB | 160 GB | 512 GB | 1 TB | 1 TB | 1 TB | 2 TB |
| 資料分割 | N/A | 3 | 12 | 12 | 12 | 3 | 12 | 12 |
| 複本 | N/A | 3 | 12 | 12 | 12 | 12 | 12 | 12 |
2024 年 5 月 17 日之後
- L1 和 L2 具有更多資料分割記憶體和計算能力。
- 較高的容量僅限於支持區域中的新搜尋服務。 目前沒有就地升級。
| 資源 | 免費 | 基本 | S1 | S2 | S3 | S3 HD | L1 | L2 |
|---|---|---|---|---|---|---|---|---|
| 服務等級協定 (SLA) | No | .是 | .是 | .是 | .是 | .是 | .是 | Yes |
| 儲存體 (分割區大小) | 50 MB | 15 GB | 160 GB | 512 GB | 1 TB | TB | 2 TB | 4 TB |
| 資料分割 | N/A | 3 | 12 | 12 | 12 | 3 | 12 | 12 |
| 複本 | N/A | 3 | 12 | 12 | 12 | 12 | 12 | 12 |
具有較高儲存體限制的支援區域
服務必須位於下列其中一個區域，才能取得額外儲存體。 請參閱 Azure AI 搜尋服務有何新功能中的公告，以擴充到其他區域。
從 2024 年 5 月 17 日開始提供
| Country | 每個分割區提供額外容量的區域 |
|---|---|
| 瑞士 | 瑞士西部 |
| 南非 | 南非北部 |
| 德國 | 德國北部、德國中西部 |
| Azure Government | 德克薩斯州、亞利桑那州、維吉尼亞州 |
從 2024 年 4 月 3 日開始提供
| Country | 每個分割區提供額外容量的區域 |
|---|---|
| 美國 | 美國東部、美國東部 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 | 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 呼叫的文件大小限制
呼叫「索引 API」時的文件大小上限大約是 16 MB。
文件大小是索引 API 要求主體大小的實際限制。 由於您可以一次將多份文件整批傳遞給「索引 API」，因此大小限制實際上取決於批次中的文件數量。 針對具有單一文件的批次，文件大小上限為 16 MB 的 JSON。
評估文件大小時，請記得只考慮那些將值新增至搜尋案例的欄位，並排除您想要執行的查詢中沒有任何用途的任何來源欄位。
向量索引大小限制
當您使用向量欄位為文件編制索引時，Azure AI 搜尋服務會使用您提供的演算法參數建構內部向量索引。 這些向量索引的大小會受限於保留給服務層 (或 SKU) 向量搜尋的記憶體。
服務會針對搜尋服務中的每個分割區強制執行向量索引大小配額。 每個額外分割區都會增加可用的向量索引大小配額。 此配額是硬性限制，可確保您的服務保持狀況良好，這表示超過限制之後，進一步嘗試編製索引會導致失敗。 一旦刪除了某些向量文件或在擴大了分割區來釋出可用的配額，您就可以繼續編製索引。
此資料表描述了跨服務層每個分割區的向量索引大小配額。 針對內容，它包含：
- 每個層級的分割區儲存體限制，此處針對上下文重複。
- 向量索引 (當您將向量欄位新增至索引時建立) 可用的每個分割區數量 (以 GB 為單位)。
- 每個分割區的內嵌近似數量 (浮點數值)。
使用 [取得服務統計資料] 以擷取您的向量索引大小配額，或檢閱 Azure 入口網站中的 [索引] 頁面或 [使用量] 索引標籤。
向量限制會因服務建立日期和階層而有所不同。 若要檢查搜尋服務的存留期，並深入了解向量索引，請參閱向量索引大小並保持在限制內。
在 2024 年 5 月 17 日之後所建立服務的向量限制
在 2024 年 5 月 17 日之後於支援的區域建立的搜尋服務上，可使用最高的向量限制。
| 層 | 儲存體配額 (GB) | 每個分割區的向量配額 (GB) |
|---|---|---|
| 基本 | 15 | 5 |
| S1 | 160 | 35 |
| S2 | 512 | 150 |
| S3 | 1,024 | 300 |
| L1 | 2,048 | 150 |
| L2 | 4,096 | 300 |
2024 年 4 月 3 日至 2024 年 5 月 17 日之間所建立服務的向量限制
在 2024 年 4 月 3 日之後於支援的區域建立的搜尋服務上，可使用下列向量限制。
| 層 | 儲存體配額 (GB) | 每個分割區的向量配額 (GB) |
|---|---|---|
| 基本 | 15 | 5 |
| S1 | 160 | 35 |
| S2 | 350 | 100 |
| S3 | 700 | 200 |
| L1 | 1,000 | 12 |
| L2 | 2,000 | 36 |
請注意，在 4 月 3 日推出中，L1 和 L2 限制不會變更。
2023 年 7 月 1 日至 2024 年 4 月 3 日之間所建立服務的向量限制
下列限制適用於 2023 年 7 月 1 日至 2024 年 4 月 3 日之間建立的新服務，但下列區域除外，其從 2023 年 7 月 1 日之前即有原始限制：
- 德國中西部
- 印度西部
- 卡達中部
所有其他區域具有下列限制：
| 層 | 儲存體配額 (GB) | 每個分割區的向量配額 (GB) |
|---|---|---|
| 基本 | 2 | 1 |
| S1 | 25 | 3 |
| S2 | 100 | 12 |
| S3 | 200 | 36 |
| L1 | 1,000 | 12 |
| L2 | 2,000 | 36 |
在 2023 年 7 月 1 日之前所建立服務的向量限制
| 層 | 儲存體配額 (GB) | 每個分割區的向量配額 (GB) |
|---|---|---|
| 基本 | 2 | 0.5 |
| S1 | 25 | 1 |
| S2 | 100 | 6 |
| S3 | 200 | 12 |
| L1 | 1,000 | 12 |
| L2 | 2,000 | 36 |
索引子限制
執行時間上限是為了提供整體服務的平衡和穩定性，但較大的資料集所需的編制索引時間可能比允許的上限還多。 如果編製索引作業無法在允許的時間上限內完成，請嘗試按照排程執行編製索引作業。 排程器會追蹤索引狀態。 如果排定的索引作業因故中斷，索引子可以在下次排定的執行時間繼續從上次停止處進行。
| 資源 | 免費 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 個
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 個查詢金鑰