估計和管理搜尋服務的容量

在 Azure AI 搜尋服務中，容量是以可依工作負載縮放的「複本」和「分割區」為基礎。 複本是搜尋引擎的複製。 分割區是儲存體單位。 每個新的搜尋服務開始時都會有一個複本和一個分割區，但您可以個別新增或移除複本和分割區，以容納變動的工作負載。 新增容量會增加執行搜尋服務成本。

複本和分割區的實體特性如處理速度和磁碟 IO，會因服務層級而異。 在標準搜尋服務上，複本和分割區的速度比基本服務更快且更大。

變更容量非即時進行。 最多可能需要一小時才能對分割區進行委任或解除委任，特別是針對具有大量資料的服務。

縮放搜尋服務時，您可以從下列工具和方法中選擇：

• Azure 入口網站
• Azure PowerShell
• Azure CLI
• 管理 REST API

注意

在 2024 年 4 月和 5 月之後建立的較新服務上，可以以相同的計費費率提供更高容量的分割區。 如需詳細資訊，請參閱分割區大小升級服務限制。

概念：搜尋單位、複本、分割區

容量會以可配置於分割區和復本組合的搜尋單位來表示。

概念	定義
搜尋單位	可用容量總計 (36 單位) 的單一遞增。 至少需要一個單位才可執行服務。 第一個復本和數據分割組是第一個搜尋單位。 不過，複本或分割區的每個額外實例都會耗用額外的搜尋單位。 例如，您從一個複本和分割區開始（一個搜尋單位），新增第二個複本，您現在會取用兩個搜尋單位。 搜尋單位也是 Azure AI 搜尋服務 的計費單位。
複本	搜尋服務的執行個體，主要用來讓查詢作業達到負載平衡。 每個複本會裝載一個索引。 如果配置三個複本，則有三份可供維護查詢要求的索引複本。
資料分割	為讀寫作業 (例如，在重建或重新整理索引時) 提供實體儲存體和 I/O。 每個分割區都有總索引的配量。 如果您配置三個分割區，您的索引會以三個為單位分割。

檢閱分割區和複本資料表，以取得可能保持在 36 單位限制下的組合。

新增容量的時機

一開始會為服務配置由一個分割區和一個複本組成的最低層級資源。 您選擇的定價層會決定分割區大小和速度，而且每個定價層都會針對符合各種案例的一組特性進行最佳化。 如果您選擇較高的定價層，則可能需要比使用 S1 更少的分割區。 在自我導向測試中，您需要回答的其中一個問題是，較大型且更昂貴的分割區與在佈建較低定價層的服務上兩個較便宜分割區相比，是否能產生更好的效能。

單一服務必須具有足夠的資源，才能處理所有工作負載 (編製索引和查詢)。 兩個工作負載都不會在背景執行。 您可以排程，在查詢要求自然較不頻繁的時間編製索引，但服務不會另外排定某個工作優先於另一個工作。 此外，當服務或節點在內部更新時，特定數量的備援可讓查詢效能更加順暢。

判斷是否要新增容量的部分規則包括：

• 符合服務等級協定的高可用性準則
• HTTP 503 錯誤發生的頻率正在增加
• 預期會有大型查詢磁碟區

就一般規則而言，搜尋應用程式通常需要的複本數量會多於分割區數量，特別是在服務作業偏向查詢工作負載的情況下。 每個複本就像是您的索引複本，能讓服務針對多個複本進行要求的負載平衡。 索引的所有負載平衡和複寫都是由 Azure AI 搜尋服務所管理，而您可以隨時變更配置給服務的複本數目。 您最多可在標準搜尋服務中配置 12 個複本，並在基本搜尋服務中配置 3 個複本。 您可以從 Azure 入口網站或其中一個程式設計選項中進行複本配置。

額外的分割區有助於大量編製工作負載索引。 額外的資料分割可將讀取/寫入作業分配到更大量的計算資源。

最後您會發現，索引越大，查詢所需的時間就越長。 這麼一來，您可能會發現每個資料分割中每個累加式的增加在複本中都需要有較小但按比例的增加。 要將查詢執行速度提高到何種程度，需將您的查詢和查詢磁碟區複雜性納入考量。

注意

