Azure 認知搜尋中的索引

在 Azure 認知搜尋中, 搜尋索引 是可供搜尋引擎用來編制索引、全文檢索搜尋和篩選查詢的可搜尋內容。 索引是由架構所定義,並儲存至搜尋服務,並遵循資料匯入作為第二個步驟。 除了主要資料存放區之外,此內容存在於您的搜尋服務中,這是新式應用程式中預期之毫秒回應時間的必要專案。 除了特定的索引編制案例之外,搜尋服務永遠不會連線到或查詢您的本機資料。

如果您要建立和管理搜尋索引,本文將協助您瞭解下列各項:

  • 內容 (檔和架構)
  • 實體標記法
  • 基本作業

偏好立即實際操作? 請參閱改為 建立搜尋索引

搜尋索引的內容

在認知搜尋中,索引包含 搜尋檔。 就概念而言,文件是索引中可搜尋資料的單一單位。 例如,零售商可能會有每個產品的檔、新聞群組織可能會有每篇文章的檔、旅遊網站可能有每個旅館和目的地的檔等等。 將這些概念對應至更熟悉的資料庫對等專案: 搜尋索引 相當於 資料表,而 大致相當於資料表中的資料

檔的結構取決於索引架構,如下所示。 「欄位」集合通常是索引的最大部分,其中每個欄位都會命名、指派 資料類型,並使用可允許的行為來屬性來決定其使用方式。

{
  "name": "name_of_index, unique across the service",
  "fields": [
    {
      "name": "name_of_field",
      "type": "Edm.String | Collection(Edm.String) | Edm.Int32 | Edm.Int64 | Edm.Double | Edm.Boolean | Edm.DateTimeOffset | Edm.GeographyPoint",
      "searchable": true (default where applicable) | false (only Edm.String and Collection(Edm.String) fields can be searchable),
      "filterable": true (default) | false,
      "sortable": true (default where applicable) | false (Collection(Edm.String) fields cannot be sortable),
      "facetable": true (default where applicable) | false (Edm.GeographyPoint fields cannot be facetable),
      "key": true | false (default, only Edm.String fields can be keys),
      "retrievable": true (default) | false,
      "analyzer": "name_of_analyzer_for_search_and_indexing", (only if 'searchAnalyzer' and 'indexAnalyzer' are not set)
      "searchAnalyzer": "name_of_search_analyzer", (only if 'indexAnalyzer' is set and 'analyzer' is not set)
      "indexAnalyzer": "name_of_indexing_analyzer", (only if 'searchAnalyzer' is set and 'analyzer' is not set)
      "synonymMaps": [ "name_of_synonym_map" ] (optional, only one synonym map per field is currently supported)
    }
  ],
  "suggesters": [ ],
  "scoringProfiles": [ ],
  "analyzers":(optional)[ ... ],
  "charFilters":(optional)[ ... ],
  "tokenizers":(optional)[ ... ],
  "tokenFilters":(optional)[ ... ],
  "defaultScoringProfile": (optional) "...",
  "corsOptions": (optional) { },
  "encryptionKey":(optional){ }
  }
}

為了簡潔起見,其他元素會折迭,但下列連結可以提供詳細資料:

欄位定義

搜尋檔是由 建立索引要求本文中的「欄位」集合所定義。 您需要 (索引鍵) 、儲存可搜尋文字,以及支援篩選、Facet 和排序的欄位欄位。 您可能也需要使用者從未看到的資料欄位。 例如,您可能想要欄位取得利潤或行銷促銷,以便用來修改搜尋排名。

如果內送資料本質上是階層式資料,您可以在索引內將其表示為 複雜類型,用來表示巢狀結構。 內建的範例資料集 Hotels 說明使用 Address (的複雜類型,其中包含多個子欄位) 每個旅館都有一對一關聯性,以及一個會議室複雜集合,其中多個會議室與每個旅館相關聯。

欄位屬性

欄位屬性會決定欄位的使用方式,例如,是否將它用於全文檢索搜尋、多面向導覽、排序作業等。

