mysql亿级数据表的维护讨论
时间：2010-03-09 来源：pkman110
Saver(792218) 14:54:40
接着昨天的面试来，请教个问题：背景：客户端记录用户机所有内存中跑的可执行程序，web网站等等，用户基数是千万数量级，每天会产生好几亿数据，这种情况下的mysql数据表如何去维护，提高其增删改查的性能呢？
Saver(792218) 14:55:01
群里的兄弟们给支支招
落落<[email protected]> 14:55:22
Saver，问你的问题 怎么都这么 变态呢
落落<[email protected]> 14:56:01
呵呵
Saver(792218) 14:57:32
赶紧给支支招
Saver(792218) 14:57:39
研究下这问题咋解决
叶金荣(4700963) 14:58:41
1. 提高可靠性
2. 提高性能
叶金荣(4700963) 14:58:46
归结为这2点
Saver(792218) 14:59:23
这个几天下来就好几亿吧，单表
Saver(792218) 14:59:43
然后需要刨去安全的，不需要关注的程序
把问题当机会(459472823) 15:00:01
日志文件、日志缓存设大点，用以减少日志的磁盘操作；
关闭autocmmit；
INSERT INTO tab VALUES (1,1), (2,2),... 降低客户端与服务器端的通信开销；
加大buffer pool，插入时减少磁盘 I/O；
读写分离...
Saver 说:
接着昨天的面试来，请教个问题：背景：客户端记录用户机所有内存中跑的可执行程序，web网站等等，用户基数是千万数量级，每天会产生好几亿数据，这种情况下的mysql数据表如何去维护，提高其增删改查的性能呢？
timothy 说:
这时候就不光是mysql的事儿了。
看具体需求，一定是把表分 的非常细。
横向总想 分表。
再安需求分库。。等。
Saver 说:
他现在是单表做
如何去维护，呵呵
timothy 说:
单表。。能承受这么大并发？
应该会用到队列等东西。
Saver 说:
人跟我讲的
说:
问题太泛了
timothy 说:
那要看具体需求吧？？
说:
这样很难回答的
Saver 说:
主要是这个东挖西挖，膨胀收缩
timothy 说:
如果是个超级简单的表儿。。
数据大 ，还要看读写 比例什么的。
Saver 说:
还有分析，分析之后删除无用的数据
写多读少
删除也多
初期快速膨胀
中后期开始收缩
timothy 说:
成千上万的用户同时写？？
他的mysql也太强大了。
isql 说:
我比较关心那个每个互联网公司都在用的东东，哈哈
到底是嘛？
说:
有这样的东西吗？
timothy 说:
mysql用的都很广泛的。
一般都会分表。。
Saver 说:
说白了就是用户习惯系统
[email protected] 说:
有呀，电脑，数据库，操作系统
isql 说:
saver说的
[email protected] 说:
就这三个吧。。。
isql 说:
saver给解释下
Saver 说:
就是，只要你上他的网站，用他的客户端
那么，他就会去收集你的相关信息
timothy 说:
http://z.xiaoi.com/r?www.sitebot.com.cn
我们公司的站点儿。。数据量三千万 我都觉得很累了。。
Saver 说:
不是这个玩意
类似这个
但是比这个收集的夸张的多
timothy 说:
总的来说问题太泛泛了
Saver 说:
比如说，用户当前跑的所有程序
用浏览过的所有web页面
用户点击过的链接
甚至用户所有的文档
都可以收集，分析，挖掘，然后变成资源
说:
这些都是存放成日志，通过hadoop来分析的
大部分公司都是用hadoop
数据量一天可以达到几十T
Saver 说:
那咱把这个圈子缩小点
缩小到每个客户端内存中跑的exe程序，然后对比md5判断，哪些是未知的，然后让客户端上传分析
这个数据量就变小了
说:
这个可以做到
根据md5值来hash存放数据就行了
表数量多一些，肯定能撑住的
Saver 说:
这个如何维护呢，一天的数据量在1-2亿很正常
然后后期就会越来越小
说:
表按照两个维度去划分
先按照时间，再按照hash
你可以定时移走老表
如果不想移走老表，那就hash多一些
一亿的数据，分割成1024个表
分布到多个服务器上
很容易实现并行运算，存储也不是问题
还可以加slave去增加吞吐量
Saver 说:
这样的话跨库的查询就会需要跨库的UNION，删除的时候也是如此了吧？ 说:
不需要的
看你们的删除条件是什么了
拆分表有很多种做法
还是要看常用的SQL是什么样的
Saver 说:
把已提取的认为是安全，无采集意义的玩意删除掉 说:
可以直接删除这些东西的
因为每个表的数据量都很小
删除的代价并不高
Saver 说:
就是需要操作多表感觉
说:
不一定
Saver 说:
不按用户分布？
说:
所有的查询都带有md5的话，那就可以根据md5来分库
分表
看你的SQL语句是什么样了
其实和用户没有关系的
找一个最合理的分表方式，抛弃不必要的需求，然后就能诞生一个稳健的系统
Saver 说:
嗯，这个系统最终的目的还是要去判断用户跑了哪些程序，判断这些程序是否有害，估计也只能算是附加功能
说:
是的
Saver 说:
但是如果是这样的话，那就涉及到按用户去统计的问题了
有可能极限情况是用户数据被分到N个表里
唉，这个应该算是代价的均衡问题了
不过分布式系统的优势就体现出来了，并行计算
比单表处理的性能要高了很多
说:
恩
最终还是要有取舍的
数据聚集是分布式最头疼的问题
但是有些系统没有数据聚集需求
可以先做
Saver 说:
挖掘的话，那肯定是要聚集的
接着昨天的面试来，请教个问题：背景：客户端记录用户机所有内存中跑的可执行程序，web网站等等，用户基数是千万数量级，每天会产生好几亿数据，这种情况下的mysql数据表如何去维护，提高其增删改查的性能呢？
Saver(792218) 14:55:01
群里的兄弟们给支支招
落落<[email protected]> 14:55:22
Saver，问你的问题 怎么都这么 变态呢
落落<[email protected]> 14:56:01
呵呵
Saver(792218) 14:57:32
赶紧给支支招
Saver(792218) 14:57:39
研究下这问题咋解决
叶金荣(4700963) 14:58:41
1. 提高可靠性
2. 提高性能
叶金荣(4700963) 14:58:46
归结为这2点
Saver(792218) 14:59:23
这个几天下来就好几亿吧，单表
Saver(792218) 14:59:43
然后需要刨去安全的，不需要关注的程序
把问题当机会(459472823) 15:00:01
日志文件、日志缓存设大点，用以减少日志的磁盘操作；
关闭autocmmit；
INSERT INTO tab VALUES (1,1), (2,2),... 降低客户端与服务器端的通信开销；
加大buffer pool，插入时减少磁盘 I/O；
读写分离...
Saver 说:
接着昨天的面试来，请教个问题：背景：客户端记录用户机所有内存中跑的可执行程序，web网站等等，用户基数是千万数量级，每天会产生好几亿数据，这种情况下的mysql数据表如何去维护，提高其增删改查的性能呢？
timothy 说:
这时候就不光是mysql的事儿了。
看具体需求，一定是把表分 的非常细。
横向总想 分表。
再安需求分库。。等。
Saver 说:
他现在是单表做
如何去维护，呵呵
timothy 说:
单表。。能承受这么大并发？
应该会用到队列等东西。
Saver 说:
人跟我讲的
说:
问题太泛了
timothy 说:
那要看具体需求吧？？
说:
这样很难回答的
Saver 说:
主要是这个东挖西挖，膨胀收缩
timothy 说:
如果是个超级简单的表儿。。
数据大 ，还要看读写 比例什么的。
Saver 说:
还有分析，分析之后删除无用的数据
写多读少
删除也多
初期快速膨胀
中后期开始收缩
timothy 说:
成千上万的用户同时写？？
他的mysql也太强大了。
isql 说:
我比较关心那个每个互联网公司都在用的东东，哈哈
到底是嘛？
说:
有这样的东西吗？
timothy 说:
mysql用的都很广泛的。
一般都会分表。。
Saver 说:
说白了就是用户习惯系统
[email protected] 说:
有呀，电脑，数据库，操作系统
isql 说:
saver说的
[email protected] 说:
就这三个吧。。。
isql 说:
saver给解释下
Saver 说:
就是，只要你上他的网站，用他的客户端
那么，他就会去收集你的相关信息
timothy 说:
http://z.xiaoi.com/r?www.sitebot.com.cn
我们公司的站点儿。。数据量三千万 我都觉得很累了。。
Saver 说:
不是这个玩意
类似这个
但是比这个收集的夸张的多
timothy 说:
总的来说问题太泛泛了
Saver 说:
比如说，用户当前跑的所有程序
用浏览过的所有web页面
用户点击过的链接
甚至用户所有的文档
都可以收集，分析，挖掘，然后变成资源
说:
这些都是存放成日志，通过hadoop来分析的
大部分公司都是用hadoop
数据量一天可以达到几十T
Saver 说:
那咱把这个圈子缩小点
缩小到每个客户端内存中跑的exe程序，然后对比md5判断，哪些是未知的，然后让客户端上传分析
这个数据量就变小了
说:
这个可以做到
根据md5值来hash存放数据就行了
表数量多一些，肯定能撑住的
Saver 说:
这个如何维护呢，一天的数据量在1-2亿很正常
然后后期就会越来越小
说:
表按照两个维度去划分
先按照时间，再按照hash
你可以定时移走老表
如果不想移走老表，那就hash多一些
一亿的数据，分割成1024个表
分布到多个服务器上
很容易实现并行运算，存储也不是问题
还可以加slave去增加吞吐量
Saver 说:
这样的话跨库的查询就会需要跨库的UNION，删除的时候也是如此了吧？ 说:
不需要的
看你们的删除条件是什么了
拆分表有很多种做法
还是要看常用的SQL是什么样的
Saver 说:
把已提取的认为是安全，无采集意义的玩意删除掉 说:
可以直接删除这些东西的
因为每个表的数据量都很小
删除的代价并不高
Saver 说:
就是需要操作多表感觉
说:
不一定
Saver 说:
不按用户分布？
说:
所有的查询都带有md5的话，那就可以根据md5来分库
分表
看你的SQL语句是什么样了
其实和用户没有关系的
找一个最合理的分表方式，抛弃不必要的需求，然后就能诞生一个稳健的系统
Saver 说:
嗯，这个系统最终的目的还是要去判断用户跑了哪些程序，判断这些程序是否有害，估计也只能算是附加功能
说:
是的
Saver 说:
但是如果是这样的话，那就涉及到按用户去统计的问题了
有可能极限情况是用户数据被分到N个表里
唉，这个应该算是代价的均衡问题了
不过分布式系统的优势就体现出来了，并行计算
比单表处理的性能要高了很多
说:
恩
最终还是要有取舍的
数据聚集是分布式最头疼的问题
但是有些系统没有数据聚集需求
可以先做
Saver 说:
挖掘的话，那肯定是要聚集的
相关阅读 更多 +