新增更多複本或分割區會增加執行服務的成本，並可能會對結果的排序方式產生稍微變化。 請務必檢查定價計算機，以了解新增更多節點會對計費造成哪些影響。 下圖可協助您交互參照特定設定所需的搜尋單位數目。 如需其他複本如何影響查詢處理的詳細資訊，請參閱排序結果。

如何變更容量

若要增加或減少搜尋服務的容量，請新增或移除分割區和複本。

1. 登入 Azure 入口網站，然後選取搜尋服務。

2. 在 [設定] 底下，開啟 [縮放] 頁面以修改複本和分割區。

   下列螢幕擷取畫面顯示以一個複本和分割區佈建的標準服務。 底部的公式會指出正在使用多少搜尋單位 (1)。 如果單價為 $100 (非實際價格)，則執行此服務的每月成本平均為 $100。

   

3. 使用滑桿來增加或減少分割區數目。 選取 [儲存]。

   此範例會新增第二個複本和分割區。 請注意搜尋單位元數目；目前是四個，因為計費公式是複本乘以分割區 (2 x 2)。 將容量翻倍超過執行服務的成本。 如果搜尋單位成本為 $100，新的每月帳單現在會是 $400。

   如需每個定價層的目前每個單位成本的詳細資訊，請瀏覽定價頁面。

   

4. 儲存之後，您可以檢查通知以確認動作成功。

   

   容量變更可能需要 15 分鐘到數小時才能完成。 一旦流程啟動，而且無提供複本和分割區調整的即時監視，就無法取消。 不過，在進行變更時，下列訊息仍會顯示。

   

注意

服務在佈建之後，即無法升級到較高的定價層。 您必須在新層中建立搜尋服務，然後重新載入您的索引。 如需有關服務佈建的說明，請參閱在入口網站中建立 Azure AI 搜尋服務。

如何處理縮放要求

接收到縮放要求時，搜尋服務會：

1. 檢查要求是否有效。
2. 開始備份資料和系統資訊。
3. 檢查服務是否已處於佈建狀態 (目前新增或排除複本或分割區)。
4. 啟動佈建。

縮放服務可能需要 15 分鐘或超過一小時才能完成，視服務的大小和要求範圍而定。 備份可能需要幾分鐘才能完成，視資料量和分割區及複本的數目而定。

上述步驟不完全連續。 例如，系統會在可以安全佈建時開始佈建，代表可能是在備份變得緩慢時。

縮放期間發生錯誤

「目前不允許服務更新作業，因為我們正在處理先前的要求」的錯誤訊息會出現，是因為在服務已經在處理先前的要求，同時間又重複縮小或擴大的要求。

藉由檢查服務狀態以確認佈建狀態來解決此錯誤：

1. 使用管理 REST API、Azure PowerShell 或 Azure CLI 來取得服務狀態。
2. 呼叫 Get Service (REST) 或對等的 PowerShell 或 CLI。
3. 檢查 "provisioningState" 的回應："provisioning"

如果狀態為「正在佈建」，請等候要求完成。 在嘗試另一個要求之前，狀態應為「成功」或「失敗」。 備份沒有狀態。 備份是內部作業，而且不太可能導致縮放演練發生任何中斷。

如果您的搜尋服務似乎處於佈建狀態，請檢查是否有無法使用的孤立索引，且沒有查詢磁碟區及沒有索引更新。 無法使用的索引可以封鎖服務容量的變更。 特別是，尋找 CMK 加密索引，其索引鍵不再有效。 您應該刪除索引或還原索引鍵，讓索引重新上線並解除封鎖調整作業。

資料分割與複本組合

下圖適用於標準層和更高層級。 其會顯示所有可能的分割區和複本組合，受限於每個服務 36 個搜尋單位的上限。

	1 個資料分割	2 個資料分割	3 個資料分割	4 個資料分割	6 個資料分割	12 個資料分割
1 個複本	1 SU	2 SU	3 SU	4 SU	6 SU	12 SU
2 個複本	2 SU	4 SU	6 SU	8 SU	12 SU	24 SU
3 個複本	3 SU	6 SU	9 SU	12 SU	18 SU	36 SU
4 個複本	4 SU	8 SU	12 SU	16 SU	24 SU	N/A
5 個複本	5 SU	10 SU	15 SU	20 SU	30 SU	N/A
6 個複本	6 SU	12 SU	18 SU	24 SU	36 SU	N/A
12 個複本	12 SU	24 SU	36 SU	N/A	N/A	N/A