字串欄位通常標示為「可搜尋」和「可擷取」。 用來縮小搜尋結果的欄位包括「sortable」、「filterable」 和 「facetable」。

屬性 描述
「searchable」 可進行全文檢索搜尋,受限於語彙分析,例如,在編製索引期間執行斷字功能。 如果您為可搜尋的欄位設定像是「sunny day」的值,則系統會在內部將它分割為「sunny」和「day」這兩個個別的語彙基元。 如需詳細資訊,請參閱全文檢索搜尋如何運作
「filterable」 在 $filter 查詢中加以參考。 類型 Edm.StringCollection(Edm.String) 的可篩選欄位不會執行斷字功能,因此,只會針對完全相符的項目進行比較。 例如,如果您將欄位 f 之類的欄位設為「sunny day」,$filter=f eq 'sunny' 就會找不到相符項目,但 $filter=f eq 'sunny day' 可以。
「sortable」 根據預設,系統會依分數來排序結果,但您可根據文件中的欄位設定排序。 類型的 Collection(Edm.String) 欄位不可「可排序」。
「facetable」 通常用來呈現搜尋結果,其中包含依類別的叫用次數 (例如,特定城市中的旅館)。 此選項無法與類型 Edm.GeographyPoint的欄位搭配使用。 可篩選、可排序或「可多面向」類型的 Edm.String 欄位長度最多可以有 32 KB。 如需詳細資訊,請參閱建立索引 (REST API)
「key」 索引內文件的唯一識別碼。 您必須只選擇一個欄位作為索引鍵欄位,而它的類型必須是 Edm.String
「可擷取」 判斷搜尋結果中是否會傳回該欄位。 當您想要使用某個欄位 (例如 profit margin) 作為篩選、排序或評分機制,但不想讓使用者看見該欄位時,這非常有用。 針對 true for key

雖然您可以隨時新增欄位,但現有的欄位定義會在索引的存留期間加以鎖定。 基於這個理由,開發人員通常會使用入口網站來建立簡單的索引、測試概念,或使用管理入口網站頁面來查詢設定。 如果您遵循以程式碼為基礎的方法,則整個索引設計中頻繁的反覆動作就會更有效率,如此便能讓您輕鬆地重建索引。

注意

您用來建置索引的 API 具有不同的預設行為。 針對 REST API,大部分屬性預設會啟用 (例如,字串欄位的「可搜尋」和「可擷取」是 true) ,而且您通常只需要在關閉它們時設定它們。 若為 .NET SDK,則相反。 在您未明確設定的任何屬性上,預設值是停用對應的搜尋行為,除非您特別啟用它。

實體結構和大小

在 Azure 認知搜尋中,索引的實體結構主要是內部實作。 您可以存取其架構、查詢其內容、監視其大小及管理容量,但叢集本身 (索引、 分區和其他檔案和資料夾) 由 Microsoft 內部管理。

您可以在 Azure 入口網站的 [索引] 索引標籤中監視索引大小,或針對您的搜尋服務發出 GET INDEX 要求 。 您也可以發出 服務統計資料要求 ,並檢查儲存體大小的值。

索引的大小取決於:

  • 檔的數量和組合
  • 個別欄位的屬性
  • 特別是索引組態 (,您是否包含建議工具)

檔組合和數量取決於您選擇匯入的內容。 請記住,搜尋索引應該只包含可搜尋的內容。 如果來源資料包含二進位欄位,除非您使用 AI 擴充來破解和分析內容來建立文字可搜尋的資訊,否則請省略這些欄位。

欄位屬性會決定行為。 為了支援這些行為,編制索引程式會建立必要的資料結構。 例如,「可搜尋」會叫用 全文檢索搜尋,它會掃描標記化字詞的反向索引。 相反地,「可篩選」或「可排序」屬性支援對未修改字串的反復專案。 下一節中的範例會根據選取的屬性顯示索引大小的變化。

