4

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

@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？

4

3 回答 3

3

回答这个问题的最简单方法可能是通过一个简单的测试。我只是将一个示例应用程序放入 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
于 2013-10-28T18:05:34.260 回答
2

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

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

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

于 2013-10-28T18:07:52.100 回答
0

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

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

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

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

于 2013-10-28T18:53:26.460 回答