基本搜尋服務的搜尋單位計數較低。

• 在 2024 年 4 月 3 日之前建立的搜尋服務上，基本搜尋服務可以有正好 1 個分割區及最多 3 個複本，上限為 3 個 SU。 唯一可調整的資源是複本。

• 在支援區域中於 2024 年 4 月 3 日之後建立的搜尋服務上，基本服務最多可以有三個分割區和三個複本。 SU 上限為 9，可支援分割區和複本的完整補充。

對於任何可計費層上的搜尋服務，不論建立日期為何，您至少需要兩個複本，才能在查詢上取得高可用性。

如需每一層的計費費率和貨幣，請參閱 Azure AI 搜尋服務定價頁面。

使用可計費層估計容量

儲存體需求取決於您預期要建置的索引大小。 沒有固定的啟發學習法或通用法則能幫助您進行估計。 判斷索引大小的唯一方法就是建置一個索引。 其大小是以 Token 化和內嵌為基礎，以及您是否啟用建議工具、篩選和排序，或可以利用向量壓縮。

我們建議在可計費層、基本或更高階層上估計。 免費層會在多個客戶共用的實體資源上執行，且受限於超出您控制的因素。 只有可計費搜尋服務的專用資源可以因應較大的取樣和處理時間，並可在開發期間實際預估索引數量、大小和查詢量。

1. 檢閱每一個定價層的服務限制，以判斷較低定價層是否能支援您需要的索引數量。 請考慮您針對使用中開發、測試和生產環境是否需要多個索引複本。

   搜尋服務受限於物件限制 (索引、索引器、技能集等數目上限) 和儲存體限制。 先觸達哪個限制即為有效限制。

2. 在可計費的定價層建立服務。 階層會針對特定工作負載進行最佳化。 例如，儲存體最佳化定價層的限制為 10 個索引，因為其設計目的為支援極少數非常大型的索引。

   • 如果您不確定預測負載為多少，請從較低的基本或 S1 定價層開始。

   • 如果測試包含大規模的索引和查詢負載，請從較高的定價層開始，例如 S2 或甚至 S3。

   • 從 L1 或 L2 的儲存體最佳化開始，如果您要為大量資料編製索引，而且查詢負載相對較低，如同內部商務應用程式一樣。

3. 建置初始索引，以判斷來源資料轉譯為索引的情形。 這是唯一能預估索引大小的方式。 欄位定義上的屬性會影響實體儲存體需求：

   • 針對關鍵字搜尋，將欄位標示為可篩選且可排序會增加索引大小。

   • 針對向量搜尋，您可以 設定參數以減少向量大小。

4. 在入口網站中監視儲存體、服務限制、查詢量和延遲。 入口網站會顯示每秒查詢數、節流查詢和搜尋延遲。 所有這些值都可以協助您決定是否選取正確的定價層。

5. 新增高可用性的複本或減輕緩慢的查詢效能。

   並無關於容納查詢負載所需複本數目的規則。 查詢效能依據查詢和完成工作負載的複雜度而定。 雖然新增複本會明顯獲得更好的效能，但是最終結果並不會完全地呈線性關係：新增 3 個複本並不保證有 3 倍的輸送量。 如需評估解決方案 QPS 的規則，請參閱分析效能和監視查詢。

若為反向索引，其大小和複雜性取決於內容，而不一定是您送入的資料量。 具有大量重複內容的大型資料來源所產生的索引，可能會比內容變化極大的資料集所產生的索引還小。 因此，不太可能根據原始資料集的大小來推斷出索引大小。

如果您包含永遠不會搜尋的資料，則可能會導致儲存體需求膨脹。 理想情況是，文件只包含搜尋體驗所需的資料。

服務等級協定考量

免費層和預覽功能並未涵蓋服務等級協定 (SLA)。 在所有可計費層中，SLA 會在您為您的服務佈建足夠的備援性時生效。

• 兩個或多個複本滿足查詢 (讀取) SLA。

• 三個或多個復本滿足查詢和編製索引 (讀寫) SLA。

分割區數目不會影響 SLA。

下一步

規劃和管理成本