我已经使用Google App Engine几个月了，最近我对数据存储区的一些做法产生怀疑。我有大约10个实体，每个实体有10-12个属性。一切都在我的应用程序中运行良好，代码非常简单，我的数据结构的方式，但我想知道我是否应该将这些大型实体分解为较小的实体，以优化读取或写入或仅遵循最佳实践（我不确定关于GAE）
现在我已经完成了读写的配额，并希望对其进行检查。
答案 0 :(得分：3)
优化阅读：
如果在查询中使用偏移量，则将偏移实体计为读数。如果您运行offset = 100的查询，数据存储区将检索并丢弃前100个实体，并为这些读取付费。尽可能使用游标来减少读操作。游标也会带来更快的查询。
在运行查询时，NDB不一定会减少读取。对数据存储区进行查询并返回实体，不会发生内存缓存交互。如果要在查询的上下文中从memcache检索实体，则需要运行keys_only查询，然后尝试从memcache中检索这些键。然后，您需要转到任何缓存未命中的实体的数据存储区。检索密钥是一个“小”操作，是读操作成本的1/7。
优化写作：
删除未使用的索引。默认情况下，实体上的每个属性都被编入索引，并且每个属性在第一次写入时都会发生2次写入，而在每次写入时都会发生4次写入。您可以为这样的属性禁用索引：firstname = db.StringProperty（indexed = False）。
如果使用列表属性，则列表中的每个项目都是实体上的单个属性。列表属性是为方便起见而提供的抽象。名为具有值[“thing1”，“thing2”]的东西的列表属性实际上是数据存储区中的两个属性：things_0 =“thing1”和things_1 =“things”。与索引结合使用时，这可能会非常昂贵。
合并您不需要查询的属性。如果只需要查询一个或两个属性，请序列化其余属性并将其作为blob存储在实体上。
进一步阅读：
答案 1 :(得分：1)
我建议考虑使用NDB实体。在执行对数据存储区的读/写操作之前，NDB将使用上下文缓存（如果需要，还有Memcache）。这应该可以帮助您保持在配额范围内。
请阅读此处以获取有关NDB如何使用缓存的更多信息：https://developers.google.com/appengine/docs/python/ndb/cache
请参阅此页面，了解有关GAE的最佳实践：https://developers.google.com/appengine/articles/scaling/overview
答案 2 :(得分：1)
AppEngine数据存储区每个实体读取收取固定金额，无论实体有多大（尽管最大为1MB）。这意味着将您阅读的多个实体组合成一个实体是有意义的。缺点是延迟增加（因为它需要每次反序列化更大的实体）。我发现这个延迟非常低（即使对于大的也是低1位数ms）。
在数据存储区上使用框架是一个好主意。我正在使用Objectify并且非常高兴。尽管如此，请谨慎使用Memcache集成。 Googles只为每个应用程序提供固定数量的固定内存，因此，一旦您谈论更大的数据，这将无法解决您的问题（因为实体已从Memcache中逐出，需要从数据存储区重新读取并放入缓存中每次阅读再次。）