Appengine搜索API vs數據存儲

我正在嘗試決定是否應該使用App-engine搜索API或數據存儲來存儲App-engine Connected Android項目。谷歌文檔的唯一區別是Appengine搜索API vs數據存儲

...索引搜索可以找到不超過10,000個匹配文檔。 App引擎數據存儲區可能更適合需要檢索非常大的結果集的應用程序。

鑑於我已經非常熟悉數據存儲：有人請幫助我，假設我不需要10,000個結果嗎？

是否有任何優勢，使用Search API與使用數據存儲爲我的查詢（根據上面的報價，這似乎是合理使用一個或其他）？就我而言，最終用戶必須能夠搜索，更新現有條目並創建新實體。例如，如果我的應用程序是書店，則用戶必須能夠添加新書籍，向現有書籍添加評論，搜索特定書籍。
我的數據結構是這樣的，內容將由最終用戶提供。文檔vs數據存儲實體：哪個更新更便宜？ $$等
它們可以相互補充：數據存儲和搜索API嗎？有什麼優勢？爲什麼有人會考慮配對呢？成本是多少？

來源

2014-04-26 Katedral Pillon

這是一個很好的問題。但選定的答案是欠佳的。我會對這個問題投票，但是需要一個更好的答案來解決問題中的問題。 – learner

關鍵的區別在於，使用數據存儲您不能在實體內搜索。如果您有一本名爲「戰爭與和平」的書，如果用戶在搜索框中鍵入「戰爭和平」，則無法找到它。與評論等相同因此，它不是您的選擇。

來源

2014-04-26 23:26:51

更準確地說，在數據存儲中，您不能通過'contains'進行搜索，因此您無法在這裏用兩個單詞搜索示例進行搜索。數據存儲還有其他限制，例如只允許兩個不等式。 –

非常感謝你的答案。這確實有很大的幫助。所以我應該假設，否則我可以使用搜索API和文檔**而不是數據存儲來存儲我的數據？即我是否明白數據存儲的唯一優勢是10,000限制？否則，Search API Documents可以執行數據存儲可以執行的任何操作？ –

您仍然需要數據存儲。這是存儲數據的位置，例如書籍ID/ISBN，作者，價格，類別等。您可以使用Search API來存儲書名和評論，但需要將這些記錄鏈接到數據存儲中的實體。 –

其他一些信息：

數據存儲是一種交易系統，這是在很多使用情況非常重要。搜索API不是。例如，您不能在單個事務中放入和刪除並在搜索索引中記錄文檔。
數據存儲與Cassandra等NoSql數據庫有許多共同之處，而搜索API實際上是一個文本搜索引擎，與Lucene類似。如果您瞭解反向索引的工作原理，則可以更好地瞭解搜索API的工作原理。
將數據存儲區API和搜索API結合使用的一個很好的理由是，數據存儲使得查詢API非常容易處理某些類型的查詢（例如，自由文本查詢，地理空間查詢）非常困難。因此，您可以將主要實體存儲在數據存儲中，但如果您需要以數據存儲不允許的方式進行搜索，則可以使用搜索API。我認爲，如果數據存儲和搜索API更加緊密地集成在一起，例如通過允許您對索引文本字段進行自由文本搜索，那麼應用引擎會在您的幕後爲您自動創建搜索文檔索引。

來源

2014-04-27 23:55:31 adevine

搜索API的最嚴重的con是最終一致性的規定在這裏： https://developers.google.com/appengine/docs/java/search/#Java_Consistency

這意味着，當您添加或更新與搜索API的記錄，它可能不會立即反映更改。想象一下，用戶上傳圖書或更新其帳戶設置的情況，並且沒有任何更改，因爲更改尚未傳送到所有服務器。

我認爲搜索API只有一個好處：搜索。它基本上充當數據存儲中數據的搜索引擎。

所以我的建議是保持數據存儲在用戶期望的即時結果，並使用搜索API來搜索用戶不會期望即時結果的數據。

來源

2014-09-02 01:34:32 highroller

數據存儲區只提供一些查詢操作符（=，！=，<，>），執行嵌套過濾器和多個不等式成本高昂或不可能（超時），搜索結果可能會給出很多False Positives。您可以通過標記進行部分字符串搜索，但這會使您的實體膨脹。解決這些限制的最佳方法是使用Structured Properties和/或Ancestor Queries。

另一方面，搜索API在搜索文檔上運行全文搜索，它比NDB查詢更快，更準確，而不依賴於標記化數據。缺點是它依賴數據保持最新。

使用數據存儲處理數據（創建，更新，刪除），然後運行函數將這些數據作爲文檔和集羣使用索引，然後使用Search API運行搜索。

來源

2017-06-14 03:03:35

Appengine搜索API vs數據存儲

回答

相關問題