MYSQL插入问题及单表查询问题

系统遇到瓶颈了：
1. 100个线程一起从activeMQ上接收数据并转存到mysql中，每秒大约2000条数据，现在的问题是插入效率慢，导致activeMQ上的数据堆积，最终使得activeMQ占用内存过大而崩溃。求解决办法！
2. 单表数据过上亿，如何做数据统计，现在每次查询统计的时间实在是没法说啊，语句中包含count()之类的，求解决办法啊！

求各位大牛给指条明路！

100分给参与者，每个问题被采纳者各100分，共300 分！ --------------------编程问答-------------------- 采纳者我另加贴散分！ --------------------编程问答-------------------- 1、插入数据慢，插入的是什么类型的数据，允许数据丢失么？
数据库分表，加节点
打开日志缓冲（可能要丢数据）
所有数据多线程丢进文件里，半夜一起load

2、 mysql要对付单表过E，数据文件得有20G往上了吧？
说实在不好搞，要不就换数据库，要不就上hadoop吧 --------------------编程问答-------------------- 另外，你数据库是怎么架构的，2000的TPS,好家伙，太大了 --------------------编程问答--------------------

引用 2 楼 ygycomon 的回复:

1、插入数据慢，插入的是什么类型的数据，允许数据丢失么？
数据库分表，加节点
打开日志缓冲（可能要丢数据）
所有数据多线程丢进文件里，半夜一起load

2、 mysql要对付单表过E，数据文件得有20G往上了吧？
说实在不好搞，要不就换数据库，要不就上hadoop吧

1.插入慢是我意象的，可能也不慢，反正现在mysql的插入效率是1500/秒，不知道慢不，插入的是数据对象，有50多个字段，但每个字段都不是很长，如果5000条丢个几条的话，可以考虑。
日志缓冲不知道能丢多少数据？
数据是不间断传输的，只是晚上的数据量比白天数据量小而已，估计丢进文件的想法不大可能实现，经过你一说，我想每个小时建立一个数据文件，再把文件load到数据库不知道效率能提高不，是个想法。
2，你说的太对了，估计每天的数据文件大小有15个G左右吧
换数据库的话，该换什么数据库比较好呢？
hadoop没听过，貌似是个好东西，学习学习

谢谢了 --------------------编程问答--------------------

引用 4 楼 szx_zsx 的回复:

Quote: 引用 2 楼 ygycomon 的回复:

1、插入数据慢，插入的是什么类型的数据，允许数据丢失么？
数据库分表，加节点
打开日志缓冲（可能要丢数据）
所有数据多线程丢进文件里，半夜一起load

2、 mysql要对付单表过E，数据文件得有20G往上了吧？
说实在不好搞，要不就换数据库，要不就上hadoop吧

1.插入慢是我意象的，可能也不慢，反正现在mysql的插入效率是1500/秒，不知道慢不，插入的是数据对象，有50多个字段，但每个字段都不是很长，如果5000条丢个几条的话，可以考虑。
日志缓冲不知道能丢多少数据？
数据是不间断传输的，只是晚上的数据量比白天数据量小而已，估计丢进文件的想法不大可能实现，经过你一说，我想每个小时建立一个数据文件，再把文件load到数据库不知道效率能提高不，是个想法。
2，你说的太对了，估计每天的数据文件大小有15个G左右吧
换数据库的话，该换什么数据库比较好呢？
hadoop没听过，貌似是个好东西，学习学习

谢谢了

引用 4 楼 szx_zsx 的回复:

Quote: 引用 2 楼 ygycomon 的回复:

1、插入数据慢，插入的是什么类型的数据，允许数据丢失么？
数据库分表，加节点
打开日志缓冲（可能要丢数据）
所有数据多线程丢进文件里，半夜一起load

2、 mysql要对付单表过E，数据文件得有20G往上了吧？
说实在不好搞，要不就换数据库，要不就上hadoop吧

1.插入慢是我意象的，可能也不慢，反正现在mysql的插入效率是1500/秒，不知道慢不，插入的是数据对象，有50多个字段，但每个字段都不是很长，如果5000条丢个几条的话，可以考虑。
日志缓冲不知道能丢多少数据？
数据是不间断传输的，只是晚上的数据量比白天数据量小而已，估计丢进文件的想法不大可能实现，经过你一说，我想每个小时建立一个数据文件，再把文件load到数据库不知道效率能提高不，是个想法。
2，你说的太对了，估计每天的数据文件大小有15个G左右吧
换数据库的话，该换什么数据库比较好呢？
hadoop没听过，貌似是个好东西，学习学习

