在 Azure AI 搜尋服務中為大型資料集編製索引
如果您的搜尋解決方案需求包括編製巨量資料或複雜資料的索引，本文會說明在 Azure AI 搜尋服務上容納長時間執行處理序的策略。
本文假設您熟悉匯入資料的兩種基本方法：將資料推送至索引，或使用搜尋索引子從支援的資料來源提取資料。 如果您的案例牽涉到需要大量計算的 AI 擴充，由於技能組相依於索引子，因此必須使用索引子。
本文會補充改善效能的秘訣，該文章提供索引和查詢設計的最佳做法。 設計完善的索引只會包含您需要的欄位和屬性，這是大規模索引編製的重要先決條件。
我們建議使用較新的搜尋服務，在 2024 年 4 月 3 日之後建立，以取得 每個分割區的較高記憶體。
注意
本文所述的策略是以單一大型資料來源為前提。 如果您的解決方案需要編製來自多個資料來源的索引，請參閱在 Azure AI 搜尋服務中為多個資料來源編製索引以了解建議的方法。
使用推送 API 編製大型資料的索引
「推送」API，例如文件索引 REST API 或 IndexDocuments 方法 (Azure SDK for .NET)，屬於 Azure AI 搜尋服務中最普遍的索引編製形式。 對於使用推送 API 的解決方案，長時間執行索引編製的策略將採用下列其中一個或兩個元件：
- 批次處理文件
- 管理執行緒
每個要求批次處理多份文件
編製大量資料索引的一個簡單機制，便是在單一要求中提交多個文件或記錄。 只要整個承載的大小在 16 MB 以內，要求便可以在大量上傳作業中處理多達 1000 個文件。 無論您是使用文件編製索引 REST API 還是使用 .NET SDK 中的 IndexDocuments 方法，這些限制都適用。 針對任一 API，您會在每個要求的本文中封裝 1000 份文件。
批次處理文件會大幅縮短處理大量資料所需的時間。 為您的資料決定最佳批次大小是將索引編製速度最佳化的關鍵要素。 影響最佳批次大小的兩個主要因素如下：
- 索引的結構描述
- 資料的大小
由於最佳批次大小取決於索引和資料，因此最好的方法是測試不同批次大小，以判斷在您所處的情況下，能達到最快編製索引速度的批次大小。 教學課程：使用推送 API 最佳化編制索引提供範例程式碼，以使用 .NET SDK 測試批次大小。
新增執行緒和重試策略
索引子具有內建執行緒管理，但當您使用推送 API 時，您的應用程式碼必須管理執行緒。 請確定有足夠的執行緒可以充分利用可用的容量，特別是如果您最近增已加分割區或已升級至較高層級的搜尋服務。
在您的用戶端程式碼中增加並行執行緒數目。
當您增加點擊搜尋服務的要求時，您可能會遇到 HTTP 狀態碼，指出要求並未完全成功。 在索引編製期間，兩個常見的 HTTP 狀態碼如下：
503 服務無法使用 - 此錯誤表示系統負載過重，因此目前無法處理要求。
207多重狀態 - 此錯誤表示有些文件成功，但至少有一個文件失敗。
若要處理失敗，應該使用指數輪詢重試策略來重試要求。
Azure .NET SDK 會自動重試 503 和其他失敗的要求，但您必須實作自己的邏輯才能重試 207。 您也可以使用 Polly 等開放原始碼工具來實作重試策略。
使用索引子和「提取」API 編製索引
索引子有數個功能，適用於長時間執行的處理序：
- 批次處理文件
- 分割資料的平行編製索引
- 排程和變更偵測，只逐步編製新增和變更文件的索引
索引子排程可從上一個已知停止點繼續處理。 假如使用提供變更偵測的資料來源，當資料未在處理視窗中完整編製索引時，索引子在下次執行時會從離開的位置繼續處理。
將資料分割成較小的個別資料來源可實現平行處理作業。 您可以將來源資料分割成 Azure Blob 記憶體中的多個容器、為每個分割區建立資料來源，然後平行執行索引子，但會受限於搜尋服務的搜尋單位數目。
檢查索引子批次大小
如同推送 API 一樣，索引子可讓您設定每個批次的項目數目。 針對以建立索引子 REST API 為基礎的索引子，您可以設定 batchSize 引數以自訂此設定，以便更加符合資料的特性。
預設批次大小是資料來源特定的。 Azure SQL Database 和 Azure Cosmos DB 的預設批次大小為 1000。 相較之下，Azure Blob 索引編製作業會在發現平均文件大小較大時，將批次大小設定為 10 個文件。
排程長時間執行流程的索引子
索引子排程是一種重要機制，用於處理大型資料集以及容納緩慢執行的流程 (例如，擴充管線中的影像分析)。
一般而言，索引子處理時間在 2 小時內。 如果編製索引工作負載無法在數小時完成，而需要數天時間，您可以將索引子放在每隔兩小時啟動的連續週期性排程上。 假設資料來源已啟用變更追蹤，索引子會從上次離開的位置繼續處理。 依此步調，索引子可在數天內陸續處理待處理項目，直到所有未處理的文件都完成為止。
{
"dataSourceName" : "hotels-ds",
"targetIndexName" : "hotels-idx",
"schedule" : { "interval" : "PT2H", "startTime" : "2024-01-01T00:00:00Z" }
}
當資料來源中已無任何新增或更新的文件時，索引子執行歷程記錄會報告已處理 0/0 個文件，且不會進行任何處理。
如需設定排程的詳細資訊，請參閱建立索引子 REST API，或參閱如何針對 Azure AI 搜尋服務排程索引子。
注意
在舊版執行階段結構上執行的部分索引子的處理時間範圍上限為 24 小時，而不是 2 小時。 2 小時的限制適用於在內部受控多租用戶環境中執行的較新內容處理器。 在可能的情況下，Azure AI 搜尋服務會嘗試將索引子和技能集處理卸除至多租用戶環境。 如果索引子無法移轉，則會在私人環境中執行，而且可以執行長達 24 小時。 如果您要排程具備這些特性的索引子，請以 24 小時的處理時間範圍為準。
平行執行索引子
如果您分割資料，則可以建立多個索引子-資料-來源組合，從每個資料來源提取資料並寫入至相同的搜尋索引。 因為每個索引子都不同，所以您可以同時執行，這比依序執行搜尋索引更快填入搜尋索引。
確定您有足夠的容量。 服務中的單一搜尋單位一次只能執行一個索引子。 只有在多個索引子能以平行的方式執行時，建立多個索引子才會很有用。
可以同時執行的編製索引作業數目會由於文字型和技能型索引而有所不同。 如需詳細資訊，請參閱索引子執行。
如果您的資料來源是 Azure Blob 儲存體容器或 Azure Data Lake Storage Gen 2，列舉大量 Blob 可能需要很長的時間 (甚至數小時)，直到此作業完成為止。 這會導致索引子的文件成功計數在該時間期間未增加，而且在進行時似乎沒有任何進度。 如果您想要針對大量 Blob 進行更快的文件處理，請考慮將資料分割成多個容器，並建立指向單一索引的平行索引子。
登入 Azure 入口網站，並檢查搜尋服務所使用的搜尋單位數目。 選取 [設定]>[調整] 以檢視頁面頂端的數字。 將平行執行的索引子數目大約等於搜尋單位的數目。
在多個容器之間或在相同容器內多個虛擬資料夾之間分割資料。
在每個索引子中指定相同的目標搜尋索引。
排程索引子。
檢閱索引子狀態和執行歷程記錄以進行確認。
有一些與平行編制索引相關聯的風險。 首先，回想一下，編製索引不會在背景執行，這增加查詢受到節流或捨棄的可能性。
其次，Azure AI 搜尋服務不會鎖定更新的索引。 並行寫入會加以管理，如果特定寫入在第一次嘗試時未成功，則會叫用重試，但您可能會注意到編製索引失敗的次數增加。
雖然多個索引子-資源-來源集合可以將相同的索引設為目標，但請小心可能覆寫索引中現有值的索引子執行。 如果第二個索引子-資源-來源將相同的文件和欄位設為目標，則會覆寫第一次執行中的任何值。 欄位值會以完整方式取代；索引子無法將多個執行中的值合併到相同的欄位。
在 Spark 上編製巨量資料的索引
如果您有巨量資料架構，且資料位於 Spark 叢集上，建議使用 SynapseML 來載入和編製資料索引。 本教學課程包含呼叫 Azure AI 服務以進行 AI 擴充的步驟，但您也可以使用 AzureSearchWriter API 進行文字索引編製。