谷歌應用程序引擎JDO查詢使用替代邏輯'NOT IN'

我正在開發一個Google App Engine Java應用程序，用戶可以根據搜索條件從數據庫中搜索業務對象。搜索結果（記錄列表）不應包含他們過去的搜索中的任何記錄（特定數量的記錄，比如100）。出於這個原因，我將過去的結果存儲在用戶配置文件中。有效實現此邏輯的任何建議（不使用多個集合迭代）。我正在使用JDO，並且在查詢中使用'NOT IN'條件有限制。谷歌應用程序引擎JDO查詢使用替代邏輯'NOT IN'

來源

2011-09-28 wmmcii

業務對象的總數有多大，您預計「已搜索」列表有多大？這聽起來像你的用戶對象會變得巨大，如果你不斷用已經查看過的搜索結果更新它們。 –

搜索結果只是對象鍵（不是實際的業務對象）。搜索歷史記錄將有500個搜索結果記錄（僅限Keys），當添加新密鑰時，舊歷史記錄將滾動 - 僅保留500個記錄密鑰。 – wmmcii

搜索結果將限制爲每個搜索200條記錄。這200個結果不應包含搜索歷史記錄中的任何500條記錄。謝謝你的時間。 – wmmcii

下面是一個解決方案，假設您的目標是獲得200個已不在歷史記錄中的密鑰。我將嘗試估計用作「效率」的代理操作的數量，因爲這是我們將如何在new pricing model

收取取用戶對象和「歷史的鑰匙」（1個讀操作）
只執行鍵查詢和取300條記錄。（300小操作）
在你的代碼中，從300條記錄中減去任何歷史鍵。（0操作）
如果最後步驟3後的記錄數少於200，則取另外100個（如果需要，重複）（100個小操作）。
一旦您有200個以前未見過的密鑰，您可以在需要時獲取完整的業務對象實體，或者將密鑰顯示給用戶。（200讀取操作，如果您獲取整個對象）

如果數據存儲支持原生「NOT IN」操作符，那麼我們就可以從第2步剃掉100個小操作，並跳過步驟4.最大的成本在這裏將獲取實際的200個實體，這些實體必須在有或者沒有NOT IN操作符的情況下發生。最終，與原生NOT IN運算符相比，這種方法的效率並不高。

進一步優化：

如果你並不需要所有的同時顯示200個鍵，那麼你可以使用光標一次只能獲得N個結果。
我只是猜測，當我建議你最初得到300個鍵。您可能需要獲得更多或更少。第二次嘗試的時候你也可能少於100。

來源

2011-09-28 18:52:09

非常感謝您的時間和解決方案。如果我在第一次300次獲取時沒有獲得200個好記錄（比如說我只有100個好的記錄），在第二次獲取時，我必須將結果與500次歷史記錄和最初的100次記錄進行比較。（並且它會繼續提取）您認爲執行此收集操作會影響性能。有沒有任何數據存儲解決方案來解決這個問題。即使使用Google本機數據存儲區API？ – wmmcii

@ user969227從代碼中的（大）可能結果集中篩選出（小）排除結果集將比任何數據存儲選項快得多。如果你從頭開始構建數據庫，這仍然是最快的方法。 –

除非有重複的業務對象，否則不必將其與初始值100進行比較。 –

谷歌應用程序引擎JDO查詢使用替代邏輯'NOT IN'

回答

相關問題