前言:
之前做项目的时候,遇到这么一个问题,对接方对推一些单子给我方的接口,而且数据内容很大,平均一条有10M左右.然后我们经过解析等处理以后存入数据库,随着每天项目的运行,数据量越来越大,导致了解析过程很慢,数据存储越来越大,导致磁盘空间不足.ps:一开始用的text,后来发现长度不够用,变成了mediumtext.于是,我们项目组考虑了一些方案.下面的内容是我自己想出来的方案中的一个,并做了一些测试,虽然最后没有采用我的方案,但还是记录一下过程,说不定以后会用到.
(最后用的是某云的压缩数据库,思路是一样的,压缩存储大数据,取出解析还原后在使用)
1.处理方式和预期结果:
主要采用Zlib压缩来减少数据库的磁盘占用,分别在接受订单信息上使用了Zlib的压缩和解压,来达到节省数据库磁盘空间的目的,磁盘IO的降低,一定程度上降低了数据库的压力,提高了系统的性能.个人见解:一般web的瓶颈最后都是到了io上,内存和cpu的压力没有那么大,数据库服务器会比应用服务器要贵很多,所以尽量不要把逻辑和过多的计算抛给数据库,应该在应用服务器处理掉
预期结果:
优化后的接受订单的时间可能对比以前可能会变慢或者相差不多,因为接受订单多了压缩字符串的过程,但是插入数据变快了.压缩消耗的是应用服务器的资源,数据库服务器压力减小了,响应时间可能会有一定的提高.
2.数据库空间节省对比
采用一万条数据为基准(一万条user_verify一样的数据).
操作步骤:
1.新建了一张t_user_verify的表,从图中可以看出没用存任何数据的t_user_verify占用了98304字节.
2.开始跑程序向表中插入一万条数据,10个线程跑每个循环1000次
循环1000次后的空间大小.
用sql查询数据大小
所以数据占用空间大概是1.7个G
3.记录储存空间大小,在创建一个t_user_verify_compress表,查看空表的大小,如下图,
4.用加入了压缩代码的程序去跑10个线程循环1000次.
程序跑完看使用空间大小,如下图.
压缩比:360/1707 ~21% Zlib级别设置为1(1-9数字越大压缩效果越好,时间也越长,在这里我设置的是1,速度快,压缩效果比较差,9级别则相反).
3.原程序与优化后的程序接受订单接口响应时间对比(服务器数据库)
原程序:
优化后:
4.分析和总结:
响应时间对比:
优化后,响应时间在0-10之间变化不明显.
在10-20及之后的对比开始有了差距;
在40-80差距开始变大,相差几乎有两倍.
结论:
1.优化后的程序,在0-10之间差距并不大,从10开始有了一定的差距,在40并发量以后,RT时间有一定的缩短;
2.磁盘空间节省了将近4/5.在节省mysql磁盘空间和优化响应时间上有比较大的进步.
可能存在的隐患/问题:
1.程序入口会打印日志和入参出参的参数,但由于接受订单接口的数据比较大(一般一条700KB左右,一共大概十几兆),会导致tomcat运行时间过长后,应用服务器的磁盘空间不够用.可以去掉log4j的consoleAppender,并且将tomcat/conf/logging.properies 下的日志级别设置为Warning,默认为Find.或者使用cronolog将日志切分.
2.数据即使被压缩了.随着时间的推移也会不断的增加,应该添加一个定期处理垃圾数据的机制.