在AppEngine中使用更短的属性名称是否被认为是一种好的做法？

根据多个来源如this presentation by Johan Euphrosine，AppEngine将属性名称与数据和索引一起存储。正因为如此我使用缩短的种类和属性名的版本，在数据存储，节省空间的磁盘：在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％的压缩，但是这是一种理论上的做法，难以推进，而不平台进行的内部知识R M。我的问题是：这是常见的做法吗？有没有人测量过在NoSQL中储存的缩短的属性名称，特别是AppEngine？

来源

2013-10-28 Nacho Coloma

从我记得您可以在应用程序中使用的“名称”和您在数据存储区中使用的名称（以Python的形式）。简而言之，如果你存储数百万条记录，然后你的节省将是“数记录X字符串的长度”的每一个。所以，如果你预计有很多很多的记录.... –

我觉得长属性名的数据存储中的影响是类似于JSON的问题 - 有短属性名称将帮助你俩当存储你的实体在DS和当它发送到您的客户端应用程序。 – Tom

回答这个问题最简单的方法可能是通过一个简单的测试。我只是将一个示例应用程序投入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-28 18:05:34 jeremydw

太棒了。如果我正确读取此测试，它只会对数据使用的存储进行求和，而不是索引。 –

是的，看着我的devappserver的数据存储统计数据（使用数据存储浏览器），该指数的大小（以字节为单位）对于用长属性名的种类和短属性名相同。这样，索引大小是相同的，存储是不同的，RPC时间（潜在地，可能）不同的。现在，我们可以从中得出一些有趣的结论，但最好的做法可能是分析您的实际应用，以查看差异是否与价格和速度有关。 :) – jeremydw

每个实体的差异是140个字节，其是IMO忽略不计。它甚至不应该在RPC上可见。这听起来像是一个不成熟的优化。 –

不妥的地方 - 这应该是一个完全可以接受的做法。

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

您应该确实做一点calc以确定这是否会对您的总GAE成本产生实际影响。

来源

2013-10-28 18:07:52

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

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

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

但是，我只有几千个这样的实体存储，所以对成本的实际影响是最小的。但是现在每次在数据存储视图中显示这些实体时，我都必须提供我的源代码来确定哪个属性是哪个属性。

来源

2013-10-28 18:53:26 dragonx

在AppEngine中使用更短的属性名称是否被认为是一种好的做法？

回答

相关问题