建議工具 是支援預先輸入或自動完成查詢的建構。 因此,當您包含建議工具時,索引處理會建立逐字字元比對所需的資料結構。 建議工具會在欄位層級實作,因此請只選擇適用于預先輸入的欄位。

示範屬性和建議工具之儲存含意的範例

下列螢幕擷取畫面說明各種屬性組合所產生的索引儲存模式。 索引是以 實際資產範例索引為基礎,您可以使用 [匯入資料精靈] 和內建的範例資料輕鬆建立。 雖然未顯示索引結構描述,但您可以根據索引名稱推斷屬性。 例如, realestate-searchable 索引已選取 「可搜尋」屬性,而且沒有其他屬性, 而 realestate-擷取 索引則選取 「可擷取」屬性,而沒有其他屬性等等。

Index size based on attribute selection

雖然這些索引變體有點人工,但我們可以參考這些變數,以取得屬性如何影響儲存體的廣泛比較:

  • 「可擷取」不會影響索引大小。
  • 「filterable」、「sortable」、「facetable」 會耗用更多儲存體。
  • 建議工具 可能會增加索引大小,但與螢幕擷取畫面一樣可能指出 (可能讓建議工具感知的所有欄位都已選取,這在大部分索引) 並非可能的案例。

上述表格中也未反映,就是 分析器的影響。 如果您使用 edgeNgram Tokenizer 來儲存字元的逐字序列, (a、ab、abc、abcd) ,索引的大小將會比您使用標準分析器大。

基本作業和互動

既然您已更清楚瞭解索引是什麼,本節將介紹索引執行時間作業,包括連線至及保護單一索引。

注意

管理索引時,請注意沒有入口網站或 API 支援移動或複製索引。 相反地,如果使用相同的索引名稱) ,或修改名稱以在目前的搜尋服務上建立複本,客戶通常會將其應用程式部署解決方案指向不同的搜尋服務 (,然後加以建置。

索引隔離

在認知搜尋中,您將一次使用一個索引,其中所有索引相關的作業都會以單一索引為目標。 沒有相關索引的概念或獨立索引的聯結,可用於編制索引或查詢。

持續可用

索引會持續可用,且無法暫停或離線。 因為它是針對連續作業而設計的,所以其內容的任何更新或索引本身的新增都會即時發生。 因此,如果要求與檔更新一致,查詢可能會暫時傳回不完整的結果。

請注意,檔作業 (重新整理或刪除) 的查詢持續性,以及不會影響目前索引的現有結構和完整性的修改 (,例如新增欄位) 。 如果您需要 (變更現有欄位) 進行結構化更新,這些更新通常會在開發環境中使用卸載和重建工作流程來管理,或在生產服務上建立新版本的索引來管理。

若要避免 索引重建,某些進行小型變更的客戶會藉由建立與舊版並存的新客戶,選擇「版本」欄位。 經過一段時間後,這會導致過時欄位或過時自訂分析器定義形式的孤立內容,特別是在成本高昂的生產索引中。 您可以在索引生命週期管理過程中,解決索引計劃性更新的這些問題。

端點連線和安全性

所有索引編制和查詢要求都會以索引為目標。 端點通常是下列其中一項:

端點 連線和存取控制
<your-service>.search.windows.net/indexes 以索引集合為目標。 建立、列出或刪除索引時使用。 這些作業需要系統管理員許可權,可透過系統管理員 API 金鑰搜尋參與者角色取得。
<your-service>.search.windows.net/indexes/<your-index>/docs 以單一索引的檔集合為目標。 查詢索引或資料重新整理時使用。 對於查詢,讀取權限已足夠,而且可透過查詢 API 金鑰或資料讀取器角色取得。 針對資料重新整理,需要系統管理員許可權。

後續步驟

您可以使用幾乎任何認知搜尋的範例或逐步解說,取得建立索引的實作體驗。 針對入門,您可以從目錄中選擇任何快速入門。

但您也會想要熟悉使用資料載入索引的方法。 索引定義和資料匯入策略會同時定義。 下列文章提供有關建立和載入索引的詳細資訊。