2

我正在研究使用表存储来存储一些事务数据，但是，我需要支持一些非常高级的报告，基本上是每天/每月的总数。

我有几个选择：

  • 使用分区/行键结构并动态执行求和，
    例如 20101101_ITEMID_XXXXXXXX（x = guid 或时间，以使其唯一）然后我将使用行键的一部分（ITEMID_201011）查询一个月数据，并在“类型中的成本”属性。

    但是，如何管理 1000 条记录的查询限制？（即如果一天有超过 1000 笔交易，总计会很困难）

  • 使用另一条记录存储当天的总数，并在添加新记录时对其进行更新，
    例如行键“20101101_ITEMID_TOTAL”，然后查询天总数、月数或年总数。

做这个的最好方式是什么？对于使用表存储的这种类型的要求，是否有“最佳实践”？

4

1 回答 1

1

我不确定最佳实践是什么，但我可以评论说，我们在AzureWatch中遇到了类似的情况，并且肯定在表中使用了预聚合值。

主要是出于性能原因 - 即使您通过单个分区键和行键中的范围进行查询，表存储也不是即时的。下载记录所花费的时间有点长，并且取决于记录可能会使 CPU 飙升，因为它需要将数据反序列化为对象。如果您因为 1000 条记录的限制而多次访问表存储，您也将支付更多费用。

需要考虑的其他一些想法：

你的总和会改变吗？如果不是，这是对预聚合的另一个推动

您是否需要在原始数据消失后保留汇总值，或者您是否需要清除原始数据？如果是，那么这是对预聚合的另一个推动

于 2010-11-25T16:29:01.937 回答