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

[赏金--猎人]

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

求各位大牛给指条明路！

100分给参与者，每个问题被采纳者各100分，共300 分！

[赏金--猎人]

采纳者 我另加贴 散分！

[致知Fighting]

1、 插入数据慢，插入的是什么类型的数据，允许数据丢失么？ 数据库分表，加节点 打开日志缓冲（可能要丢数据） 所有数据多线程丢进文件里，半夜一起load 2、 mysql要对付单表过E，数据文件得有20G往上了吧？ 说实在不好搞，要不就换数据库，要不就上hadoop吧

[致知Fighting]

另外，你数据库是怎么架构的，2000的TPS,好家伙，太大了

[致知Fighting]

引用 4 楼 szx_zsx 的回复:

[quote=引用 2 楼 ygycomon 的回复:] 1、 插入数据慢，插入的是什么类型的数据，允许数据丢失么？ 数据库分表，加节点 打开日志缓冲（可能要丢数据） 所有数据多线程丢进文件里，半夜一起load 2、 mysql要对付单表过E，数据文件得有20G往上了吧？ 说实在不好搞，要不就换数据库，要不就上hadoop吧

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

引用 4 楼 szx_zsx 的回复:

[quote=引用 2 楼 ygycomon 的回复:] 1、 插入数据慢，插入的是什么类型的数据，允许数据丢失么？ 数据库分表，加节点 打开日志缓冲（可能要丢数据） 所有数据多线程丢进文件里，半夜一起load 2、 mysql要对付单表过E，数据文件得有20G往上了吧？ 说实在不好搞，要不就换数据库，要不就上hadoop吧

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

[致知Fighting]

1、估算数据量，性能压力，初步架构设计 2、测试，找出瓶颈 3、性能分析、针对瓶颈修改架构 LZ你还是一步一步来吧，先把基础的数据量和性能压力估算清楚，测过了之后再来考虑怎么搞

[teemai]

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

[致知Fighting]

引用 8 楼 huxiweng 的回复:

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

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

[teemai]

引用 9 楼 ygycomon 的回复:

[quote=引用 8 楼 huxiweng 的回复:] 我觉得你的首要问题是解决pendding太多，导致内存溢出和数据库容量问题。建议还是架设个集群服务器处理吧。

他单表过E的数据，这种底层架构方式想拆成集群都难，瓶颈在数据库卡死了[/quote] 这个是他其中一个问题，他还有个问题是activeMQ上的数据堆积， 最终使得activeMQ占用内存过大而崩溃。

[杨家小白]

数据库啊！

[赏金--猎人]

引用 2 楼 ygycomon 的回复:

1、 插入数据慢，插入的是什么类型的数据，允许数据丢失么？ 数据库分表，加节点 打开日志缓冲（可能要丢数据） 所有数据多线程丢进文件里，半夜一起load 2、 mysql要对付单表过E，数据文件得有20G往上了吧？ 说实在不好搞，要不就换数据库，要不就上hadoop吧

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

[qiuqiupeng]

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

[赏金--猎人]

引用 10 楼 huxiweng 的回复:

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

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

[teemai]

引用 13 楼 szx_zsx 的回复:

[quote=引用 10 楼 huxiweng 的回复:] 这个是他其中一个问题，他还有个问题是activeMQ上的数据堆积， 最终使得activeMQ占用内存过大而崩溃。

activeMQ数据堆积的主要原因就是 消费者的消费效率慢，耗时就是在插入数据库的时候，我觉得只要是提高了插入数据的效率（前提是数据库能扛住），其他的就不算是问题了！ 就是不知道该用什么数据库 [/quote] 所以你需要分布式去插入数据，比如搞个10个数据库，10个instance，每个instance10个线程去activeMQ取数据，插入不同的数据库