2013-04-24 170 views
0

我有大约28GB的Data-In,存储在Windows Azure Table Storage中的行数超过1,350万行。优化Windows Azure表存储?

6列,除1小数和1日期时间以外的所有整数。 分区密钥长约10个字符。 RowKey是一个guid。

这是为了我的理智检查 - 这似乎是正确的吗?

SQL数据库我从迁移的数据有WAY更多的数据,只有4.9GB。

有没有缩小尺寸的方法?我不怀疑重命名的属性会对此产生巨大的影响。

*请注意,这只是数据的采样估计的长途费用。

+0

也许这不是说这个的时候,但是你确定你使用适当类型的存储为你的信息?看起来你得到了一个固定的模式和其他更适合关系数据库服务的东西...... – Leonardo 2013-04-24 20:15:34

+0

是的,我忘了提及这个迁移只是测试我可以预期的成本。架构不固定,数据本质上是非关系型的。 – asunrey 2013-04-24 20:29:53

+1

@Leonardo - 我不同意;关系数据库与关系数据一起发光,但如果数据可以通过分区+行直接查找,则表存储是一个非常棒的替代方案,不需要大量的SQL(并且可以扩展到200TB,SQL Az不能在Azure中实现)。无论如何:没有详细了解数据如何被访问的信息,绝对没有办法做出这种决定。 – 2013-04-25 02:37:10

回答

1

嗯......事情似乎没有加起来正确的数据不只是改变。

  • 每个属性都是一个键/值对,所以在计算中包含属性名称。
  • 数据本身可能在75-100字节左右,包括属性名称平均每个10个字符。 4个int等于16个字节,小数点(double?)8个字节,时间戳8个字节。因此,我们只需要为每个实体添加100个字节。
  • 在1400万个实体中,您将拥有100 * 1350万或约1.35 GB的实体。

你的数字是约。一个数量级以上(每个实体大约2,000字节)。即使从序列化中考虑批量,我也没有看到你是如何获得这么大的尺寸的。只是好奇:你是如何计算当前表格大小的?还有......你是否做过多次测试,从而得到更多以前运行的数据?您是只测量表格大小,还是存储帐户中使用的总存储空间?如果是后者,可能会有其他表格(如诊断)也占用空间。

+0

我手工计算并得到相同的估计。但是当我查看门户摘要时,我看到Data Transfer In是27GB。我在一个免费的帐户,并已被禁用,因为我无法进一步测试(虽然我可能会改变帐户类型)。 – asunrey 2013-04-25 18:33:31

+0

我确实启用了日志记录。这是否包括存储?哦,我敢打赌,它确实。我还使用Cloud Storage Studio从Sql数据库迁移数据。我不知道该程序是否会在存储中增加一些开销。 – asunrey 2013-04-25 18:34:04

0

重命名在那些坚持应该有大小有一定影响的实体属性。不幸的是,这只会用于未来保存的数据。现有因为你已经更名的属性