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

对于一个纯JAVA实现的项目，有如下一些需求，采取何种方案为好呢：
        并发的、大数据量的持久化（最少15G/天）；
        大量的报表统计（对上面收集的各种数据做统计，时间跨度月、周、天....不等）；
        第一时间反应要敏捷；
        要求支持多个主流数据库系统；
        并发用户访问量不大；
        这是一个产品型的项目；
对于以上这么一个需求，采取什么实现比较合理?这里的合理第一位为性能，然后才考虑可维护性、扩展性（首先、然后都很重要，不能太有偏向）。个人认为项目的可维护性和扩展性主要与程序的具体设计有关系，与采取什么样的持久化方案关系不大，这里要考虑的其实就一个性能问题。
    呵呵，以前主要做行业软件，初次接触产品型的开发，也很少碰到这么大的数据量，感觉比较紧张，恭请各位赐教......
   

正好今天有个朋友问了一个类似的问题，给出以下建议吧，不一定成熟：
1、首先是数据归类，比如常变数据和不变数据及偶尔变化的数据
2、数据分域，比如说把不变数据按照业务规则直接输出到硬盘文件中，统计的时候，就可以合并这些文件，而不是从数据库中查找。
3、有一个统一的缓存入口，避免不必要的并发
4、要有后台线程，定时或者趁系统闲的时候跑报表
5、建议专用一台或者多台无状态服务器专门负责分域生成报表
6、适当的减少或者干脆不缓存报表数据，否则很容易OOM的。
7、适当的用数据库的特性，如存储过程，集群。
8、接口设计上一定要用心，否则万一出现了问题，连改进的机会都没有了

http://hadoop.apache.org/pig/

看看， 有点意思哦

谢谢wl95421兄！很好的建议，我们的设想也有一些地方类似：
    1、数据量太大，设计的时候要尽量减少冗余（不能过多牺牲性能），同事根据数据将可能的使用频率进行分类；
    2、定期的（周、月）对数据进行合并搜理，对合并过后的数据进行整理，按将可能的使用频度进行处理（无用、少用、常用）；
    3、考虑这是项目，不可能要求客户准备太多的硬件设备，这里假设只有一台机器，在机器空闲的时间（比如深夜），做数据的合并整理工作；
    4、由于批处理的数据量太大，并发访问量不大，不建议缓存数据（这点与WL95421兄的建议有不同）；
    5、既然是产品，设计是的用心、小心，不然肯定惨；

    对与存储过程，用的很少，这里的数据不复杂，不存在对其过多的处理操作，对于这样的情况，用存储过程有优势吗？


     对于sdh5724兄的PIG正在看，谢谢！
   

存储过程从任何角度都是不利的。

我们说， 业务绑在数据库上， 非常不利于开发。 特别是变化比较大的应用。 大规模的数据尽量避免join等复发操作。 另外分阶段， 利用晚上空闲时间统计阶段性数据。 避免一次长时间跨度的计算。

菜鸟发表一下自己的意见。说错不要见怪。。
明确一下，并发用户访问是B/S吗，一般报表的查询都是用浏览器比较便利吧。
如果是通过浏览器那么J2EE这部分可以单纯的通过数据库显示报表。
所谓第一时间敏捷就是查询最新的实时的数据吧。那么就后台的统计可以分为两个部分统计，一个是实时的统计，一个是历史的维护。实时统计的程序用来统计收集来的数据，或读写磁盘文件或建临时表，15G对于数据库来说不是很大。历史的统计的程序可以跑线程定时服务器压力小的时候来完成。

别谦虚。
我没说清楚，这里的敏捷性是指反应要快，就是速度，不是实时的数据处理，对于数据的采集是定时循环的。对于统计不打算采取实时的，由于一次的数据量不小，如果实时统计的话会给系统太大的压力，打算采用定时任务调度的方式进行统计。

项目支持多数据库，如果存储过程没有绝对的优势，是不打算采用的（这里考虑要支持各种主流的关系数据库，而存储过程一般在具体数据库有一定的区别，所以不怎么想用，主要是怕麻烦 ）。

找个会C的来写吧 毕竟低层的程序都是C来写的，最起码环境不用担心

1、hadoop我不建议使用，我最近在研究这些东西，还是非常复杂，我觉得冒然引入一个复杂度这么高的系统，很可能引起项目的失败。

2、关于缓存，要看你的具体情况，我的建议还是一定要慎重，其实很多问题也都是出在缓存上，包括性能，OOM之类。

3、不管并发量是多少，一定要考虑到，一是因为再少的报表并发都可能引发大量的数据处理，对性能和稳定都会造成大的影响；二是没有人可以猜到未来的并发数。

数据量大的情况下不用存储过程？
那就说明还不够大。。。。