從數據存儲中檢索實體的時間

我有一個使用數據存儲的App Engine應用程序。數據存儲中的一種包含超過2,000,000個實體。這種查詢非常緩慢。
例如，返回大約50個實體的查詢需要3 - 5秒。我不知道過濾器的數量是否很重要，但在這種情況下，我在查詢中設置了7個過濾器。
在我看來，其他類型的查詢也很慢。例如，查詢返回大約20個實體，其中包含超過90 000個實體的實體大約需要1秒。從數據存儲中檢索實體的時間

我爲該查詢構建複合索引，但它沒有太多幫助。更改塊大小和使用密鑰只有查詢不幫助。

對數據存儲執行查詢的時間影響最大的是什麼？有什麼方法加快我的查詢？

，我找回實體的方式類同用一個例子，我在文件中發現：

Query q = new Query("Person").setFilter(heightRangeFilter); 

    PreparedQuery pq = datastore.prepare(q); 

    for (Entity result : pq.asIterable()) { 

     String firstName = result.getProperty("firstName").toString(); 
     String lastName = result.getProperty("lastName").toString(); 
     Long height = (Long) result.getProperty("height"); 

    }

該實體的總大小爲423.33 MB，內置指標：2.87GB，複合索引：1.85GB

我正在使用Logger類來記錄診斷信息。我可以在管理控制檯中看到兩個日誌之間的時差。當我把日誌放入迭代實體的循環的第一行和最後一行時，我可以在迭代之間看到奇怪的暫停。我不知道是什麼原因。

實施例：
15：06：30.565開始
15：06：30.566停止
15：06：30.566開始
15：06：30.566停止
15：06：30.572開始
15： 06：30.572停止
15：06：30.583開始
15：06：30.583停止
15：06：30.595開始
15：06：30.595停止
15：06：30.595啓動
15：06：30.595停止
15：06：30.595開始
15：06：30.596停止
15：06：30.658開始
15：06：30.658停止
15：06：30.659開始
15：06：30.659停止
15：06：30.666開始
15：06：30.666停止
...

編輯：我修改我的查詢使用6個過濾器，並建立新的COM posite指數。它似乎更快，但它在檢索大約100個實體時仍然運行超過2秒。我創建過濾器的方法是從文檔類似於例如：

Filter timeMinFilter = 
    new FilterPredicate("time", 
         FilterOperator.GREATER_THAN_OR_EQUAL, 
         startTime); 

Filter timeMaxFilter = 
    new FilterPredicate("time", 
         FilterOperator.LESS_THAN_OR_EQUAL, 
         stopTime); 

Filter heightRangeFilter = CompositeFilterOperator.and(timeMinFilter, timeMaxFilter);

會有問題，我設置FilterOperator.GREATER_THAN_OR_EQUAL和FilterOperator.LESS_THAN在一根繩子上的財產？

感謝您的幫助。

來源

2014-11-03 lukasz

你如何計時查詢需要多長時間？也許在使數據存儲調用的代碼中有開銷？ – bighonestjohn 2014-11-04 10:04:59

最好使用'（String）result.getProperty（「firstName」）'。 'toString（）'方法是將所有類型表示爲String的「盡力而爲」方法，而在這種情況下，您只需簡單地轉換類型。例如，如果你將錯誤的類型傳遞給「firstName」屬性，那麼如果你嘗試轉換它，你會得到一個異常（即你會發現有問題），但是'toString（）'即使在這種類型沒有意義。 – 2014-11-04 16:26:40

App Engine上的查詢速度不取決於存儲在數據存儲中的實體數量。它僅取決於您從查詢中檢索到的實體的數量和大小。

您所查詢的時間表示以檢索這些實體的方式存在問題。這可能是用於運行查詢的代碼中的問題，也可能是實體創建方式的問題。無法深入挖掘您在問題中提供的信息。

UPDATE：

嘗試使用此代碼代替，看看你看到的改進：

for (Entity result : pq.asList(FetchOptions.Builder.withDefaults().chunkSize(100).prefetchSize(100)) {

你應該在你預料有超過10個結果中查詢每次使用這條線。請注意，該數字可以是0到1000之間的任意值，因此您可以針對不同的查詢嘗試不同的限制，以查看最佳效果。

來源

2014-11-03 22:19:55

只是指出他的錯誤的另一種可能性：如果他沒有這個查詢的自定義索引，並使用7個不同索引的鋸齒算法，它肯定會減慢查詢 – Patrice 2014-11-03 22:44:03

你是完全正確的。然而，Lukasz在他的問題中確實提到了「綜合指數」。另外，我們不知道他正在使用哪個運行時和數據存儲庫。如果您創建一個沒有支持索引的查詢，其中一些會引發異常。 – 2014-11-04 04:56:39

我正在使用Java運行時環境和DatastoreService來運行我的查詢。 – lukasz 2014-11-04 08:28:16

從數據存儲中檢索實體的時間

回答

相關問題