Azure 表存储日志数据的更好计数算法是什么？答案

【问题标题】：What's a better counting algorithm for Azure Table Storage log data?Azure 表存储日志数据的更好计数算法是什么？
【发布时间】：2011-09-13 05:08:37
【问题描述】：

我正在使用 Windows Azure 并首次尝试使用 Azure 表存储，以使我的应用程序可扩展到高密度流量负载。我的目标很简单，根据一组参数记录每个传入的请求，并报告计数或汇总日志中的数据。在此我提出了 2 个选项，我想知道更有经验的人认为哪个更好。

选项 1：使用布尔值并计算“真”行

因为每一行都被写入一次并且从不更新，所以将每个计数参数存储为布尔值并在求和线程中，拉取查询中的行并对每组真值执行计数以获得每个参数的总数。如果有很多参数，这将节省空间，因为我认为 Azure Tables 将 bool 存储为单个位值。

选项 2：使用 Int 值并对行求和

每一行都如上所写，但每个参数列都添加为 0 或 1 的值。求和将通过查询所有行并对每列使用求和运算来进行。这会更快，因为求和可能发生在单个查询中，但是在为布尔值存储 32 位整数时我会丢失一些东西吗？

我认为在这一点上查询速度，选项 2 是最好的，但我想大声询问存储和检索方面的意见，因为我不太了解 Azure 表（我希望这个帮助其他人）。

【问题讨论】：

标签： azure azure-storage azure-table-storage

【解决方案1】：

表存储不会在服务器端进行聚合，因此对于这两个选项，您最终都会在本地提取所有行（及其所有属性）并进行计数/求和。这使得它们的性能同样糟糕。 :-)

我认为你最好保留一个运行总计，而不是每次都重新总结所有内容。我们在 Cloud Cover 第 43 集讨论了一些模式：http://channel9.msdn.com/Shows/Cloud+Cover/Cloud-Cover-Episode-43-Scalable-Counters-with-Windows-Azure

【讨论】：

在发布我的问题之前，我已经看过您的博客文章并下载了源代码。我确实观看了这一集，尽管它非常令人难以忍受（iPad iTunes 下载的音频很好，但视频非常可怕 - 一次又一次地向前跳跃 - 使其完全无法观看）并且在我的笔记本电脑上观看网络它一直在缓冲（速度测试。网说我的骗局是 2.88 Mbps 下载）。所以我花了一个半小时才看完你的 30 分钟一集。仅供参考，对于那些进来的人，请擦洗到 9:30 标记，他们开始讨论跟踪计数的模式。
@smarx 我以为你为你的博客实现了 cmets。他们发生了什么？您应该在节目结束时使用您的 cmets 更新有关使用 DeploymentId 作为分区的博客文章和源代码。
@smarx 最后，我对您的回答的看法：所以您是说我不应该真正使用日志并计算日志数据 b/c 它最终成为序列化的一大动力XML 和通过 HTTP b/c 发送所有聚合都不能在本地完成。这是否意味着拥有更细粒度的对象（更少的属性）更好，因为它们更容易拉回？我能做的最好的计数就是同步每个线程的计数，这是否可靠？我走的是日志数据 b/c 的方式，我根本不需要任何锁。
我的博客上确实有 cmets...删除了它们，因为除了垃圾邮件之外没有其他内容。（现在大多数反馈都发给 Twitter，这很适合我。）至于手头的任务，是的，我是说你拉下来计数的日志似乎不是最佳的。对于少量数据可能没什么大不了的，但是由于您担心用于存储布尔值的位数，我怀疑您预计会有很多数据。有很多选择，但我认为重要的是保持一个总数，而不是（或除了）一个日志。
谢谢，史蒂夫。但是，您没有回答我的另一个问题是每个部署计数的每个线程上的互锁是否得到保证。是吗？