公司最近要作相似关注与粉丝的功能,须要将以前已经加为好友或者已经提交好友请求的数据转化为follow关系,我设计了两个表,follow和fan,同时在user_info表中添加了follow_count和fan_count两个字段,在功能上线以前,须要将现网的数据导出,而后转化为follow关系再导入,总数据为75万条(社区刚放开,尚未大规模推广)。mysql
策略1:sql
根据导出的通过排序的uid来操做,一共75万insert操做,75万update操做,整理写成sql文件, 直接cat sql | mysql 执行,竟然一个下午都没有完成,经过show processlist发现没死,还在一个一个执行,只能中断操做ui
策略2:设计
将策略1生成的sql请求分红10份,有点并行操做的意思,结果仍是一下午没有作完(其实没有从本跟上解决问题)排序
策略3:队列
通过分析,肯定问题确定在随机uid的insert和update操做使得mysql频繁的跨库跨表lock table和unlock taoble,时间都花费在表的切换上了。因而决定将操做按照db和table进行分类, 采用了multimap结构,进程
multimap< string, string > insert_query;ssl
multimap< string, string > update_query;资源
以db_xx.table_xx为key,value就是要执行的sql,这样生成了两个sql:insert.sql和update.sql, 执行结果:string
insert complete --- sns_user_97.user_follow_96
insert complete --- sns_user_97.user_follow_97
insert complete --- sns_user_97.user_follow_98
insert complete --- sns_user_97.user_follow_99
insert complete --- sns_user_98.user_follow_00
insert complete --- sns_user_98.user_follow_01
insert complete --- sns_user_98.user_follow_02
insert complete --- sns_user_98.user_follow_03
insert complete --- sns_user_98.user_follow_04
insert complete --- sns_user_98.user_follow_05
insert complete --- sns_user_98.user_follow_06
insert complete --- sns_user_98.user_follow_07
能够清晰的看到,顺序执行sql操做使得lock table形成的消耗降到了最低,最终结果:
update 1分钟内完成
insert 10分钟完成
策略4:
将策略3的结果sql按照key分红N块,起N个进程并行执行,这样会在1分钟以内完成,由于不一样的表根本不会有锁的进程,效率提高会又上一个量级
从这个经验我想到了两点:
1.任务的队列化,若是任务的执行会涉及到大范围的随机跳转操做,而这种跳转还会引发资源竞争,那么最好的办法就是将任务队列化,按照跳转最少,资源竞争最少的原则进行排序。
2.在任务队列化的基础上,map/reduce
(备注:咱机器不行,你们不要太在乎那个10分钟的时间消耗,我只是说有下这种思路,但愿你们多多拍砖)