Google App Engine數據存儲區中最有效的一對多關係？

Question

對不起，如果這個問題太簡單了，我只進入9年級。

我想了解NoSQL數據庫設計。我想設計一個Google數據存儲模型，以最大限度地減少讀/寫次數。

下面是在一個一對多關係的博客文章和評論的玩具例子。哪種方法更高效 - 將所有註釋存儲在StructuredProperty中，或在Comment模型中使用KeyProperty？

此外，其目標是最大限度地減少對數據存儲的讀取/寫入次數。你可以做出以下假設：

• 評論將不會獨立於各自的博客文章檢索。 （我懷疑，這使得最優選的StructuredProperty。）
• 評論將需要按日期，等級，作者等排序（數據存儲中的子屬性不能被索引，所以，這可能會影響性能？）
• 博客文章和評論可以在創建後進行編輯（甚至刪除）。

使用StructuredProperty：

from google.appengine.ext import ndb 

class Comment(ndb.Model): 
    various properties... 

class BlogPost(ndb.Model): 
    comments = ndb.StructuredProperty(Comment, repeated=True) 
    various other properties... 

使用KeyProperty：

from google.appengine.ext import ndb 

class BlogPost(ndb.Model): 
    various properties... 

class Comment(ndb.Model): 
    blogPost = ndb.KeyProperty(kind=BlogPost) 
    various other properties... 

隨意彈出，涉及到有效地代表與問候到最小化一個一對多的關係，任何其他考慮因素讀/寫數據存儲的次數。

謝謝。

Answer 1

我可能是錯的，但是從我的理解，一個StructuredProperty只是一個實體中的屬性，但子屬性。

這意味着閱讀BlogPost及其所有評論只需花費一次閱讀。所以當你渲染你的頁面時，你只需要一次讀取你的整個頁面。

寫入每個也會更便宜。您需要一次讀取操作來獲取BlogPost，並且只要您不更新任何索引屬性，它就只是一個寫操作。

您可以處理的評論自己的排序，你讀出的實體數據存儲之後。與交易

你必須同步您的評論更新/編輯，以確保一個評論不覆蓋其他，因爲它們都修改同一個實體。如果每個人都在同一時間評論和編輯同一篇博文，您可能會遇到難以解決的問題。

雖然在成本優化，你會碰了壁帶1MB的最大實體尺寸。這將限制您可以爲每篇博文存儲的評論數量。

使用KeyProperty將會相當昂貴。

你需要一個讀來獲取博客文章，再加上1個查詢併爲每個評論1次小的讀取運算。

每個評論是一個新的實體，所以它至少會有4個寫操作。您可能想要對排序順序進行索引，這樣最終會花費更多的寫操作。

從好的一面來看，每篇博文都會有無限的評論，您不必擔心同步新評論。您可能需要擔心編輯註釋的同步，但如果將編輯限制爲創建者，那應該不是問題。你不必自己排序。

這是一個成本與功能的權衡。

Answer 2

什麼：

from google.appengine.ext import ndb 

class Comment(ndb.Model): 
    various properties... 

class BlogPost(ndb.Model): 
    comments = ndb.KeyProperty(Comment, repeated=True) 
    various other properties... 

這樣，您就可以存儲多達獨立每篇博客文章的大小，每博客文章（重複屬性的最大數量）5000條評論。你不需要查詢來獲取博客的評論，你可以做ndb.get_multi(blog_post.comments)。對於此操作，您可以嘗試依賴ndb的內存緩存。當然，這取決於你的用例，這是否是一個好的假設。

Answer 3

使用重複StructuredProperty時，要注意這個警告的：

，如果你有超過100-1000值不要使用重複的屬性。 （1000可能已經在推動它。）它們不是爲這種使用而設計的。

查看Guido的回答GAE ndb design, performance and use of repeated properties。

因此，儘管您不可能使用StructuredProperty達到1 MB實體限制，但您可以輕鬆達到100-1000建議的最大值。