在数据存储中存储元组的有效方法答案

【问题标题】：Efficient way to store tuples in the datastore在数据存储中存储元组的有效方法
【发布时间】：2010-06-09 22:13:56
【问题描述】：

如果我有一对浮点数，将它们存储为GeoPtProperty 是否比腌制元组并将其存储为BlobProperty 更有效（计算上或存储上）？

如果GeoPt 正在做一些更聪明的事情来将多个值保存在一个属性中，那么它可以用于任意数据吗？我可以以同样有效的方式将元组 ("Johnny", 5) 存储在单个实体属性中吗？

【问题讨论】：

【解决方案1】：

以下是一些经验性答案：

GeoPtProperty 使用 31B 的存储空间。

使用 BlobProperty 取决于您存储的具体内容：

简而言之，GeoPt 看起来并没有做任何特别聪明的事情。如果你要存储很多这些，那么你可以使用struct 来打包你的花车。使用struct 打包和解包它们可能与序列化/反序列化GeoPt 相关的CPU 成本存在显着差异。

如果您计划为每个实体存储很多个浮点数并且空间非常重要，那么您可以考虑利用 aetycoon 中的 CompressedBlobProperty。

免责声明：这是所需的最小空间。根据物业名称的长度，每个物业的实际空间会稍大一些。模型本身也增加了开销（对于它的名称和键）。

【讨论】：

为了好玩...GeoPt 似乎存储为“点”值。具体来说，数据本身似乎需要 18B - 两个 1 字节整数和两个 8 字节双精度数（参见 here），总共 18 个字节。 struct 解决方案将每个浮点数打包成 4 个字节，总共 8 个字节。因此，从我上面的测试的其余属性信息中，两者都有 13B 的“开销”（开销预计是相同的，因为我的测试之间唯一不同的是属性类型）。
您的分析没有考虑 CPU 时间 - 酸洗和去酸洗通常在计算上非常昂贵。不过，使用结构是个好主意。 AETycoon中新增的ArrayProperty也值得一看。

【解决方案2】：

GeoPt 本身仅限于 (-90 - 90, -180 - 180)；它不能用于存储任何不适合此模型的数据。

但是，自定义元组属性不应该太难自己创建；看看 aetycoon 中的 SetProperty 和 ArrayProperty 是如何设计的。

【讨论】：