Question

根据this presentation by Johan Euphrosine等多个来源，AppEngine将属性名称与数据和索引一起存储。因此，我在数据存储区中使用类型和属性名称的缩短版本来节省磁盘空间：

@Entity("p")
public class PersistentClass {

    @Property("n")
    private String name;

}

此实体的索引条目位于以下行：

PersistentClass:1
PersistentClass:name:foo:PersistentClass:1

与（应用缩短的属性名称）相比：

p:1
p:n:foo:p:1

这是73％的压缩，但这是一个理论上的练习，如果没有平台的内部知识，很难推进。我的问题是：这是常见做法吗？有没有人测量过NoSQL中存储的缩短属性名称的节省，特别是AppEngine？

Answer 1

回答这个问题的最简单方法可能是通过一个简单的测试。我只是将一个示例应用程序放入一个Gist（https://gist.github.com/jeremydw/7201456），在那里我测试了具有长属性名称的模型的2000个实体的创建，以及具有单个字符属性名称的模型的2000个实体。

使用数据存储统计模块（https://developers.google.com/appengine/docs/python/datastore/stats）确认较长的属性名称占用更多磁盘空间。（在此特定实验中为278KB。）有趣的测试还包括测量创建或检索实体的时间，因为这也会影响应用程序的速度。

以下是单个测试的结果：

name: l_PersistentClass2, bytes: 1507635
name: super_very_long_property_name_PersistentClass1, bytes: 1787607
difference: 279972 bytes

Answer 2

没有错 - 这应该是一个完全可以接受的做法。

它是否真的为您节省了金钱是另一回事。这当然完全取决于应用程序，但我们最大的开支是数据库操作和带宽。经过两年的运营（不断保存数据），我们的总数据存储费用仅占总费用的5％。

你应该做一些计算，看看这是否会对你的总GAE成本产生任何有意义的影响。

Answer 3

是的，这通常是一个好主意。

这可能对索引的影响可以忽略不计，我认为索引实际上不会为每个索引条目使用属性名称。

但是，属性名称用于存储的每个实体。我现在没有跟我有数字，但我确实用一个有大约80个整数属性的实体进行了测试。在这种情况下，长属性名称是实际整数值之上的显着开销，并且使用1或2个字符的属性名称显着减少了实体的大小。

但是，我只存储了几千个实体，因此对成本的实际影响很小。但是现在每次我在数据存储视图中调出这些实体时，我都需要调出我的源代码来确定哪个属性是哪个。