估計及管理搜尋服務的容量
在 Azure AI 搜尋服務中，容量是以 可調整為工作負載的複 本和數據 分割 為基礎。 複本是搜尋引擎的複本。 分割區是記憶體單位。 每個新的搜尋服務都會以一個開頭，但您可以個別新增或移除複本和分割區，以容納變動的工作負載。 新增容量會增加 執行搜尋服務的成本。
復本和數據分割的實體特性，例如處理速度和磁碟IO，會因服務層級而異。 在標準搜尋服務上，複本和分割區的速度比基本服務更快且更大。
變更容量並非瞬間。 最多可能需要一個小時才能委託或解除委任數據分割，特別是對於具有大量數據的服務。
調整搜尋服務時，您可以從下列工具和方法中選擇：
概念：搜尋單位、複本、分割區、分區
容量是以可組合分割區和複本來配置的搜尋單位來表示，使用基礎分區化機制來支援彈性組態：
| 概念 | 定義 |
|---|---|
| 搜尋單位 | 可用容量總計的單一增量（36 個單位）。 這也是 Azure AI 搜尋服務 的計費單位。 執行服務至少需要一個單位。 |
| 複本 | 搜尋服務的實例，主要用於負載平衡查詢作業。 每個複本都會裝載一份索引複本。 如果您配置三個複本，則有三份索引複本可供服務查詢要求。 |
| 資料分割 | 讀取/寫入作業的實體記憶體和 I/O（例如，重建或重新整理索引時）。 每個分割區都有總計索引的配量。 如果您配置三個分割區，索引會分割成第三個數據分割。 |
| 碎片 | 索引的區塊。 Azure AI 搜尋會將每個索引分成分區，以加快新增分割區的程式（將分區移至新的搜尋單位）。 |
下圖顯示複本、分割區、分區和搜尋單位之間的關聯性。 它示範單一索引如何跨越服務中具有兩個複本和兩個分割區之四個搜尋單位的範例。 這四個搜尋單位中的每一個只會儲存索引分區的一半。 左數據行中的搜尋單位會儲存分區的前半部，包含第一個分割區，而右數據行中的搜尋單位則儲存分區的後半部，由第二個分割區組成。 由於有兩個複本，因此每個索引分區都有兩個複本。 頂端數據列儲存一個複本的搜尋單位，其中包含第一個複本，而底部數據列的搜尋單位則儲存另一個複本，其中包含第二個複本。
上圖只是一個範例。 許多數據分割和複本的組合都是可能的，最多最多 36 個搜尋單位。
在 Azure AI 搜尋中，分區管理是實作詳細數據和不可設定的，但知道索引已分區化有助於瞭解排名和自動完成行為的偶爾異常：
排名異常：搜尋分數會先在分區層級計算，然後再匯總成單一結果集。 根據分區內容的特性，來自某個分區的相符專案可能會排名高於另一個分區中的相符專案。 如果您注意到搜尋結果中的計數器直覺式排名，很可能是因為分區化的影響，特別是索引很小時。 您可以選擇在整個索引中全域計算分數，以避免這些排名異常，但這樣做會造成效能損失。
自動完成異常：自動完成查詢，其中比對是在部分輸入字詞的前幾個字元進行，接受模糊參數，原諒拼字中的小偏差。 針對自動完成，模糊比對受限於目前分區內的詞彙。 例如，如果分區包含 「Microsoft」，並輸入部分字詞 「micro」 ，則搜尋引擎會在該分區中的 「Microsoft」 上比對，但在保留索引其餘部分的其他分區中則不相符。
估計目標
容量規劃必須包含物件限制（例如，服務上允許的索引數目上限）和記憶體限制。 服務層級會 決定物件和記憶體限制。 先達到哪一個限制是有效限制。
索引和其他物件的計數通常是由商務和工程需求決定。 例如，您可能有多個版本的相同索引，以供使用中開發、測試和生產環境使用。
儲存體 需求取決於您預期建置的索引大小。 沒有紮實的啟發學習法或一般性有助於估計。 判斷索引 大小的唯一方法是組建一個。 其大小會以匯入的數據、文字分析和索引設定為基礎，例如您是否啟用建議工具、篩選和排序。
對於全文搜索，主要數據結構是 反向索引 結構，其特性與源數據不同。 針對反向索引，大小和複雜度是由內容決定，不一定由您饋送至其中的數據量來決定。 具有高備援性的大型數據源可能會導致索引小於包含高度變數內容的較小數據集。 因此，很少可以根據原始數據集的大小來推斷索引大小。
索引上的屬性，例如啟用篩選和排序，會影響記憶體需求。 使用建議工具也有儲存含意。 如需詳細資訊，請參閱 屬性和索引大小。
注意
即使估計索引和記憶體的未來需求可能像是猜測，但值得這麼做。 如果階層的容量變得太低，您必須在較高層布建新的服務，然後 重載您的索引。 沒有任何服務從一層升級到另一層的就地升級。
使用免費層估計
評估容量的其中一種方法是從免費層開始。 請記住，免費服務最多可提供三個索引、50 MB 的記憶體，以及 2 分鐘的編製索引時間。 使用這些條件約束來估計投影的索引大小可能很困難，但這些步驟如下：
準備小型代表性數據集。
建立索引並載入您的數據。 如果數據集可以裝載在索引器支援的 Azure 數據源中，您可以使用 入口網站中的 匯入數據精靈來建立和載入索引。 否則，您可以使用 REST API 來建立索引並推送數據。 推送模型需要數據格式為 JSON 檔，其中檔中的欄位會對應至索引中的欄位。
收集索引的相關信息，例如大小。 功能和屬性會影響記憶體。 例如，新增建議工具（搜尋即用類型查詢）會增加記憶體需求。
使用相同的數據集，您可以嘗試建立多個版本的索引，並在每個欄位使用不同的屬性，以查看記憶體需求的差異。 如需詳細資訊，請參閱建立基本索引中的<儲存體 含意>。
使用粗略估計，您可能會將兩個索引的預算金額加倍（開發和生產），然後據以選擇您的階層。
可計費層的估計
專用資源可以容納較大的取樣和處理時間，以在開發期間更實際地估計索引數量、大小和查詢磁碟區。 有些客戶會直接進入計費層，然後在開發專案成熟時重新評估。
檢閱每個層級 的服務限制，以判斷較低層是否可以支援您需要的索引數目。 在基本、S1 和 S2 層中，索引限制分別為 15、50 和 200。 儲存體 優化層的限制為10個索引，因為它的設計目的是支援非常大型的索引數目。
在可計費層建立服務：
- 如果您不確定投影的負載，請從基本或 S1 低開始。
- 如果測試包含大規模的索引編製和查詢載入，請從 S2 或甚至 S3 開始高。
- 從 儲存體 Optimized 開始，如果您在 L1 或 L2 上編制大量數據索引，而且查詢負載相對較低，就像內部商務應用程式一樣。
建置初始索引 ，以判斷源數據如何轉譯為索引。 這是估計索引大小的唯一方法。
在入口網站中監視記憶體、服務限制、查詢磁碟區和延遲 。 入口網站會顯示每秒的查詢、節流查詢和搜尋延遲。 所有這些值都有助於您決定是否選取了正確的階層。
新增高可用性的複本，或降低查詢效能變慢。
不需要多少複本來容納查詢負載的指導方針。 查詢效能取決於查詢和競爭工作負載的複雜性。 雖然新增復本顯然會產生較佳的效能，但結果並不嚴格是線性的：新增三個復本不保證三個輸送量。 如需評估解決方案 QPS 的指引，請參閱 分析效能和 監視查詢。
注意
如果您包含永遠不會搜尋的數據，則可以擴大 儲存體 需求。 在理想情況下，檔只包含搜尋體驗所需的數據。 二進位數據無法搜尋，而且應該分開儲存（可能儲存在 Azure 數據表或 Blob 記憶體中）。 然後，應該在索引中加入字段，以保存外部數據的 URL 參考。 個別搜尋檔的大小上限為 16 MB（如果您以一個要求大量上傳多個檔，則更少）。 如需詳細資訊，請參閱 Azure AI 搜尋中的服務限制。
查詢磁碟區考慮
每秒查詢 （QPS） 是效能微調期間的重要計量，但對於容量規劃而言，只有在您一開始就預期查詢量很高時，才會成為考慮事項。
標準層可以提供複本和數據分割的平衡。 您可以新增用於負載平衡的複本，或新增數據分割以進行平行處理，藉以增加查詢回合。 接著，您可以在布建服務之後微調效能。
如果您預期一開始就會有高持續查詢磁碟區，您應該考慮更高的標準層，由更強大的硬體支援。 然後，如果這些查詢磁碟區未發生，您可以將分割區和複本脫機，或甚至切換至較低層的服務。 如需如何計算查詢輸送量的詳細資訊，請參閱 監視查詢。
儲存體 優化層適用於大型數據工作負載，可支援較不重要的查詢延遲需求時，較整體可用的索引記憶體。 您仍然應該使用其他復本來進行負載平衡，而其他分割區則用於平行處理。 接著，您可以在布建服務之後微調效能。
服務等級協定
服務等級協定 （SLA） 未涵蓋免費層和預覽功能。 針對所有計費層，SLA 會在您為服務布建足夠的備援時生效。 您需要有兩個以上的複本來進行查詢（讀取）SLA。 您需要有三個以上的複本來查詢和編製索引（讀寫）SLA。 分割區數目不會影響 SLA。
容量規劃的 提示
允許計量圍繞查詢建置，並收集使用模式的數據（在上班時間期間查詢，在離峰時段編製索引）。 使用此數據來通知服務布建決策。 雖然在每小時或每日頻率上並不實用，但您可以動態調整數據分割和資源，以因應查詢磁碟區中規劃的變更。 如果層級夠長，足以保證採取行動，您也可以容納非計劃性但持續變更。
請記住，布建下的唯一缺點是，如果實際需求大於您的預測，您可能必須卸除服務。 為了避免服務中斷，您會在較高層級建立新的服務，並排執行它，直到所有應用程式和要求都以新端點為目標為止。
新增容量的時機
一開始，服務會配置由一個分割區和一個複本組成的最小層級資源。 您選擇的階層會決定分割區大小和速度，而且每個層都會針對一組符合各種案例的特性進行優化。 如果您選擇較高階層，則 可能需要比使用 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 加密的索引，其金鑰不再有效。 您應該刪除索引或還原索引鍵，讓索引重新上線並解除封鎖調整作業。
數據分割和復本組合
在 2024 年 4 月 3 日之前建立的搜尋服務上：基本可以有一個分割區和最多三個複本，上限為三個 SU。 唯一可調整的資源是複本。
在支援區域中於 2024 年 4 月 3 日之後建立的搜尋服務：基本最多可以有三個分割區和三個複本。 最大 SU 限制為 9，可支援分割區和複本的完整補充。
對於任何計費層上的搜尋服務，不論建立日期為何，您至少需要兩個複本，才能在查詢上取得高可用性。
所有標準和 儲存體 優化搜尋服務都可以假設下列復本和分割區組合，但受限於這些層允許的 36-SU 限制。
| 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 |
Azure 網站上會詳細說明 SU、定價和容量。 如需詳細資訊，請參閱 定價詳細數據。
注意
復本和數據分割的數目平均分成 12 個（特別是 1、2、3、4、6、12）。 Azure AI 搜尋會將每個索引預先分割成 12 個分區，以便將其分散到所有分割區中的相等部分。 例如，如果您的服務有三個數據分割，而您建立索引，則每個分割區都會包含索引的四個分區。 Azure AI 搜尋如何分區索引是實作詳細數據，未來版本可能會有所變更。 雖然數位是今天 12，但您不應該預期該數位在未來一律為 12。