mysql大数据量下访问实践

最近参与了一些用户相关系统的开发,经历了数据库在大数据量下出现的一些问题,记录备忘,也请有经验的牛们指点指点。

目前数据量大概在40亿条左右,最近1周大概增长了50%左右,后面可能会小一些,每天预估在几百到几千W条左右。

功能:

java服务接口接收请求,执行sql操作。

查询:

读操作共有5,6种,group by, max()比较多,查询数据时间范围在1年左右。但要求尽可能的实时,同时并发量较大,记得出现过一次1分钟内某个查询执行了260W次左右的情况。一般情况下1秒钟有1W条左右的sql在执行,除了1个write,1个update,其他都是查询。

阶段1:

开始时按照1主1从的结构部署,读写都在主库。共分了5个库,每个库上400张表(同一张表)。当单表数据量达到100W条后,读操作出现瓶颈,导致mysql load高,io等待严重。考虑将读操作分离到读库上,来减小主库上的压力。

阶段2:

读操作切到读库上后,当天就出现读库load居高不下,频繁报警等情况。DBA建议可减少调用量来降低mysql压力,经过业务分析后,减少了一些不必要的调用,大概减少了1/10左右的调用量,但并发量还是很大,报警依旧。DBA组建议添加1组读库来分担读压力,应用也进行了相应地调整。

阶段3:

在前两个阶段中还出现了主从不同步的问题,后来采用了对索引进行调整的策略来应对。

1.减少从库上的索引来加快数据同步的速度,有一定的效果,但期间从库数据也重做过。

2.减少主库的索引,一定程度上提高了写操作的性能。

阶段4:

为了提高读库的访问性能,1组从库上了fusion卡,从性能监控比较,安装卡后的库在大致相同的处理性能下,可多承担3-5倍的读操作。

数据还在不断增加,比较担心数据的访问性能,尤其是查询数据的时间段比较大,如果单表数据量增大到500W后...

猜你喜欢

转载自qify.iteye.com/blog/2111454