在 Azure 認知搜尋 中建立索引
在Azure 認知搜尋中，查詢要求會以搜尋索引中的可搜尋文字為目標。
在本文中，瞭解定義及發佈搜尋索引的步驟。 建立索引會在搜尋服務上 (資料夾和檔案) 建立實體資料結構。 一旦索引定義存在， 載入索引會 接著做為個別的工作。
必要條件
搜尋服務的寫入權限。 您可以透過要求上的 系統管理員 API 金鑰 來授與許可權。 或者，如果您參與 角色型存取控制公開預覽，您可以將要求發出為搜尋參與者角色的成員。
提供要編制索引之內容的外部資料源。 您應該參考資料源，以瞭解搜尋索引的架構需求。 索引建立主要是架構定義練習。 在建立之前，您應該具備：
清楚瞭解您想要在搜尋索引中讓搜尋、可擷取、可篩選、可多面向和可排序的來源欄位， (請參閱 架構檢查清單 ，以取得指引) 。
來源資料中的唯一欄位，可用來做為索引中的 檔索引鍵 (或識別碼) 。
穩定索引位置。 現成不支援將現有的索引移至不同的搜尋服務。 重新流覽應用程式需求，並確定您現有的搜尋服務、其容量和位置已足以滿足您的需求。
最後，所有服務層級都有您可以建立之物件的 索引限制 。 例如，如果您要在免費層上進行實驗，則在任何指定時間只能有 3 個索引。 在索引本身內，複雜欄位和集合的數目有限制。
檔索引鍵
搜尋索引有一個必要欄位：檔索引鍵。 檔索引鍵是搜尋檔的唯一識別碼。 在Azure 認知搜尋中，它必須是字串，而且它必須源自資料來源中提供要編制索引之內容的唯一值。 搜尋服務不會產生索引鍵值，但在某些情況下， (例如 Azure 資料表索引子) 它會合成現有的值，以針對要編制索引的檔建立唯一索引鍵。
在累加式索引編制期間，只要編制新的和更新的內容，就會新增具有新索引鍵的傳入檔，而具有現有索引鍵的傳入檔則會合並或覆寫，視索引欄位為 Null 或填入而定。
架構檢查清單
使用此檢查清單來協助搜尋索引的設計決策。
檢閱 命名慣例 ，讓索引和功能變數名稱符合命名規則。
檢閱 支援的資料類型。 資料類型會影響欄位的使用方式。 例如，數值內容是可篩選的，但無法搜尋全文檢索。 最常見的資料類型是
Edm.String用於可搜尋的文字，其會使用全文搜尋引擎進行標記化和查詢。識別 檔索引鍵。 檔索引鍵是索引需求。 它是單一字串欄位，而且會從包含唯一值的源資料欄位填入。 例如，如果您要從 Blob 儲存體編制索引，中繼資料儲存體路徑通常會當做檔索引鍵使用，因為它會唯一識別容器中的每個 Blob。
識別資料來源中將參與索引中可搜尋內容的欄位。 可搜尋的內容包含使用全文檢索搜尋引擎查詢的簡短或長字串。 如果內容 (小片語或較大的區塊) ，請試驗不同的分析器以查看文字的標記化方式。
欄位屬性指派 會決定搜尋行為，以及搜尋服務上索引的實體標記法。 判斷應如何指定欄位是許多客戶的反復程式。 若要加速反復專案，請從範例資料開始，以便輕鬆卸載和重建。
識別哪些來源欄位可作為篩選。 數值內容和簡短文字欄位，特別是具有重複值的欄位是不錯的選擇。 使用篩選時，請記住：
可篩選的欄位可以選擇性地用於多面向導覽。
可篩選的欄位會依任意順序傳回，因此也請考慮讓欄位排序。
判斷您將使用預設分析器 ()
"analyzer": null或不同的分析器。 分析器 可用來在編制索引和查詢執行期間標記文字欄位。 如果字串具有描述性和語意豐富，或您已翻譯字串，請考慮使用 語言分析器覆寫預設值。
注意
全文檢索搜尋是透過索引編制期間標記化的字詞進行。 如果您的查詢無法傳回您預期的結果， 請測試權杖化 以確認字串確實存在。 您可以在字串上嘗試不同的分析器，以查看如何為各種分析器產生權杖。
建立索引
當您準備好建立索引時，請使用可傳送要求的搜尋用戶端。 您可以使用 Azure 入口網站 或 REST API 進行早期開發和概念證明測試。
在開發期間，規劃經常重建。 由於實體結構是在服務中建立， 因此卸載和重新建立索引 是許多修改的必要專案。 您可以考慮處理部份的資料，讓重建更快速。
透過入口網站的索引設計會針對特定資料類型強制執行需求和架構規則，例如不允許數值欄位的全文檢索搜尋功能。
在搜尋服務 [概觀] 頁面中，選擇任一選項來建立搜尋索引：
- 新增索引，這是用來指定索引架構的內嵌編輯器
- 匯入資料精靈
精靈是一個端對端工作流程，可建立索引子、資料來源和已完成的索引。 它也會載入資料。 如果這不是您想要的專案，請改用 [新增索引 ]。
下列螢幕擷取畫面醒目提示 [ 新增索引 ] 和 [ 匯入資料 ] 出現在命令列上的位置。 建立索引之後，您可以在 [ 索引] 索引 標籤中再次找到索引。
提示
在入口網站中建立索引之後，您可以複製 JSON 標記法，並將其新增至您的應用程式程式碼。
針對跨原始來源查詢設定 corsOptions
索引架構包含設定 corsOptions 的區段。 用戶端的 JavaScript 預設無法呼叫任何 API，因為瀏覽器會阻止所有跨原始來源的要求。 若要允許對索引進行跨原始來源查詢，請設定 corsOptions 屬性來啟用 CORS (跨原始來源資源共用)。 基於安全性考慮，只有 查詢 API 支援 CORS。
"corsOptions": {
"allowedOrigins": [
"*"
],
"maxAgeInSeconds": 300
您可以為 CORS 設定下列屬性：
allowedOrigins (必要) ：這是將授與索引存取權的來源清單。 這表示將允許來自那些原始來源的所有 JavaScript 程式碼查詢您的索引 (假設它能提供正確的 API 金鑰)。 每個原始來源的形式通常是
protocol://<fully-qualified-domain-name>:<port>(儘管經常會忽略<port>)。 請參閱跨原始來源資源共用以取得詳細資料。如果您想要允許所有原始來源進行存取，請在 allowedOrigins 陣列中包含
*作為單一項目。 這不是生產搜尋服務的建議做法 ，但通常適用于開發和偵錯。maxAgeInSeconds (選擇性) ：瀏覽器會使用此值來判斷 (以秒為單位) 快取 CORS 預檢回應的持續時間。 這必須是非負數的整數。 這個值越大，效能就越好，但是讓 CORS 原則變更生效的時間也就越長。 若未設定，即會使用預設持續期間 5 分鐘。
現有索引上允許的更新
建立索引 會建立實體資料結構， (檔案和搜尋服務上的反轉索引) 。 建立索引之後，您可以使用 更新索引 來影響變更的能力取決於修改是否使這些實體結構失效。 在索引中建立欄位之後，就無法變更大部分的欄位屬性。
或者，您也可以 建立索引別名 ，以作為應用程式程式碼中的穩定參考。 您可以更新索引別名以指向較新的索引版本，而不是更新程式碼。
為了將設計程式中的變換降到最低，下表說明架構中的哪些元素是固定且有彈性的。 變更固定專案需要重建索引，而彈性元素可以隨時變更，而不會影響實體實作。
| 元素 | 可以更新嗎？ |
|---|---|
| 名稱 | No |
| 答案 | No |
| 功能變數名稱和類型 | No |
| 欄位屬性 (可搜尋、可篩選、可 Facet、可排序) | No |
| 欄位屬性 (可堲取) | Yes |
| 分析器 | 您可以在索引中新增和修改自訂分析器。 關於字串欄位的分析器指派，您只能修改 「searchAnalyzer」。 所有其他指派和修改都需要重建。 |
| 評分設定檔 | Yes |
| 建議工具 | No |
| 跨原始來源遠端腳本 (CORS) | 是 |
| 加密 | 是 |
後續步驟
使用下列連結熟悉使用資料載入索引，或使用同義字對應擴充索引。