问题如下。我们实时收集一些数据，比方说每秒100个条目。我们希望有实时报告。报告应按小时显示数据。我们要做的就是创建一些传入数据并进行一些智能索引，这样我们就可以轻松地提供诸如“给我valueA for featureA = x，featureB = y，2012-01-01 09:00 - 的查询 - 10:00"
为了避免过多的I / O操作，我们在内存中聚合数据（这意味着我们将它们相加），然后将它们刷新到数据库。我们假设它每10秒左右发生一次，这对我们的实时报告来说是可接受的延迟。
所以基本上，在SQL术语中，我们最终得到20个（或更多）这样的表（好吧，我们可以通过组合sum来减少它们，但它没有太大的区别）：
（我不是说解决方案必须是SQL，我只是用它来解释手头的问题。）Time列是时间戳（小时精度），Feature列是系统实体的一些id，值是整数值（计数）。
所以现在问题出现了。由于数据的本质，即使我们聚合它们，这些聚合表仍然有很多插入。这是因为有些数据是稀疏的，这意味着对于每100个条目，我们有一些聚合表的50个条目。我知道我们可以通过升级硬件继续前进，但我觉得我们可以通过更智能的存储机制做得更好。例如，我们可以使用SQL数据库，但我们不需要它的大部分功能（事务，连接等）。
因此，考虑到这种情况，我的问题如下。你们如何处理大量流量的实时报告？谷歌以某种方式为网络分析做了这个，所以它毕竟是可能的。这里有秘密武器吗？我们对任何解决方案持开放态度 - 无论是Hadoop＆amp; Co，NoSQL，聚类或其他任何东西。
答案 0 :(得分：2)
除了分离收集和报告/分析的存储要求之外，我们过去经常做的事情之一是查看值发生重大变化的频率，以及数据的使用方式。
不知道您的数据是什么样的，但报告和分析通常会寻找重要的模式。在容忍中，反之亦然，特别是振荡。 现在虽然收集“无限量”的数据可能是值得称赞的，以防你想要分析它，当你遇到有限的实施时，必须做出选择。
我在制造环境中做过这样的事情。我们有两个级别的分析。一个用于控制，其粒度尽可能高。然后，随着过去数据的进一步发展，我们对其进行了总结，以便进行报告。
我遇到了你看起来多次出现的问题，虽然数据丢失受到了谴责，但是关于它需要多少费用的投诉要大得多。
因此，我不会仅从技术角度来看这个问题，而是从实际的业务角度来看。从企业认为它能承受多少钱开始，看看你可以为它提供多少。