大数据量统计

基本是这个意思。中间产生的临时表用db的确很方便，但是速度肯定bdb快，毕竟减少了网络时间。临时表大概会有10多张，每张表都在千万级的数据量。如果非常频繁的更新数据库表，mysql的master-slave同步会变慢，这样就会造成插进去的数据过几十分钟甚至几个小时才能在slave中看到，会给其他应用带来问题。因此考虑用bdb。

去补习一下BI的基本架构的知识就可以了。用ETL抽取出来，再用CUBE分析吧。就是实时性差一点，不过你这么大的数据量，做实时统计，DBA估计也会吃人的。

对于大数据量的统计，可以建一个新表，定时统计，比如1小时一次。
然后最后对这1小时的统计表 进行统计。

楼主的情况 即使1分钟统计一次 也不过分

可以用内存数据库

没必要用数据库，以前我曾经也做过这样的系统。
具体步骤分以下几步：
1、压缩，我们一般会保存一个月的日志备查，如果不做这一步的话，一台服务器可能无法保留下这么多日志内容。如果是网站的日志的话，为了节省空间，一般会把URL 之类的较长字串替换成自定义的短的字串，这样一般文本长度会变成原来的1/10 大小
2、分片，遍历这个日志文件，按照需要count 的字段进行hash 切分，如果是1亿的数据量的话，可以分成1024 个文件
3、统计，这里可以用多线程，也可以放到多个服务器并发处理，每个进程统计的结果写入各自文件中
4、汇总，将所有的统计结果汇总，如果还存在相同项，进行合并

这套流程，即使日志有300G 也可以很轻松处理，只存在处理时间长短的问题

一  “实时统计” 1亿数据是在24*60=1440 分钟内完成的
假设数据是平均产生的，则 每分钟 69444 条。考虑到数据产生的峰值，假设为十万条。
那么每分钟 对10万条数据做次统计，应该不是什么问题

二  “分表统计” 1亿数据放到一张表里做统计显然不是什么好办法，避免锁定。这个数量级的数据，比如信令或者话单。在业务系统里，差不多一分钟要有一张表。每张表内十来万。 使用多线程后台处理，必要的话，加入队列机制。

p.s. 能在数据库做就在数据库做 以上的统计部分完全可以使用存储过程来实现
把1~2亿数据都取出来读一遍，统计完再删除，是在加剧臭氧层恶化。
考虑到jvm的回收效率和编码水准，很难乐观你的jvm不会在这一次次的gc中拥塞到满

我做过这种东西, 用的是 C++ 和 文本文件, 最后只把统计结果存到数据库

超级潜水员 数据库很厉害的吗~

呵呵，上次我们公司３０００万个手机号都不敢用java做排重！

建议你把数据处理的需求写得更加易懂一些，比如你的原始数据是什么格式，增长方式如何，是一个大文件递增？你要统计的报表数据关系复杂度如何，是否复杂sql才能搞定？还是在内存中计算更为合理？统计结果的数据量级如何，围度有多少，等等。

你的需求描述不够清晰，如果能描述得更好的话能够获得更多好的建议。

粗粗认为，你的主要任务是提高处理的效率，与分布式并行计算有关，至于是否需要数据仓库支持，这个要跟你的统计复杂度有关，既然只能用mysql，要搞挖掘难度较大。