我有大约28GB的Data-In,存储在Windows Azure Table Storage中的行数超过1,350万行。优化Windows Azure表存储?
6列,除1小数和1日期时间以外的所有整数。 分区密钥长约10个字符。 RowKey是一个guid。
这是为了我的理智检查 - 这似乎是正确的吗?
SQL数据库我从迁移的数据有WAY更多的数据,只有4.9GB。
有没有缩小尺寸的方法?我不怀疑重命名的属性会对此产生巨大的影响。
*请注意,这只是数据的采样估计的长途费用。
我有大约28GB的Data-In,存储在Windows Azure Table Storage中的行数超过1,350万行。优化Windows Azure表存储?
6列,除1小数和1日期时间以外的所有整数。 分区密钥长约10个字符。 RowKey是一个guid。
这是为了我的理智检查 - 这似乎是正确的吗?
SQL数据库我从迁移的数据有WAY更多的数据,只有4.9GB。
有没有缩小尺寸的方法?我不怀疑重命名的属性会对此产生巨大的影响。
*请注意,这只是数据的采样估计的长途费用。
嗯......事情似乎没有加起来正确的数据不只是改变。
你的数字是约。一个数量级以上(每个实体大约2,000字节)。即使从序列化中考虑批量,我也没有看到你是如何获得这么大的尺寸的。只是好奇:你是如何计算当前表格大小的?还有......你是否做过多次测试,从而得到更多以前运行的数据?您是只测量表格大小,还是存储帐户中使用的总存储空间?如果是后者,可能会有其他表格(如诊断)也占用空间。
重命名在那些坚持应该有大小有一定影响的实体属性。不幸的是,这只会用于未来保存的数据。现有因为你已经更名的属性
也许这不是说这个的时候,但是你确定你使用适当类型的存储为你的信息?看起来你得到了一个固定的模式和其他更适合关系数据库服务的东西...... – Leonardo 2013-04-24 20:15:34
是的,我忘了提及这个迁移只是测试我可以预期的成本。架构不固定,数据本质上是非关系型的。 – asunrey 2013-04-24 20:29:53
@Leonardo - 我不同意;关系数据库与关系数据一起发光,但如果数据可以通过分区+行直接查找,则表存储是一个非常棒的替代方案,不需要大量的SQL(并且可以扩展到200TB,SQL Az不能在Azure中实现)。无论如何:没有详细了解数据如何被访问的信息,绝对没有办法做出这种决定。 – 2013-04-25 02:37:10