生不逢時的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,利用這個開源專案為自己的資料庫產品開發一個底層儲存元件，用在自己的資料庫一體機上。