FastCFS刚发布了版本2.2.0,IOPS全面超越Ceph:顺序写是Ceph的6.x倍,顺序读是Ceph的2.x倍,随机写大约是Ceph的2倍。具体的性能测试数据参见:https://gitee.com/fastdfs100/FastCFS/blob/master/docs/benchmark.md。相信有很多朋友会好奇FastCFS是如何做到的,接下来将为你揭晓FastCFS IOPS完胜Ceph的秘诀。
我不打算探讨架构和实现细节上的差异,直接为大家揭晓有效提升IOPS的关键做法。
FastCFS基于trunk文件(默认大小为256MB)存储数据,在一个trunk文件内采用顺序写方式。顺序写可以做到数据批量落盘,能够有效解决写放大问题,决定了FastCFS的写入性能相比传统的落盘方式有着明显优势,这就解释了FastCFS的随机写大约是Ceph的2倍。
为啥FastCFS顺序写可以秒杀Ceph呢,除了FastCFS服务端特有的顺序写机制外,还有一个关键因素是FastCFS客户端默认开启合并写特性。分布式存储系统核心性能指标是IOPS,受制于另外两个IO能力:磁盘IO和网络IO。合并写可以大大提升网络IO效率,有效消除网络IO瓶颈。
接下来说一下读性能。在v2.2.0之前,FastCFS采用传统的同步模型,随机读性能比Ceph略差。v2.2.0采用基于Linux libaio的异步模型,随机读性能有所提升,性能比Ceph略强。使用libaio异步模型的两大优势:1. CPU占用较低,一个异步读线程处理能力约等于8~16个同步读线程;2. 随机读IOPS更好。其代价是实现门框较高,需要使用Direct IO,read buffer、文件偏移量和读取字节数都需要按设备块大小对齐ÿ