估計及管理搜尋服務的容量
在 Azure AI 搜尋服務中，容量是以 可調整為工作負載的複 本和數據 分割 為基礎。 複本是搜尋引擎的複本。 分割區是記憶體單位。 每個新的搜尋服務都會以一個開頭，但您可以個別新增或移除複本和分割區，以容納變動的工作負載。 新增容量會增加 執行搜尋服務的成本。
復本和數據分割的實體特性，例如處理速度和磁碟IO，會因服務層級而異。 在標準搜尋服務上，複本和分割區的速度比基本服務更快且更大。
變更容量並非瞬間。 最多可能需要一個小時才能委託或解除委任數據分割，特別是對於具有大量數據的服務。
調整搜尋服務時，您可以從下列工具和方法中選擇：
概念：搜尋單位、複本、分割區
容量會以可配置於分割區和復本組合的搜尋單位來表示。
| 概念 | 定義 |
|---|---|
| 搜尋單位 | 可用容量總計的單一增量（36 個單位）。 這也是 Azure AI 搜尋服務 的計費單位。 執行服務至少需要一個單位。 |
| 複本 | 搜尋服務的實例，主要用於負載平衡查詢作業。 每個複本都會裝載一份索引複本。 如果您配置三個複本，則有三份索引複本可供服務查詢要求。 |
| 資料分割 | 讀取/寫入作業的實體記憶體和 I/O（例如，重建或重新整理索引時）。 每個分割區都有總計索引的配量。 如果您配置三個分割區，索引會分割成第三個數據分割。 |
檢閱數據 分割和複本數據表 ，以取得可能保持在36單位限制下的組合。
新增容量的時機
一開始，服務會配置由一個分割區和一個複本組成的最小層級資源。 您選擇的階層會決定分割區大小和速度，而且每個層都會針對一組符合各種案例的特性進行優化。 如果您選擇較高階層，則 可能需要比使用 S1 的分割區少 。 您需要透過自我導向測試來回答的其中一個問題是，較大且更昂貴的分割區是否比較低層布建的服務上的兩個更便宜的數據分割產生更好的效能。
單一服務必須有足夠的資源來處理所有工作負載（編製索引和查詢）。 兩個工作負載都不會在背景執行。 您可以排程查詢要求自然較不頻繁的時間編製索引，但服務不會將某個工作優先於另一個工作。 此外，當服務或節點在內部更新時，特定數量的備援可讓查詢效能順暢。
判斷是否要新增容量的一些指導方針包括：
- 符合服務等級協定的高可用性準則
- HTTP 503 錯誤的頻率正在增加
- 預期會有大型查詢磁碟區
一般而言，搜尋應用程式通常需要比分割區更多的複本，特別是當服務作業偏向於查詢工作負載時。 每個復本都是索引的複本，可讓服務對多個複本對要求進行負載平衡。 索引的所有負載平衡和復寫都是由 Azure AI 搜尋所管理，而且您可以隨時變更為服務配置的複本數目。 您可以在標準搜尋服務中配置最多 12 個複本，並在基本搜尋服務中配置 3 個複本。 您可以從 Azure 入口網站 或其中一個程式設計選項進行複本配置。
額外的分割區有助於大量編製索引工作負載。 額外的分割區會將讀取/寫入作業分散到大量的計算資源。
最後，較大的索引需要較長的時間才能查詢。 因此，您可能會發現分割區中的每個累加增加都需要較小但比例增加的複本。 查詢和查詢量的複雜性將考慮查詢執行的速度。
注意
新增更多複本或分割區會增加執行服務的成本，並可能會對結果的排序方式產生輕微的變化。 請務必檢查 定價計算機 ，以瞭解新增更多節點的計費影響。 下圖可協助您交叉參考特定設定所需的搜尋單位數目。 如需其他複本如何影響查詢處理的詳細資訊，請參閱 排序結果。
如何變更容量
若要增加或減少搜尋服務的容量，請新增或移除分割區和複本。
登入 Azure 入口網站，然後選取搜尋服務。
在 [設定] 下，開啟 [調整] 頁面以修改復本和數據分割。
下列螢幕快照顯示以一個複本和分割區布建的標準服務。 底部的公式會指出正在使用多少個搜尋單位 （1）。 如果單價為 $100 （不是實際價格），則執行這項服務的每月成本平均為100美元。
使用滑桿來增加或減少分割區數目。 選取 [儲存]。
本範例會新增第二個複本和分割區。 請注意搜尋單位計數;現在是四個，因為計費公式是複本乘以分割區 （2 x 2）。 將容量增加一倍以上，可增加執行服務的成本。 如果搜尋單位成本是 $100，新的每月帳單現在會是 $400 美元。
如需每一層目前的每單位成本，請瀏覽 定價頁面。
儲存之後，您可以檢查通知以確認動作成功。
容量變更可能需要 15 分鐘到數小時才能完成。 一旦程序啟動，且復本和數據分割調整沒有即時監視，就無法取消。 不過，在進行變更時，下列訊息仍會顯示。
注意
布建服務之後，就無法升級至較高層。 您必須在新層建立搜尋服務，並重載您的索引。 如需服務布建的說明，請參閱在入口網站中建立 Azure AI 搜尋服務。
如何處理調整要求
收到縮放要求時，搜尋服務：
- 檢查要求是否有效。
- 開始備份數據和系統資訊。
- 檢查服務是否已經處於布建狀態（目前新增或排除複本或分割區）。
- 開始布建。
視服務的大小和要求範圍而定，調整服務可能需要 15 分鐘或超過一小時的時間。 備份可能需要幾分鐘的時間，視數據量和分割區和複本數目而定。
上述步驟並非完全連續。 例如，當系統可以安全地進行時，系統就會開始布建，這可能是備份正在結束的時候。
調整期間發生錯誤
錯誤訊息「目前不允許服務更新作業，因為我們正在處理先前的要求」，是因為當服務已經處理先前的要求時，重複要求相應減少或增加。
藉由檢查服務狀態來確認布建狀態，以解決此錯誤：
- 使用管理 REST API、Azure PowerShell 或 Azure CLI 來取得服務狀態。
- 針對 PowerShell 或 CLI 呼叫 Get Service （REST） 或對等專案。
- 檢查 “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 日之前建立的搜尋服務上，基本搜尋服務最多可以有一個分割區和最多三個複本，上限為三個 SU。 唯一可調整的資源是複本。
在支持區域中於 2024 年 4 月 3 日之後建立的搜尋服務上，基本服務最多可以有三個分割區和三個複本。 最大 SU 限制為 9，可支援分割區和複本的完整補充。
對於任何計費層上的搜尋服務，不論建立日期為何，您至少需要兩個複本，才能在查詢上取得高可用性。
如需每一層和貨幣的計費費率，請參閱 Azure AI 搜尋定價頁面。
使用可計費層估計容量
儲存體 需求取決於您預期建置的索引大小。 沒有紮實的啟發學習法或一般性有助於估計。 判斷索引 大小的唯一方法是組建一個。 其大小是以令牌化和內嵌為基礎，以及您是否啟用建議工具、篩選和排序，或可以利用 向量壓縮。
我們建議在計費層、基本或更新版本上估計。 免費層會在多個客戶共享的實體資源上執行，而且受限於超出您控制的因素。 只有可計費搜尋服務的專用資源可以容納較大的取樣和處理時間，以在開發期間更實際地估計索引數量、大小和查詢量。
檢閱每個層級 的服務限制，以判斷較低層是否可以支援您需要的索引數目。 請考慮您是否需要多個索引複本，才能使用中開發、測試和生產環境。
搜尋服務受限於物件限制（索引器、索引器、技能集等數目上限）和記憶體限制。 先達到哪一個限制是有效限制。
在可計費層建立服務。 階層會針對特定工作負載進行優化。 例如，儲存體 優化層的限制為10個索引，因為它的設計目的是支援非常大型的索引數目。
如果您不確定投影的負載，請從基本或 S1 低開始。
如果測試包含大規模的索引編製和查詢載入，請從 S2 或甚至 S3 開始高。
從 儲存體 Optimized 開始，如果您在 L1 或 L2 上編制大量數據索引，而且查詢負載相對較低，就像內部商務應用程式一樣。
建置初始索引 ，以判斷源數據如何轉譯為索引。 這是估計索引大小的唯一方法。 欄位定義上的屬性會影響實體記憶體需求：
在入口網站中監視記憶體、服務限制、查詢磁碟區和延遲 。 入口網站會顯示每秒的查詢、節流查詢和搜尋延遲。 所有這些值都有助於您決定是否選取了正確的階層。
新增高可用性的複本，或降低查詢效能變慢。
不需要多少複本來容納查詢負載的指導方針。 查詢效能取決於查詢和競爭工作負載的複雜性。 雖然新增復本顯然會產生較佳的效能，但結果並不嚴格是線性的：新增三個復本不保證三個輸送量。 如需評估解決方案 QPS 的指引，請參閱 分析效能和 監視查詢。
針對反向索引，大小和複雜度是由內容決定，不一定由您饋送至其中的數據量來決定。 具有高備援性的大型數據源可能會導致索引小於包含高度變數內容的較小數據集。 因此，很少可以根據原始數據集的大小來推斷索引大小。
如果您包含永遠不會搜尋的數據，則可以擴大 儲存體 需求。 在理想情況下，檔只包含搜尋體驗所需的數據。
服務等級協議考慮
服務等級協定 （SLA） 未涵蓋免費層和預覽功能。 針對所有計費層，SLA 會在您為服務布建足夠的備援時生效。
兩個或多個複本滿足查詢（讀取）SLA。
三個或多個復本滿足查詢和索引編製（讀寫）SLA。
分割區數目不會影響 SLA。