谢谢了

1、打开日志缓冲是常用的优化，宕机会丢数据，不过这不能解决根本问题，如果你是单机的话，还是考虑分表一次性load会比较好，一天，或者几个小时load一次，不要实时写了，2000tps，我估计mysql会挂

2、换数据库的话，用商业数据库还是可以解决问题。看你的数据增量是多少，如果就是给定的E级别的数据分析，上个商业数据库就可以搞定，如果增量也很大的话，比如每天增加10G数据，那还是上hadoop吧，这个资料很多，你可以自己去找 --------------------编程问答--------------------

引用 5 楼 ygycomon 的回复:

1、打开日志缓冲是常用的优化，宕机会丢数据，不过这不能解决根本问题，如果你是单机的话，还是考虑分表一次性load会比较好，一天，或者几个小时load一次，不要实时写了，2000tps，我估计mysql会挂

2、换数据库的话，用商业数据库还是可以解决问题。看你的数据增量是多少，如果就是给定的E级别的数据分析，上个商业数据库就可以搞定，如果增量也很大的话，比如每天增加10G数据，那还是上hadoop吧，这个资料很多，你可以自己去找

这两种不错：1，几个小时load一次（单机方案） 2，hadoop （hadoop成本是不是很高呢？两台机器可以做吗？我知道3台可以）
说实话，现在也没想好到底用哪种机制 --------------------编程问答-------------------- 1、估算数据量，性能压力，初步架构设计
2、测试，找出瓶颈
3、性能分析、针对瓶颈修改架构

LZ你还是一步一步来吧，先把基础的数据量和性能压力估算清楚，测过了之后再来考虑怎么搞 --------------------编程问答-------------------- 我觉得你的首要问题是解决pendding太多，导致内存溢出和数据库容量问题。建议还是架设个集群服务器处理吧。 --------------------编程问答--------------------

引用 8 楼 huxiweng 的回复:

我觉得你的首要问题是解决pendding太多，导致内存溢出和数据库容量问题。建议还是架设个集群服务器处理吧。

他单表过E的数据，这种底层架构方式想拆成集群都难，瓶颈在数据库卡死了 --------------------编程问答--------------------

引用 9 楼 ygycomon 的回复:

Quote: 引用 8 楼 huxiweng 的回复:

我觉得你的首要问题是解决pendding太多，导致内存溢出和数据库容量问题。建议还是架设个集群服务器处理吧。

他单表过E的数据，这种底层架构方式想拆成集群都难，瓶颈在数据库卡死了

这个是他其中一个问题，他还有个问题是activeMQ上的数据堆积，最终使得activeMQ占用内存过大而崩溃。
--------------------编程问答--------------------

数据库啊！ --------------------编程问答-------------------- 多方面下手，
1、看表的特性，建议将表分区，可行的话，将分成多张表操作，插入到多表后通过数据库任务再执行写入到单表中，即将数据库缓冲处理，后期可以将表数据转存。
2、再可以做数据分析后，将数据分析结果保存进数据库，避免你大数据量计算成问题。
3、做服务器集群操作，oracle的处理需要这样去处理的，大型企业和银行都是这样处理的。
--------------------编程问答--------------------

引用 10 楼 huxiweng 的回复:

这个是他其中一个问题，他还有个问题是activeMQ上的数据堆积，最终使得activeMQ占用内存过大而崩溃。

activeMQ数据堆积的主要原因就是消费者的消费效率慢，耗时就是在插入数据库的时候，我觉得只要是提高了插入数据的效率（前提是数据库能扛住），其他的就不算是问题了！就是不知道该用什么数据库 --------------------编程问答--------------------

引用 13 楼 szx_zsx 的回复:

Quote: 引用 10 楼 huxiweng 的回复:

这个是他其中一个问题，他还有个问题是activeMQ上的数据堆积，最终使得activeMQ占用内存过大而崩溃。

activeMQ数据堆积的主要原因就是消费者的消费效率慢，耗时就是在插入数据库的时候，我觉得只要是提高了插入数据的效率（前提是数据库能扛住），其他的就不算是问题了！就是不知道该用什么数据库

所以你需要分布式去插入数据，比如搞个10个数据库，10个instance，每个instance10个线程去activeMQ取数据，插入不同的数据库

补充：Java ,  Java相关