生不逢時的openZFS能用在數據庫上嗎
?在Linux上有很多耳熟能詳的文件系統,EXT4,XFS,哪怕BTRFS也比openZFS出名,不過很多40出頭的IT人還是對ZFS有些印象的。很多人都覺得openZFS有點生不逢時,正當ZFS準備和LINUX緊密聯姻的時候,SUN被Oracle收購了,于是這也注定了ZFS的前路坎坷。在國外的很多IT社區里,都給ZFS打上了“originally Sun , but “got Oracled””這樣的標簽。在IT領域“got Oracled”不是個好詞,很多好技術都被Oracle收購了,并且消滅了。
ZFS是和普通的文件系統完全不同的,它是一種帶有嚴格一致性的文件系統,是一種日志結構的文件系統。類似于數據庫,ZFS依靠類似WAL的機制來保證文件系統的一致性。因此ZFS可以隨時保持十分強的一致性,有過服務器掉電后文件系統掛掉或者變成只讀狀態的朋友可能現在還會心有余悸,在ZFS上是永遠不需要fsck的,因為WAL可以幫助我們自動糾正這些不一致問題。
ZFS采用COW(COPY ON WRITE)的方式修改數據,這一點與SSD的行為類似,這種方式是個雙刃劍,可以獲得較好的讀寫平衡,但是會帶來寫放大的問題,數據的修改操作會有較高的成本。
ZFS的RAID-Z技術被稱為窮人的福音,使用RAID-Z技術,可以把多塊硬盤組成一個軟RAID系統從而確保數據的安全性。同時ZFS支持數據壓縮,可以讓數據的存儲成本進一步降低。
ZFS支持十分強大的快照技術,通過快照閃回或者克隆數據都十分方便。這給數據保護,數據備份、數據復制等都提供了十分強大的保障。
如此復雜的文件系統,其附加開銷肯定十分大,為了確保ZFS的性能,采用了內存中修改,并以強一致性事務的方式存盤的模式。如果你的硬件環境較好,配置有較多的物理內存,那么在內存中完成寫操作,并且將日志寫在性能極佳的NVME SSD盤上,將海量數據寫入大容量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的調優也沒那么復雜,如果你有我上面說的這樣的環境,較大的物理內存,SSD盤做日志寫入,那么下面的調整方案可能就足以 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,利用這個開源項目為自己的數據庫產品開發一個底層存儲組件,用在自己的數據庫一體機上。