提升 Azure AI 搜尋服務效能的秘訣
本文收集了有關提高關鍵字搜尋的查詢和編製索引效能的秘訣和最佳做法。 了解哪些因素最有可能影響搜尋效能，有助於避免效率低落，並且能充分利用您的搜尋服務。 主要因素包括：
- 索引組合 (結構描述和大小)
- 查詢設計
- 服務容量 (層級，以及複本和分割區的數目)
注意
在尋找大量編製索引的策略嗎？ 請參閱在 Azure AI 搜尋服務中為大型資料集編製索引。
索引大小和結構描述
查詢在較小的索引上執行得較快。 這一部分是歸因於要掃描的欄位較少，但也與系統快取內容以供未來查詢之用的方式有關。 在第一次查詢後，某些內容會保留在記憶體中，因此搜尋起來會更有效率。 索引大小通常會隨著時間成長，因此最佳做法之一，是定期重新審視索引組合 (包括結構描述和文件)，以尋求縮減內容的機會。 不過，如果索引的大小適當，則唯一可進行的校正將是增加容量：藉由新增複本或升級服務層級來達成。 「提示：升級至標準 S2 層」一節會討論擴大與擴增的決策有何不同。
結構描述複雜度也可能對索引編製和查詢效能造成負面影響。 過度的欄位歸因將形成限制和處理需求。 複雜類型的索引編製和查詢需要較長的時間。 後續幾節將探討各種情況。
提示：慎選欄位歸因
管理員和開發人員在建立搜尋索引時常犯的錯誤，是選取欄位所有的可用屬性，而不是僅選取所需的屬性。 例如，如果某個欄位不必是可全文檢索搜尋的，在設定可搜尋的屬性時即應略過該欄位。
為了支援篩選、Facet 和排序，儲存體需求可能會提高三倍。 如果再加上建議工具，儲存體需求將進一步提高。 如需關於屬性對儲存體有何影響的說明，請參閱屬性和索引大小。
總結來說，過度歸因的後果包括：
因處理欄位中的內容，然後將其儲存在搜尋反向索引內需要額外的工作，而導致索引編製效能下降 (僅在包含可搜尋內容的欄位上設定 「可搜尋」屬性)。
建立每個查詢必須涵蓋的較大範圍。 所有標示為可搜尋的欄位，在全文檢索搜尋中都會受到掃描。
因額外的儲存體而增加營運成本。 篩選和排序需要額外的空間來儲存原始 (非分析) 字串。 請避免在不需要可篩選或可排序的欄位上進行這些設定。
在許多情況下，過度歸因會限制欄位的功能。 例如，如果欄位是可面向化、可篩選且可搜尋的，則您只能在該欄位中儲存 16 KB 的文字，而可搜尋的欄位最多則可保存 16 MB 的文字。
注意
非必要的歸因才需要避免。 篩選和 Facet 對搜尋體驗而言往往至關重要，且在使用篩選的情況下，您常需使用排序，以便能對結果排序 (篩選本身會傳回未排序的結果集)。
提示：考量複雜類型的替代方案
若資料具有複雜的巢狀結構 (例如 JSON 文件中的父子元素)，複雜資料類型將有其效用。 相較於非複雜資料類型，複雜類型的缺點是會產生額外的儲存體需求，且需要額外的資源來編製內容的索引。
在某些情況下，您可以將複雜的資料結構對應至較簡單的欄位類型 (例如集合)，以避免這些缺點。 或者，您可以選擇將欄位階層扁平化為個別的根層級欄位。
查詢設計
查詢組合和複雜度是影響效能最重要的因素之一，查詢最佳化可以大幅改善效能。 設計查詢時，請考慮下列幾點：
可搜尋的欄位數目。 每個額外的可搜尋欄位，都會為搜尋服務帶來更多工作。 您可以使用 "searchFields" 參數來限制查詢時搜尋的欄位。 最好只指定您關注的欄位，以改善效能。
傳回的資料量。 擷取大量內容會導致查詢速度變慢。 建構查詢時，只傳回您呈現結果頁面所需的欄位，然後在使用者選取相符項之後，使用查閱 API 擷取其餘欄位。
用於部分字詞搜尋。部分字詞搜尋，例如前置詞搜尋、模糊搜尋和規則運算式搜尋，的運算成本比一般關鍵字搜尋更高，因為這類搜尋需要完整索引掃描才能產生結果。
Facet 的數目。 將 Facet 新增至查詢需要彙總每個查詢。 對 Facet 要求越高的「計數」，服務也需要執行更多工作。 一般而言，請只新增您打算在應用程式中呈現的 Facet，除非必要，避免對 Facet 要求太高計數。
高略過值。 將
$skip參數的值設定太高 (例如數千個) 會增加搜尋延遲，因為引擎需要針對每個要求來擷取和排名更大量文件。 基於效能理由，最好避免太高的$skip值，並改用其他技術 (例如篩選) 來擷取大量文件。避免高基數欄位。 「高基數欄位」是指具有大量唯一值，以致在計算結果時耗用大量資源的可面向化或可篩選欄位。 例如，設定為可面向化和可篩選的 [產品識別碼] 或 [描述] 欄位，將被視為高基數欄位，因為大多數的值在文件間都是唯一的。
提示：使用搜尋函式而非多載篩選準則
當查詢使用越來越複雜的篩選準則時，搜尋查詢的效能將會下降。 下列範例說明如何使用篩選根據使用者身分識別修剪結果，請加以考量：
$filter= userid eq 123 or userid eq 234 or userid eq 345 or userid eq 456 or userid eq 567
此案例使用篩選運算式來檢查每個文件中的單一欄位是否等於使用者身分識別眾多可能值的其中之一。 在實作安全性修剪的應用程式中最有可能出現此模式 (核對包含一或多個主體識別碼的欄位，與代表發出查詢之使用者的主體識別碼清單)。
執行包含大量值的篩選時，更有效率的方式是使用 search.in 函式，如下列範例所示：
search.in(userid, '123,234,345,456,567', ',')
提示：為緩慢的個別查詢新增分割區
當查詢效能整體而言變慢時，新增更多複本通常可解決問題。 但是，如果問題是完成單一查詢太過耗時，該如何處理？ 在此情況下，新增複本將無濟於事，增加分割區則可能有幫助。 分割區可將資料分散到額外的計算資源間。 兩個分割區會將資料分成兩半，三個分割區則會分成三份，依此類推。
新增分割區有一個正面的副作用，即較慢的查詢有時會因為平行運算加快執行速度。 我們已在低度選擇性查詢上注意到平行處理，例如，比對許多文件的查詢，或提供大量文件之計數的 Facet。 由於需要大量計算才能對文件的相關性進行評分，或計算文件數目，因此新增額外的分割區將有助於更快完成查詢。
若要新增分割區，請使用 Azure 入口網站、PowerShell、Azure CLI 或管理 SDK。
服務容量
當查詢耗時過久或服務開始卸除要求時，即表示服務負擔過重。 發生這種情況時，可藉由升級服務或新增容量來解決問題。
搜尋服務的層級和複本/分割區的數目對於效能也有很大的影響。 每個漸進升高的層級都會提供更快的 CPU 和更多記憶體，而兩者都對效能有正面影響。
提示：建立新的高容量搜尋服務
在 2024 年 4 月 3 日之後在支援的區域中建立的基本和標準服務，每個分割區的儲存體比舊版服務多。 升級至較高層級和較高計費費率之前，請重新瀏覽層服務限制，以查看較新服務上的同一層級是否提供必要的儲存體。
提示：升級至標準 S2 層
客戶常會從標準 S1 搜尋層開始。 S1 服務的常見模式是索引隨著時間成長，而需要更多分割區。 更多分割區會導致回應時間變慢，因此須新增更多複本來處理查詢負載。 如您所設想的，執行 S1 服務的成本現已超出初始設定的水準。
此時應提出的重要問題是，相較於逐步增加目前服務的分割區或複本數目，移轉至更高層級是否會有幫助。
請將下列拓撲視為採用了更高容量層級的服務範例：
- 標準 S1 層
- 索引大小：190 GB
- 分割區計數：8 (在 S1 上，每個分割區的分割區大小為 25 GB)
- 複本計數：2
- 搜尋單位總計：16 (8 個分割區 x 2 個複本)
- 假設零售價格：約 4,000 美元/月 (假設 250 美元 x 16 個搜尋單位)
假設服務管理員仍看到較高的延遲率，並考慮再新增一個複本。 這會使複本計數從 2 變更為 3，因而將搜尋單位計數變更為 24，最終價格為 6,000 美元/月。
不過，如果管理員選擇移轉至標準 S2 層，拓撲將顯示如下：
- 標準 S2 層
- 索引大小：190 GB
- 分割區計數：2 (在 S2 上，每個分割區的分割區大小為 100 GB)
- 複本計數：2
- 搜尋單位總計：4 (2 個分割區 x 2 個複本)
- 假設零售價格：約 4,000 美元/月 (1000 美元 x 4 個搜尋單位)
正如這個假設案例所示，在較低層級上設定所產生的成本，可能會與一開始就選擇較高層級差不多。 但較高的層級隨附進階儲存體，可加快編製索引的速度。 較高層級的計算能力也高出許多，而且還有額外的記憶體。 在相同成本下，您將有更強大的基礎結構來支援相同的索引。
增加記憶體的一大優點是可以快取更多索引，進而降低搜尋延遲，並提高每秒的查詢數目。 多了這項助力，管理員可能連增加複本計數都不需要，且支付的費用可能比使用 S1 服務還少。
秘訣：考慮規則運算式查詢的替代方案
規則運算式查詢或 regex 可能特別昂貴。 雖然它們對於進階搜尋非常有用，但執行可能需要大量的處理能力，特別是當規則運算式很複雜，或是您正在搜尋大量資料時。 所有這些因素都會導致較高的搜尋延遲。 作為緩解措施，請嘗試簡化規則運算式，或將複雜的查詢細分為更小、更易於管理的查詢。
下一步
檢閱下列與服務效能相關的其他文章：