何時不應使用App Engine的全文搜索API？

到目前爲止，我已經使用App Engine的全文搜索來幫助搜索數據存儲中的現有實體。這涉及每個實體至少創建一個Document，並以某種方式將兩者連接在一起。每次我更換實體時，我都必須更改相應的Documents。何時不應使用App Engine的全文搜索API？

我的問題是，爲什麼不把我所有的數據存儲在Documents中，忘記數據存儲實體？與數據存儲區不同，搜索API支持更豐富的query language，可以處理多個不等式過濾器和布爾運算符。

我是否錯過了一些關於搜索API的設計，這些設計會阻止用它來完全替代數據存儲？

來源

2012-06-08 Nick Farina

按照Java docs

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

雖然我沒有看到這是一個常見的用例。

更現實的情況是，使用Datastore按鍵獲取實體將會便宜很多（假設速度更快）。使用搜索API，您可以使用Index.get（）按ID查找文檔，也可以通過將ID存儲在字段中並在該字段上搜索來複制ID。

這裏的費用明細：

- Index.get():  $0.10/10,000 or 0.00001 per get 
- Index.search(): $0.13/10,000 or 0.000013 per get 
- Datastore get(): $0.06/100,000 or 0.0000006 per get

正如你所看到的，數據存儲得到的是比搜索API選項便宜得多（比Index.get 16X便宜（））。

如果您的數據結構使用了大量直接獲取和少量複雜搜索，則數據存儲在成本方面將是明顯的贏家。

注意：我沒有包含使用Index.search（）方法存儲重複數據的額外成本，因爲這取決於您存儲的實體數量。

來源

2013-08-20 17:37:23

謝謝，這非常有幫助！以及爲什麼Search可能不是合適的插入式數據存儲替換的一個很好的解釋。 –

@pixel您在哪裏看到每天有1000個API調用的限制？據我所知，這只是免費配額限制。 – AsafK

@AsafK我鏈接的文件提到「這些電話每天限制1,000次操作。」但我認爲你是正確的，這隻適用於免費配額，這句話是誤導性的，因爲定價是10K增量。我編輯了我的答案以刪除該評論。 –

難道你：

失去的memcache
面對配額下降的任何利益。「我們預計，一旦功能從實驗畢業後，我們的免費配額將每天覆蓋大約1,000次搜索」我看不到您獲得的讀取次數，但我相信數據存儲的讀取次數更高。我看着https://developers.google.com/appengine/docs/quotas#Resources

此外，對於實體更新，我們收取不同的更新或新投入。似乎索引沒有更新，而是作爲新文檔添加（這正是我正在做的事情）。沒有指標定價的細節，很難確切地知道，但可能更新一個或兩個實體索引值將會更便宜，因爲它會提供一個新的整體指數。這將取決於你的數據我猜。

最後，索引的總索引大小現在爲250M，而數據上限爲1 GB。數據存儲空間較大，而且還沒有關於索引額外定價成本的文字。
需要拿出一個備份計劃。無論如何我現在都不知道要備份或恢復索引是否損壞。擁有實體中的數據意味着可以重新創建搜索索引。您現在可以使用數據存儲的管理控制檯進行備份。

來源

2012-06-08 22:13:45 user1258245

感謝您的回答。我的迴應：1）Memcache是與數據存儲或搜索無關的完全獨立的系統。 2）目前有限的配額是暫時的。更新+刪除文件是可能的（就像實體一樣）。 3）關於自動備份的好處;儘管如此，我希望他們也支持備份文件。 –

只需將數據放在兩個位置 - 存儲成本低廉，取決於您的應用程序寫入的數量是多少，以便進行更新。爲了輕鬆查詢並按鍵獲取單個實體 - 使用memcache和數據存儲。對於複雜的查詢使用搜索API。一旦宣佈定價，您必須做出折衷。

來源

2012-10-18 17:48:27 aloo

這就是我們今天正在做的事情，但它仍然很好地瞭解搜索API的設計和意圖。 –

現在索引一個實體在searchdoc中，每當我把它和我也索引實體的序列化版本。
它實際上是很多更快地搜索搜索api上的文檔並提取序列化字段，而不是從數據存儲中獲取相同數量的實體。

來源

2012-10-18 18:47:11 aschmid00

有趣的是，知道搜索API速度更快 - 是否有理由期望它更快？或者，也許這是因爲它仍然處於有限的試用階段，並且很多用戶還沒有敲定它呢？ –

你能詳細說明你如何測量更快嗎？很明顯，如果你只是將實體從現有的搜索文檔反序列化，它將比數據存儲獲得更快。但是，您是否通過增加文檔來衡量搜索延遲的增加？ – aloo

我目前沒有數字，但大致用一個stringproperty獲取1000個實體只需要大約2s。搜索相同數量的實體（僅返回序列化字段）併爲所有這些文檔加載序列化的json在F1上花費0.5秒以下。 – aschmid00

除了查詢大量數據集的性能成本外，數據存儲還具有允許高度一致的數據的優勢。查看this link以獲取有關強一致性和最終一致性數據的更多信息。

應該假定存儲在搜索API索引中的文檔是，最終一致性爲。

來源

2016-11-26 20:58:07 yoonjesung

何時不應使用App Engine的全文搜索API？

回答

相關問題