开发中对于大量小文件的存储应该怎么处理？
开发中对于大量小文件的存储应该怎么处理？参考Google的GFS以及变种HDFS、淘宝TFS以及腾讯TencentFS的设计。这些都是处理大量小文件的典范。
大家知道传统的文件系统下，每个文件都要被创建对应的inode之类元数据，但是在海量文件场景下，传统FS已经无法承载如此多的元数据IO量以及如此庞大的元数据搜索计算量了，唯一的做法就是降低元数据量，那么势必就要降低文件实体的数量，所以这些文件系统无一例外的都是用了这样一种变通的方法，即在文件中再创建文件，比如一个64MB的大文件，比如其中可以包含16384个4KB的小文件，但是这个64MB的大文件只占用了1个inode，而如果存放4KB的文件的话，就需要16384个inode了。
那么如何寻址这个大文件中的小文件呢？方法就是利用一个旁路数据库来记录每个小文件在这个大文件中的起始位置和长度等信息，也就是说将传统文件系统的大部分元数据剥离了开来，拿到了单独的数据库中存放，这样通过查询外部数据库先找到小文件具体对应在哪个大文件中的从哪开始的多长，然后直接发起对这个大文件的对应地址段的读写操作即可。另外还可以创建索引以加速文件查找动作。
在一个海量分布式文件系统中，元数据就像上面的思想一样是分级的，中控节点，也就是MDS，存储一级元数据，也就是大文件与底层块的对应关系，而数据节点则存放二级元数据，也就是最终的用户文件在这些一级大块中的存储位置对应关系，经过两级寻址从而读写数据。其实这些一级大文件，就可以认为它们是卷了，也就是在卷管理层之上再存放文件，这样就降低了单一空间下的文件总数量从而提高性能。
相关文章
图文推荐
- 文章
- 推荐
- 热门新闻