GAE ndb 设计、性能和重复属性的使用答案

【问题标题】：GAE ndb design, performance and use of repeated propertiesGAE ndb 设计、性能和重复属性的使用
【发布时间】：2013-03-13 04:30:52
【问题描述】：

假设我有一个图片库，一张图片可能有 10 万以上的粉丝。哪个ndb设计效率更高？

class picture(ndb.model):
    fanIds = ndb.StringProperty(repeated=True)
    ... [other picture properties]

或

class picture(ndb.model):
    ... [other picture properties]

class fan(ndb.model):
    pictureId = StringProperty()
    fanId = StringProperty()

您可以添加到 ndb 重复属性的项目数量是否有任何限制，并且在重复属性中存储大量项目是否会影响性能？如果使用重复属性的效率较低，那么它们的预期用途是什么？

【问题讨论】：

与答案无关，但我建议您遵循约定.. 类名CamelCase 和属性名lower_case_underscore..
对于pictureId，也可以使用ndb.KeyProperty(kind=picture)，就像您在当前模型中所拥有的一样。以及fanId = ndb.KeyProperty(kind=fan, repeated=True)而不是StringProperty，以便更好地处理实体。

【解决方案1】：

如果您有超过 100-1000 个值，请不要使用重复的属性。（1000 可能已经在推动它了。）它们不是为这种用途而设计的。

【讨论】：

从另一个问题跳入这个答案：（stackoverflow.com/questions/26740505）。一个不应该使用超过 10 个元素的重复属性？所以应该避免通过重复的键来建立关系。对吗？
@Guido 对于这种类型的大容量数据存储我们应该使用什么？
@Napolean 我认为NDB PickleProperty 是您正在寻找的。span>

【解决方案2】：

通常 v1 会便宜很多。

在读/写成本方面，您为每个实体的获取/写入付费，因此您希望减少实体的数量。版本 1 会更便宜。如果每次获取图片时都获取所有粉丝，则成本会显着降低。

但是，每个实体的大小限制为 1MB。如果您有 10 万以上的粉丝，您可以根据 fanId 的大小达到该限制。这还不包括您的其他图片数据，因此您可能会突破 1MB 的限制。您必须添加一些更复杂的代码来处理溢出情况。

大实体比小实体需要更长的时间来获取。如果您要始终同时吸引所有粉丝，v1 会更好。如果您只想在任何时候获取 5 个粉丝，v2 可能会更快（仅可能）。另一方面，如果您尝试拉出 10 万个粉丝实体……那将永远持续下去。

【讨论】：