生不逢时的openZFS能用在数据库上吗

生不逢时的openZFS能用在数据库上吗

​在Linux上有很多耳熟能详的文件系统，EXT4,XFS，哪怕BTRFS也比openZFS出名，不过很多40出头的IT人还是对ZFS有些印象的。很多人都觉得openZFS有点生不逢时，正当ZFS准备和LINUX紧密联姻的时候，SUN被***收购了，于是这也注定了ZFS的前路坎坷。在国外的很多IT社区里，都给ZFS打上了“originally Sun , but “got ***d””这样的标签。在IT领域“got ***d”不是个好词，很多好技术都被***收购了，并且消灭了。

ZFS是和普通的文件系统完全不同的，它是一种带有严格一致性的文件系统，是一种日志结构的文件系统。类似于数据库，ZFS依靠类似WAL的机制来保证文件系统的一致性。因此ZFS可以随时保持十分强的一致性，有过服务器掉电后文件系统挂掉或者变成只读状态的朋友可能现在还会心有余悸，在ZFS上是永远不需要fsck的，因为WAL可以帮助我们自动纠正这些不一致问题。

ZFS采用COW(COPY ON WRITE）的方式修改数据，这一点与***的行为类似，这种方式是个双刃剑，可以获得较好的读写平衡，但是会带来写放大的问题，数据的修改操作会有较高的成本。

ZFS的RAID-Z技术被称为穷人的福音，使用RAID-Z技术，可以把多块硬盘组成一个软RAID系统从而确保数据的安全性。同时ZFS支持数据压缩，可以让数据的存储成本进一步降低。

ZFS支持十分强大的快照技术，通过快照闪回或者克隆数据都十分方便。这给数据保护，数据备份、数据复制等都提供了十分强大的保障。

如此复杂的文件系统，其附加开销肯定十分大，为了确保ZFS的性能，采用了内存中修改，并以強一致性事务的方式存盘的模式。如果你的硬件环境较好，配置有较多的物理内存，那么在内存中完成写操作，并且将日志写在性能极佳的NVME ***盘上，将海量数据写入大容量HDD中，那么当你的写IO不会大到击穿内存缓冲的时候，ZFS文件系统是能够表现出十分优秀的写入性能的。

对于ZFS的性能问题，网络上有很多不同的关键，也有不同的测试结果。用比较中肯的观点来说，任何的好处都是有代价的，ZFS在确保数据安全的前提下，肯定会在性能上有所欠缺。一些认为ZFS性能很差的朋友可能并没有做好调优，一些认为ZFS性能十分优秀的朋友可能其测试场景过于单一和简单。一般来说，与EXT4/XFS等传统文件系统相比，ZFS在大量持久性写入场景的性能肯定要差不少，对于读写较为均衡的OLTP系统来说，ZFS的性能与EXT4十分接近并略低一些。在某些OLTP数据库场景中，因为ZFS的内存中写与读缓冲机制，也可能会表现出比EXT4/XFS更好的性能。

比如当我们在ZFS上跑PG或者MySQL的时候，因为文件系统是可以确保不会出现块断裂问题的，因此我们就可以关闭FULL PAGE WRITE，从而获得更好的并发性能。这实际上就是我昨天讨论过的，把数据库的工作交给OS来做的一个例子。

实际上，ZFS的调优也没那么复杂，如果你有我上面说的这样的环境，较大的物理内存，***盘做日志写入，那么下面的调整方案可能就足以 ZFS表现出不错的性能了。虽然ZFS文件系统上做针对性的调优比较复杂，因为针对不同的数据保护模式，不同的缓冲策略和压缩策略，会有十分复杂的配置。不过一般情况下，调整并不复杂：

lrecordsize=8kB；llogbias=throughput [latency] ：根据你的应用场景需求可以选择吞吐量和延时，针对高并发要求的OLTP应用，可以选择LATENCY，对于具有大量数据扫描的分析类应用，可以选择throughput；lzfs_arc_max ：一定要设置该参数，避免arc cache占用过多的内存，导致操作系统换页。

有兴趣的朋友可以找时间试试ZFS的性能是否能够满足你的应用需求。我觉得不追求极致性能的情况下，ZFS的強一致性保障与数据压缩能力已经能够让我们得数据库系统受益良多了。

目前openZFS社区是十分活跃的，今年年初推出的2.1.7版本支持3.10-6.0的LINUX核心，与一直不够成熟的BTRFS相比，我还是更推荐openZFS。实际上我们的国产数据库厂商也可以试着考虑一下openZFS,利用这个开源项目为自己的数据库产品开发一个底层存储组件，用在自己的数据库一体机上。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。