GAE數據存儲結構

Question

我幾個月來一直在使用Google App Engine，最近我開始懷疑一些關於數據存儲的做法。我有大約10個實體，每個都有10-12個屬性。在我的應用程序中一切正常，代碼非常簡單，我的數據結構方式非常簡單，但我想知道是否應該將這些大型實體分解爲較小的實體，以便優化讀取和寫入，或者僅遵循最佳實踐我不確定關於GAE）

現在我超過了我的讀寫配額，並希望將這些限制在一定範圍內。

Answer 1

優化閱讀次數：

• 如果您使用在查詢偏移，偏移的實體都算作讀取。如果您在offset = 100的位置運行查詢，則數據存儲將檢索並放棄前100個實體，並根據這些讀取結算費用。儘可能使用遊標來減少讀取操作。遊標也將導致更快的查詢。

• 當您運行查詢時，NDB不一定會減少讀取。查詢是針對數據存儲進行的，並且實體被返回，不會發生memcache交互。如果要在查詢的上下文中從memcache中檢索實體，則需要運行keys_only查詢，然後嘗試從memcache中檢索這些密鑰。然後，您需要前往數據存儲以查找緩存未命中的任何實體。檢索密鑰是一個「小」操作，它是讀操作成本的1/7。

優化寫道：

• 刪除未使用的索引。默認情況下，實體上的每個屬性都被編入索引，並且每次寫入時都會寫入2次寫入操作，而每次修改時寫入4次寫入操作。你可以像這樣禁用索引：firstname = db.StringProperty（indexed = False）。

• 如果您使用列表屬性，則列表中的每個項目都是實體上的單個屬性。列表屬性是爲了方便而提供的抽象。列表屬性用值[「thing1」，「thing2」]命名事物實際上是數據存儲中的兩個屬性：things_0 =「thing1」和things_1 =「things」。與索引結合使用可能會非常昂貴。

• 合併您不需要查詢的屬性。如果您只需要查詢一個或兩個屬性，則將其餘的這些屬性序列化並將其作爲一個blob存儲在該實體上。

延伸閱讀：

• https://developers.google.com/appengine/docs/billing#Billable_Resource_Unit_Costs
• https://developers.google.com/appengine/docs/python/datastore/entities#Understanding_Write_Costs

Answer 2

我建議看看使用NDB實體。在採取對數據存儲的讀/寫操作之前，NDB將使用上下文緩存（如果需要的話，還會使用Memcache）。這應該可以幫助你保持你的配額。

這裏閱讀更多信息，NDB如何使用緩存：https://developers.google.com/appengine/docs/python/ndb/cache

並請查閱本頁面的最佳實踐方面進行討論，GAE：https://developers.google.com/appengine/articles/scaling/overview

Answer 3

的AppEngine數據存儲每個實體收取固定金額讀，不管實體有多大（儘管最大爲1MB）。這意味着把你一起閱讀的多個實體合併爲一個實體是有意義的。缺點只是延遲增加（因爲它需要每次反序列化一個更大的實體）。我發現這個延遲非常低（即使對於大的延遲也只有很少的1位數）。

使用數據存儲的ontop框架是個不錯的主意。我正在使用Objectify，我非常高興。雖然使用Memcache整合。 Google僅爲每個應用程序提供固定的有限內存量，因此，只要您在討論更大的數據，這不會解決您的問題（因爲實體已從Memcache中被驅逐出來，需要從數據存儲中重新讀取並將其放入緩存再次爲每個閱讀）。