在 Azure AI 搜尋服務中排程索引子

設定 schedule 屬性，將索引子設定為依排程執行。 索引器排程在以下情境下非常有用：

• 來源資料會隨時間改變，你希望索引器能自動處理差異。
• 來源資料非常大，您需要週期性排程才能編製所有內容的索引。
• 索引會使用多個索引子，從多個來源填入資料，而您想要錯開這些作業以減少衝突。

當索引無法在 典型的 2 小時處理時間內完成時，可以安排索引器以 2 小時的頻率來處理大量資料。 只要您的資料來源支援變更偵測邏輯，索引子在每次執行時便可自動從上次結束的位置繼續。

一旦你把索引器放進排程，它就會一直留在排程上，直到你清除區間、開始時間，或設定 disabled 為 true。 如果排程索引器突然停止觸發，請參考 排程行為常見問題 解答以了解復原步驟。 即使沒有任何項目需要處理，讓索引器維持排程執行也不會影響系統效能。 檢查變更的內容是相對快速的作業。

先決條件

• 使用資料來源和索引設定的有效索引子。

• 資料來源中的變更偵測。 Azure 儲存體和 SharePoint 已內建變更偵測。 對於其他資料來源，如 Azure SQL 和 Azure Cosmos DB，你必須手動啟用變更偵測。

排程定義

排程是索引子定義的一部分。 如果你省略了這個 schedule 屬性，索引器就只會在需要時執行。 此屬性具有兩個部分。

下列範例是一個排程，從 1 月 1 日午夜開始，每隔兩小時執行一次。

{
    "dataSourceName" : "hotels-ds",
    "targetIndexName" : "hotels-idx",
    "schedule" : { "interval" : "PT2H", "startTime" : "2024-01-01T00:00:00Z" }
}

設定排程

在索引器定義中指定排程。 要設定排程，請使用 Azure 入口網站、REST API 或 Azure SDK。

var schedule = new IndexingSchedule(TimeSpan.FromDays(1))
{
    StartTime = DateTimeOffset.Now
};

var indexer = new SearchIndexer("demo-idxr", dataSource.Name, searchIndex.Name)
{
    Description = "Demo data indexer",
    Schedule = schedule
};

await indexerClient.CreateOrUpdateIndexerAsync(indexer);

排程行為常見問題

我可以平行執行多個索引子作業嗎？

你可以同時執行多個索引器，但每個索引器都是單一實例。 您無法同時執行相同索引子的兩個複本。

對於以文字為基礎的索引，排程器可啟動搜尋服務所支援的那麼多個索引子作業，而此數量取決於 搜尋單位 的數量。 例如，如果服務具有三個複本和四個分割區，您可以在作用中執行內包含 12 個索引子作業，無論是視需要起始還是依排程起始都一樣。

針對以技能為基礎的編製索引，索引子會在特定的執行環境中執行。 因此，服務單位數量不會影響你能執行的技能型索引工作數量。 多個技能型索引子可以平行執行，但這樣做取決於執行環境中的內容處理器可用性。

排程的作業一律會在指定的時間開始嗎？

索引程序可能會排隊，且可能不會在發帖時間精確啟動，視處理工作負載及其他因素而定。 例如，如果索引器在下一次排程執行被設定為開始時仍在運行，待處理的執行會被延後到下一次排程事件，讓目前的工作得以完成。

為了讓這種行為更具體，請考慮以下範例。 假設你設定一個索引器排程，間隔為每小時，開始時間為 2024 年 1 月 1 日 UTC 上午 8：00：00。 以下是索引子執行若超過一小時，可能發生的情況：

1. 第一次索引子執行於或約於 2024年 1 月 1 日上午 8:00 UTC 開始。 假設此執行需要 20 分鐘 (或少於 1 小時的時間量)。

2. 第二次執行於或約於 2024 年 1 月 1 日上午 9:00 UTC 開始。 假設這個執行需要 70 分鐘——超過一小時——而且要到 UTC 上午 10：10 才完成。

3. 第三次執行排程為從上午 10:00 UTC 開始，但先前的執行當時仍在執行中。 然後會略過此排程的執行。 索引器的下一次執行要到 UTC 上午 11：00 才開始。

在少數情況下，例如進行維護或從暫時性狀況復原時，系統會將多個索引子執行排入佇列。 當此情況發生時，索引器會在排程視窗內依序執行待處理的工作負載。 例如，如果某個索引器排定為每小時執行一次，且有數次執行延遲或被隨選觸發，這些排入佇列的作業會一個接一個地執行，直到佇列清空。 這些執行作業不是額外新增的，而是先前已排程或已要求的執行作業。 雖然此行為在大部分案例中並不常見，但索引子的設計目的是最終處理所有佇列工作，以維持一致性和資料新鮮度。

如果在同一份文件上重複編製索引失敗，會發生什麼事？

如果您為索引器設定了特定排程，但它每次都在同一個文件上失敗，索引器就會開始改為以較低頻率執行（最長間隔為每 2 小時一次或每 24 小時一次，取決於不同的實作因素），直到再次成功取得進展為止。 如果你認為已經解決了根本問題，請 手動執行索引器。 若索引成功，索引器會回到其正常排程。 如果索引器在成功手動執行後仍未恢復正常排程，請參考下一個問題。

排程的索引子已停止觸發。 我該如何重置它的排程？

如果排程索引器停止運行，先停用再重新啟用以重設排程。 這是需要這種復原的徵兆：即使排程已設定且資料來源已更改，執行歷史中也沒有新的執行紀錄。

設定 disabled 為 true 則暫停排程。 將時間設回 false （或省略該屬性）後，會恢復排程，並以當前時間作為設定區間的新基準線。

後續步驟

對於排程執行的索引器，你可以透過從搜尋服務取得狀態來監控操作，或透過啟用資源記錄來獲得詳細資訊。

• 監視搜尋索引子狀態
• 收集和分析記錄資料
• 索引大型資料集