接下来谈谈 QingStor®️对象存储对海量小文件场景的优化。
为什么需要对海量小文件进行优化呢？
海量小文件是很多存储产品中都是比较难以应对的问题，其难点主要体现在几个方面：
第一，小文件非常多的时候，会导致很多随机读写，相比于顺序读写，随机读写的性能会差很多。
第二，小文件在底层资源利用率比较低。如何理解？小文件最终存储时落到磁盘上，大多数时候底层都是采用文件系统存储，每一个小文件都会对应一个文件，文件系统会单独使用一个结构，也就是 inode，来记录每一个小文件的元信息，包括执行权限、用户组等信息，但是这些信息对用户来说往往是无意义的。
这导致在海量的场景下，可能出现一个情况：文件本身的数据不是那么多，但是不必要的元数据却非常多，占用大量存储空间，就会造成底层资源利用率较低。
针对这个问题，QingStor®️对象存储做了一些优化，主要分为两方面：
在提升存储利用率方面，QingStor®️对象存储把很多小文件合并成一个大文件。
如上图所示，这里有一个合并文件，里面包括很多小文件，包括x、a、b、c，它们都是单个 Object 小文件，都会写到同一个文件中。通过这种方式减少额外的元数据存储，提升资源利用率。
在使用这种方式时，如果需要删除前面的小文件，QingStor®️对象存储只做一个标记，后台会有进程，实时、定期对合并文件进行压缩，将删除的资源进行释放。
在提升写入性能方面，QingStor®️对象存储在写入一个小文件时，只把它向合并文件的尾部进行追加写入，不会在打开文件后对指定的 Offset 进行写入，也就是不做随机写，保证写入全是顺序写，大大提升写入性能。
此外，如果有并发的写入请求，比如 a、b、c三个都是小文件，有一个写入请求到了 Gateway，Gateway 会把这三个请求打包成一个，本来需要写三次，这里直接合并成一次。
把三次 IO 减到一次 IO，能做这样的合并是因为底层是采用合并方式的存储，并发 IO 的合并进一步提升 QingStor®️对象存储的写入性能。
在读取时，QingStor®️对象存储通过合并文件的 Path 加上小文件中的 Offset，找到这个文件的数据进行读取。
举个例子，现在同时要读 x 和 a、b、c，在读完 x，打开文件句柄是可以重复利用的，不需要每一次读都打开文件，这种方式使得 QingStor®️对象存储的小文件读取性能得到提升。
QingStor®️对象存储重点功能介绍QingStor®️对象存储支持两种部署方式：一种是标准部署，集群由网关节点和存储节点组成。
接入与索引与事件子系统会部署在网关节点上，存储节点只部署存储服务，把计算和存储分离，支持最小是六个节点规模的部署，这种方式比较适合数据量比较大，请求量也比较大的场景，网关节点与存储节点都可以进行独立扩容。
第二种是融合部署，集群由全能节点组成，把所有服务部署在全能节点上，这种方式是适合规模比较小，数据量比较小，访问量也不大的场景，如果数据量增长，可以非常方便以单个节点的方式进行存储与索引服务的扩容。
首先是生命周期管理功能，生命周期可以对存储的数据预设一些逻辑，过一段时间后自动对数据进行处理。
生命周期有一些典型的应用场景，例如对过期日志的处理，很多时候存储的日志是为了满足政策的要求，过几个月后就可以删除了。
生命周期管理可以设置自动规则，到期后自动删除过期的日志数据。此外，生命周期管理功能还能进行冷热数据分离，举个例子，业务只需要对近两个月的数据进行分析，更久远的数据就不需要。
但是为了合规需要，更久远的数据也需要保存，不能丢失，这时候生命周期管理功能可以做冷热数据的区分，自动设置数据经过一段时间后转移到更低成本的低频存储中。
QingStor®️对象存储的生命周期功能是以存储桶为单位来进行，其核心是事件子系统进行消息的处理和分发。