半溪
海量小文件是业界难题，甚至有专门的名词，LOSF(lots of samll file)。通常我们认为大小在1MB以内的文件称为小文件，百万级数量及以上称为海量文件，由此量化定义海量小文件。
在互联网(尤其是移动互联网)、物联网、云计算、大数据等高速发展的大背景下，数据呈现爆炸式地增长。海量小文件的应用在生活中已越来越常见，社会化网络、移动通信、网络视频音频、电子商务、传感器网络、科学实验等各种应用产生的数据，不仅存储容量巨大，而且数据类型繁多、数据大小变化幅度大、流动快等显著特点，往往能够产生千万级、亿级甚至十亿、百亿级的海量小文件。如何构建高效存储访问和备份恢复的小文件管理是目前海量数据存储所面临的一个重要问题。
对于LOSF而言，IOPS/OPS是关键性能衡量指标，造成性能和存储效率低下的主要原因包括海量文件的元数据管理、存储介质性能限制等方面。
元数据来说，虽然小文件得数据量小，但是每个数据的元数据量不变。导致文件系统的元数据量非常庞大，因此元数据对于小文件得访问效率影响非常大。磁盘文件系统使用块来组织磁盘数据，并在inode中存储索引文件数据块。数据块通常比较小，一般为1KB、2KB或4KB。当文件需要存储数据时，文件系统根据预定的策略分配数据块，分配策略会综合考虑数据局部性、存储空间利用效率等因素，通常会优先考虑大文件I/O带宽。对于特别小的小文件，比如小于4KB，inode与数据分开存储，这种数据布局也没有充分利用空间局部性，导致随机I/O访问。
随着目前存储技术的发展，可以从存储介质（硬盘 or SSD）、存储方式（对象 or 文件系统）两个主要角度出发做针对小文件场景的方案选择：
1、存储介质方案选择：从机械硬盘到SSD
SSD无疑是从存储介质层面提升海量小文件存储性能的利器。单盘几万的IOPS，甚至采用nvme协议后能达到单盘几十万的IOPS，高IOPS能非常好的提升海量小文件检索效率。奈何SSD价格还是高高在上，无法大规模普及。但随着NAND flash的发展，SSD取代机械硬盘是肯定的事。
但是光从存储介质层面入手还不能完全解决问题。由于目前的文件系统往往是针对大文件设计的，比如ext3，btrfs，ntfs等文件系统在大文件时表现往往可以，但是海量小文件场景时性能也会出现下降。这种情况其实是文件系统跟不上硬件的性能，只有针对海量小文件做了特殊优化的文件系统配合高性能的SSD才能够更好的解决该问题。
2、数据存储方式方案选择
（1）对象存储
对象存储是近几年新发展出来的全新存储使用协议。对象存储最明显的特点就是，一般无用户使用界面，不像常见的posix协议的文件系统可以直接操作文件。用户存储文件和获取文件采用url的方式。可以比如，存储一个数据的时候用put，获取用get。对象存储不像文件系统一样可以无缝兼容各种业务程序，而是需要业务程序调整自己的读写接口为对象标准，从而给实际落地应用带来了一定的门槛。
对象存储目前有多种开源版本：swift，ceph，minio等。
对象存储，也叫做基于对象的存储，是用来描述解决和处理离散单元的方法的通用术语，这些离散单元被称作为对象。就像文件一样，对象包含数据，但是和文件不同的是，对象在一个层结构中不会再有层级结构。每个对象都在一个被称作存储池的扁平地址空间的同一级别里，一个对象不会属于另一个对象的下一级。
比如Ceph通过Crush算法做数据分布。不使用文件系统时，系统无需配置元数据服务（MDS），这时系统无需管理庞大的元数据，避免了元数据服务成为瓶颈；
但是由于机械硬盘的本身限制，往往在使用的时候，都会配置SSD盘作为缓存盘提供系统整体IOPS。同时业务系统也得由于使用对象存储系统而修改IO读写的访问接口，这对于很多用户来说是很难以接受的方案。
（2）分布式文件系统
文件系统作为平常最常见的存储方式，还是受广大的用户喜欢。但是传统NAS具有机头瓶颈，海量小IO的并发下性能会很差。分布式存储发展起来后，通过横向扩展，方便的解决传统存储带来的瓶颈问题。
一般来说文件系统一定需要元数据，每次数据的读写都会涉及到元数据的访问或者修改。所以元数据服务器的还是会成为分布式文件系统处理海量小文件时的瓶颈。
目前一般厂家的产品会采用多种方式来解决分布式文件系统面临海量小文件的场景：
1) 元数据节点集群技术：通过将文件系统的元数据进行分布式存储，让多台元数据节点同时提供元数据存储和检索服务，能够大幅度提升元数据的并发检索效率。
2) 小文件聚合技术：此技术是目前场景下使用比较好的一种方法。比如淘宝的TFS和Facebook的hashstack，都采用了类似的技术，提供海量图片的访问。通过将多个小文件聚合成一个大文件进行存储实现高效的文件存储。聚合的方式大大减少了系统的元数据操作，而且将小文件的读写方式从随机变为了顺序更好的发挥磁盘的性能。这种方式非常适合一次写入后数据读写少量的场景，因为数据聚合后的读需要先定位大文件，然后从大文件中定位小文件。写入的时候便没有这种消耗。
3) 缓存技术：Cache技术其实广泛的应用各种场景。类似hashstack进行了多级的缓存，在分布式存储中，将元数据尽可能的缓存在内存中能大大提高元数据的访问效率。但是当数据读写频繁时，缓存的命中比较考量算法。
3、总结
随着数字世界的不断庞大，海量小文件场景越来越常见。我们也看到业界很多产品通过各种方式的优化，支持百亿级别的数据访问。但是LOSF问题是公认的难题，需要针对不同的业务场景进行专门的优化，一个产品没法吃遍天下。也希望大家有更多的想法可以一起分享，欢迎评论留言。
神行科技
关键看怎么使用这些文件。
像网站那样上传后不要求使用原文件名，由后台自动重新命名，读取时都是明确指定文件链接，没有遍历操作，一次读取整个文件的场景的。可以使用那种对文件名进行hash运算，按算法结果决定存储位置的文件系统。读取时对文件名进行hash就能确定该从哪里读取。避免了普通文件系统搜索文件分配表这样低效率的操作。使用对象存储也是一个不错的办法，相当于存储到一个数据库中。可以利用数据库的内存缓存和索引优化提高读取速度。
如果想用传统posix规范文件系统那样随机读取文件数据，需要保留原文件名，需要目录和遍历功能的情况。可以使用带元数据服务的文件系统。这个元数据服务相当于数据库形式的文件分配表，存储了各文件的存储位置。读取文件时就先向元数据服务器查询出该从哪里取出文件，再从相应位置取出文件。
nohead
1、Raid02、固态硬盘3、Fat32：拷贝大量小文件(如拷贝照片、文档转移等)速度很快，但不支持存储单个大于4GB的文件。NTFS：支持大文件存储，管理性能比Fat32强很多，但是拷贝大量小文件时速度较慢。
