Chinaunix首页 | 论坛 | 博客
  • 博客访问: 140836
  • 博文数量: 15
  • 博客积分: 243
  • 博客等级: 入伍新兵
  • 技术积分: 185
  • 用 户 组: 普通用户
  • 注册时间: 2011-08-20 08:51
文章分类

全部博文(15)

文章存档

2015年(2)

2014年(6)

2013年(1)

2012年(6)

我的朋友

分类: Python/Ruby

2014-06-17 23:32:07

之前用python写了一个实时分析日志文件的脚本,对分析的数据结果写入mysql数据库。期初因为对入库的实时性没有做太多关注,最近一个项目对数据写入db的实时性非常看重,发现之前的脚本在现在的场景下,会出现累积时间延迟。运行时间长了后,会产生很大的累积时延。
开始分析问题,还好在分析日志文件和入库的部分加了log打印,定位时先将入库部分屏蔽,发现实时分析系统么有问题,分析文本没有时延引入。
接下来看入库部分,开始优化sql,调整db的引擎,分表这些手段都使用了后,也没有改善。
在分析网络,写入的数据库和执行写入脚本的服务器分表部署在不同城市IDC,网络时延约为30ms,本地时延0.7ms。看到这个结果后,开始考虑同idc部署。
在开始申请资源的同时,也在考虑使用的入库方式。原来在每处理一条业务数据的时候,就马上去写入db,这样因为mysql的同步API导致每次都会引入一定时延,然后这个引入时延就会叠加到处理下一条文件数据。随着数据量增大就会带来更大的时延
开始考虑读取一定量的文本数据后,再批量写入一次DB。按照这个思路重新修改sql语句。类似“insert into table (name1,name2) values (val1,val2),(val11, val22)”,在mysql客户端上执行命令没有问题,但是用python的cursor.execute(sql)执行的时候发现,报语法错误。于是google这种情况,发现python的MySQLDb模块本身有个处理多条插入的接口:executemany。
于是赶紧加入到代码中验证,使用了批量提交后,基本分析都是实时了。引入的操作db时延,只会让下一次处理的文本数据内容多一些,不会累积产生时延。在入库操作快于文件生成速度时,不会带来时延问题。
另外在文本分析阶段,引入set,对重复数据做一次去重。
使用sql的insert ignore语句将主键重复的数据也丢弃掉,最终需要写db得数据就会很少
问题得到解决,结论值得思考,如果使用Python的模块时,最好多该模块的所有接口都了解一下,弄清楚使用场景。
另外分析这种实时系统里,一定要考虑各个环节带入的时延是否具有累积性。for循环内部不要引入时延
阅读(1562) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~