浅析海量小文件的存储

海量小文件(LOSF,lots of small files)的存储是很多公司都遇到的难题,不管是互联网公司(如社交网站)还是传统的IT企业(如医疗IT的PACS厂商),都会遇到这个难题。

问题的根源在与,无论是文件系统还是网络传输,小文件都需要很多额外操作,如
1、数据布局没有优化,寻址次数大大增加,寻道时间及旋转延迟大大增加,从而每秒的输入输出量 (IOPS,Input/Output Per Second) 、数据吞吐量(Throughput)都明显下降
其实很简单,大家考虑下,拷贝一个1G的文件,和拷贝一个都是零散文件的1G文件夹,其速度差距如何,就清楚了
2、网络通信开销增加,网络延迟变大
其实很简单,大家考虑下,网络传一个1G的文件,和传一个都是零散文件的1G文件夹,其速度差距如何,就清楚了
3、分布式存储,网络交互次数增加,数据存储位置频繁变化,网络通信增加,速度变慢
其实也不难,比如,从一个服务器上拉取10000个文件,与从10个服务器上拉取10000个文件(每次都要问下,下一个文件存储在那个服务器上),谁快谁慢,就清楚了

大家应对这个问题时,采用的方法无非是4种:
1、砸硬件,用硬件性能提升,让传输效率提供
2、用缓存,通过缓存,减少磁盘访问次数,减少交互环节,提高传输效率
3、改变存储策略
4、减少询问次数,比如一次通信,找到1000个文件的地址,400个在服务器A,600个在服务器B,不按文件顺序,而是先从A取400个,再从B取600个,通信就会减少很多,速度就会有所提升(但业务场景要合适才行)

这里主要说一下第3点。
传输一个都是零散文件的1G文件夹时,我们可以这样做,先压缩一下,然后再传递,再解压,发现很多时候居然会节约时间。
也就是说:
压缩+传输压缩文件+解压用的时间 < 直接读取并传送零散文件的时间

但如果直接存储压缩文件,那压缩我们只需要上传时做一次,平时读取时,其实为:
传输+解压用的时间 < 压缩+传输传输压缩文件+解压用的时间 < 直接传送零散文件的时间

那如果压缩和解压的时候,我们只做归档,不做压缩岂不是更节约时间?
传输+归档读取用的时间 < 传输+解压用的时间 < 直接传送零散文件的时间

恩,对了,其实大家的解决方案就是,将大量小文件,写到一个大文件里,这样读取效率就飞一样上来了。
无论是Facebook的Haystack还是淘宝的TFS,用的都是类似的方案。(实际上要复杂的多,请参考论文”Finding a needle in Haystack:Facebook’s photo storage”)

那HDFS呢?当然也支持咯,但要写代码处理一下,大家可以自行找一下Hadoop Archive, Sequence file, CombineFileInputFormat等。

Leave a Reply

Your email address will not be published.

*