Google app engine 通过减少实体大小提高应用程序引擎性能

目标是减少经常运行的代码段的CPU成本和响应时间，并且每次都必须使用db.get（）几百个键

这行得通吗？ 我可以预期一个具有几百个键的db.get（）的API时间吗 当我减小实体的大小时大致线性地减小？ 当前该实体已附加以下数据：9字符串，9 布尔值，8个整数，1个GeoPt，2个DateTime，1个文本（平均大小~100字节 FWIW），1个参考，1个字符串列表（平均大小为500字节）。目标是 将绝大多数数据移动到相关类，以便 主模型的取芯速度很快

如果它确实有效，它是如何实现的？ 在重构之后，我还会产生同样的问题吗 获取现有实体的高成本？文件上说 同时获取模型的属性。老人会吗 不需要的属性仍然通过RPC在我的dime上传输，而用户 等待换句话说：如果我想减少实体的加载时间，那么 有必要将旧实体迁移到具有新实体的实体 定义？如果是这样，重新放置（）实体就足够了，还是我必须这样做 保存在一个全新的密钥下

例子 考虑：

class Thing(db.Model):
    text    = db.TextProperty()
    strings = db.StringListProperty()
    num     = db.IntegerProperty()

thing = Thing(key_name='thing1', text='x' * 10240,
      strings = ['y'*500 for i in range(10)], num=23)
thing.put()

比方说，我重新定义了要简化的东西，并推出了一个新版本：

class Thing(db.Model):
    num = db.IntegerProperty()

我把它拿回来：

thing_again = Thing.get_by_key_name('thing1')

我是否缩短了此实体的提取时间

如果我想缩小我的 实体，是否需要迁移 将旧实体转换为具有新实体的实体 定义

---

对。GAE数据存储只是一个大的键值存储，它对模型定义一无所知。因此，在您输入新值之前，旧值将一直是旧值

按顺序回答您的问题：

• 是的，分割模型将减少获取时间，尽管可能不是线性的。对于像您这样相对较小的模型，差异可能不会很大。大型列表属性是导致获取时间增加的主要原因
• 在模型更改后获取实体时，旧属性仍将被传输，因为数据存储不了解模型
• 但是，即使调用.put（），删除的属性仍将被存储。目前，有两种方法可以消除旧属性：用新实体替换所有现有实体，或者使用较低级别的api.datastore接口，该接口类似于dict，可以方便地删除键

---

要从实体中删除属性，可以将模型更改为Expando，然后使用delattr。它记录在以下App Engine文档中：

---

在标题下“从数据存储中删除已删除的属性”

谢谢，Jonathan。当然，旧的价值观将继续存在。我已对你的回答作了重新措辞。我想知道的是，在更改模型定义后，在获取对象时是否会立即看到加速（因为底层db.model将不再获取已删除的属性）；或者，我是否需要保存一个新实体，只保存一组减少的属性，以便在获取该实体时看到加速效果？如果仅更改旧模型，则将失去获取使用旧模型创建的实例的能力。您必须创建一个全新的模型，并将旧模型移植到其中。回答您的问题：获取的成本是费用，而不是将获取的blobby反序列化到模型实例中的成本。再次感谢您，Jonathan。我知道获取是费用，而不是反序列化。我在这个问题上加了一个例子。（现在我已经这样做了，我可以运行一些基准测试来更加确定。）答案仍然是“您没有减少获取时间，因为旧模型仍然存储在表中，并且整个过程都是通过网络发送的。”“如果仅更改旧模型，则将失去获取使用旧模型创建的实例的能力。“-这是完全不真实的。您仍然可以在修改之前获取实体。+1关于如何删除属性，我已经想了一两天了。谢谢。我原以为一个包含近30个属性（包括列表和文本）的模型如果不算大，也值得优化。30个属性和30个项目的列表或多或少是等效的——正如你所想象的，有可能有更大的模型。：）再次感谢你，尼克！在我的例子中，30个属性，其中一个是30个属性的StringList:）我将在论坛上跟进“模式”重构的结果。仅供参考，这是jhs所指的论坛。有没有办法减少获取的密钥数量？这可能会比从每个实体上减少一些字节更多地减少API CPU。