讨论：大数据量的报表统计，性能作为第一考虑采取何种方案好

统计第一位的应该是准确和稳定

最少15G/天 其实没多大 但是对关系数据库来说。。。 （咱这里是每天300G，每天统计前一天的,...）

关系数据库还是更适合于存储、检索，格式化规范化之后的数据，计算能力相当没什么说服力，存储过程也就那么回事儿

最近尝试hadoop中，那东西对机器、网络环境都有要求，达不到的话确实是很不稳

考虑一下Erlang

我在一个项目中，数据量就挺大的，因为数据本有5分钟、半小时、小时、天、周、月等粒度的，然后整个上数据的瞬间一般都是要处理60、70个文件的，小点的文件大概1、到70条数据不等，大的文件数据量达1000—2000多条数据的。还好这个程序的设计者做得比较好，采用并发进程，即使上万个文件，只要不是通一类的，都会比较快的处理入库，只是如果都是一个类的，就得队列等待了。

我感觉做的跟你说的项目需求挺像的，呵呵。

   前段时间刚刚做完一个在网页用户行为的统计系统，类似于google统计系统  对于加入我们系统的每一个网站，需要记录用户在上面的每一次行为，包括多少pv,click,访问了哪些页面等等。 有过这方面经验的人都知道这个数据是相当大的，按照前面同学们的建议，一种做法肯定是， 将当天所有用户的行为记录写入文件，由后台线程每隔一段时间来处理，写入数据库，统计分析出报表，写库统计的频率可能要根据数据量的具体大小等因素来考虑。用户不能查询当天的数据。采用的技术最好是C++。
   而我们的产品经理比较BT,提出比google统计更过分的需求(google是推迟2-3个小时出数据)，必须能够查询前15分钟的实时数据，这个数据当然还必须经过分析处理的统计数据，面对这样的需求，几经周折，历时4个月，才终于开发出总pv仅2000万的系统(失败，前期勉强够用，还不知道未来的变化，因为公司业务转向原因，暂时保持维护状态)，
采用的技术java+mysql ，系统结构是后台分为多个节点，每一个节点是一个进程，第一个节点接受数据，发送数据到另外一个节点，由后续的节点一次对数据进行处理统计，每一个节点缓存一定时间内(30个小时，可设定)的统计数据，因为量大，存在功能相同的并行节点，最后由各个主题及指标的节点写库。
   这个系统应该说不是一个很成功的系统，不过确实里面包含的东西还是挺多的，我们在考虑并发，性能上还是花费了相当大的功夫。 

   楼主上面的需求，我觉得还是非常容易满足的，中间有几位同学总结得不错，有些方面注意一下就可以啦。

最近也遇到类似的项目，每月有8700万的数据量，要保存6个月的数据量，一直考虑怎样去访问，性能会快一些。

我这每天的数据是20G。
常规的汇总可以结合缓存服务器、分阶段提交、表分区来处理。
目前没解决的问题是TOP N。
头疼很久了。