將Documentdb導入到Azure搜索時處理索引器超時

我試圖將相當大（〜200M文檔）documentdb導入到Azure搜索中，但我在〜24小時後發現索引器超時。當索引器重新啓動時，它會從頭開始重新開始，而不是從開始的位置開始，這意味着我無法在搜索索引中獲得超過40M的文檔。數據源具有如下高水位標記：將Documentdb導入到Azure搜索時處理索引器超時

 var source = new DataSource(); 
     source.Name = DataSourceName; 
     source.Type = DataSourceType.DocumentDb; 
     source.Credentials = new DataSourceCredentials(myEnvDef.ConnectionString); 
     source.Container = new DataContainer(myEnvDef.CollectionName, QueryString); 
     source.DataChangeDetectionPolicy = new HighWaterMarkChangeDetectionPolicy("_ts"); 
     serviceClient.DataSources.Create(source);

當在小分貝上測試時，高位標記似乎正常工作。

當索引器失敗時，是否應該遵守高位標記？如果不是，我該如何索引如此龐大的數據集？

來源

2016-09-19 Iain Brown

索引不使即使在24小時（24小時執行時間限制，預計）後超時增量進展的原因是，用戶指定的查詢（QueryString參數傳遞到DataContainer構造）被使用。使用用戶指定的查詢，我們不能保證並因此不能假定文檔的查詢響應流將按_ts列進行排序，這是支持漸進式進度的必要假設。

因此，如果您的方案不需要自定義查詢，請考慮不要使用它。

或者，考慮劃分您的數據並創建多個數據源/索引器對，它們都寫入同一個索引。您可以使用Datasource.Container.Query參數來提供一個DocumentDB查詢，該查詢使用WHERE過濾器對數據進行分區。這樣，每個索引者的工作量就會減少，並且具有足夠的分區，將會在24小時內滿足要求。此外，如果您的搜索服務具有多個搜索單元，則多個索引器將並行運行，進一步增加整個索引並減少索引整個數據集的總時間。

來源

2016-09-19 12:26:12

謝謝尤金。以這種方式劃分數據的方式並不明顯，因此，如果您在此處發現問題，我會密切關注更新。 –

嗨伊恩，對於延遲抱歉 - 我已經看了這個並更新了答案。如果您還有其他問題，請隨時通過微軟網站eugenesh與我聯繫。謝謝！ –

將Documentdb導入到Azure搜索時處理索引器超時

回答

相關問題