很抱歉，如果这个问题太简单了; 我只是进入9年级。
我想了解的NoSQL数据库设计。 我想设计一个读的数量降至最低谷歌的数据存储模型/写。
下面是在一个一对多关系的博客文章和评论的玩具例子。 哪个更有效 - 存储所有的评论中StructuredProperty或在注释模型使用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...
随意弹出，涉及到有效的代表尽量减少读取次数与问候一个一对多的关系，任何其他考虑/写入数据存储。
谢谢。
我可能是错的，但是从我的理解，一个StructuredProperty是一个实体在短短的财产，但子属性。
这意味着阅读博文及其所有评论只会花费一个读。 所以，当你渲染你的页面，你只需要为您的整个页读取运算。
写操作会更便宜每过。 你需要一个读运算来获得博客帖子，只要你不更新任何索引的属性，这将只是一个写运算。
您可以处理的评论自己的排序，你读出的实体数据存储之后。
你必须同步您的评论的更新与交易/编辑，以确保一个评论不覆盖其他，因为它们都修改同一个实体。 如果每个人都在评论和编辑在同一时间同一博客文章，您可能会遇到unsolveable问题。
虽然在成本优化，你会打带1MB的最大实体大小的墙壁。 这将限制你可以为每个博客帖子存储评论的数量。
与KeyProperty会是相当多的昂贵。
你需要一个读来获取博客文章，再加上1个查询并为每个评论1次小的读取运算。
每一个评论是一个新的实体，因此这将是至少4个写入欢声笑语。 您可能要索引排序顺序，这样最终会花费更多的写欢声笑语。
从积极的一面，你必须每博客文章评论不受限制，您不必担心同步新的评论。 您可能需要担心的编辑评论同步，但如果你限制了编辑的创造者，这实在不应该是一个问题。 你不必做整理自己无论是。
这是一个成本VS特性的权衡。
关于什么：
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的内存缓存。 当然，这取决于你的使用情况，这是否是一个好的假设与否。
使用重复StructuredProperty时，要注意这个警告的：
如果你有超过100-1000值不要使用重复的属性。 （1000可能已经推动它。）他们的设计并不适合这种用途。
见圭多的回答GAE NDB设计，性能和使用重复的属性的 。
因此，尽管你可能无法击中StructuredProperty 1 MB实体限制，你可以很容易打到100-1000建议最大。
