我們通過一個具體場景來描述 Open-Channel SSD 的價值。RocksDB 作為一個單機存儲引擎，被廣泛應用在很多分布式存儲的場景中。RocksDB 的數(shù)據(jù)存儲采用 LSM-Tree + WAL 的方式，其中，LSM-Tree 用于存儲數(shù)據(jù)和索引，WAL 用于保證數(shù)據(jù)寫入的完整性（Data Integrity）。由于目前在 RocksDB 的實現(xiàn)中，LSM-Tree 中的 SSTable 和 WAL 都是文件系統(tǒng)上的一個文件，所以數(shù)據(jù)寫入 WAL 的過程中，也會觸發(fā)文件系統(tǒng)的數(shù)據(jù)保護機制，例如 Journaling。而文件系統(tǒng)在將數(shù)據(jù)寫入 Journal 時，也會觸發(fā) SSD FTL 層的數(shù)據(jù)保護機制。所以，一次 RocksDB 的寫請求會經過三個 IO 子系統(tǒng)：RocksDB，F(xiàn)ile System，F(xiàn)TL。每一層子系統(tǒng)為了保證數(shù)據(jù)完整性，都會產生寫放大（Write Amplification），使得一次寫入被放大幾十甚至上百倍。這個現(xiàn)象可以被形象的描述為『Log-On-Log』的現(xiàn)象。
而實際上，對于 RocksDB 的 WAL，以及文件系統(tǒng)的 Journal，實際上都是臨時性的寫入，并不需要底層系統(tǒng)額外的數(shù)據(jù)保護機制。Open-Channel SSD 的出現(xiàn)提供了打破這個現(xiàn)象的機會，如果在 RocksDB 可以繞過文件系統(tǒng)層以及 FTL，則可以將三層 Log 合并為一層，避免寫入放大，最大化發(fā)揮 SSD 的性能。
除了避免寫放大之外，在 LSM-Tree 數(shù)據(jù)結中，由于 SSTable 是只讀不可修改的，而 SSD 的 Block 也是只讀的（如果要寫入必須先擦寫），那么 RocksDB 可以利用 SSD 的這個特點，讓 SSTable 與 Block 對齊，將 LSM-Tree 中的刪除 SSTable 操作與 SSD 的 Block 回收操作合并，避免 SSD Block 回收時產生的數(shù)據(jù)拷貝操作，避免 GC 對性能產生影響。在?『An Efficient Design and Implementation of LSM-Tree based Key-Value Store on Open-Channel SSD』中，就實現(xiàn)了將 LevelDB 直接運行在 Open-Channel SSD 上。
除了避免寫放大，Open-Channel SSD 還提供了實現(xiàn) IO Isolation 的可能性。由于 SSD 的物理特性，SSD 的性能和數(shù)據(jù)的物理布局緊密相關。SSD 的性能來自于每一個 NAND 芯片的性能的總和。每一個 NAND 芯片提供的 IO 性能很低，但由于 NAND 芯片之間可以進行并行化，這使得 SSD 的整體性能非常高。換句話說，數(shù)據(jù)的布局決定了 IO 性能。然而由于傳統(tǒng)的 SSD 上運行了 FTL，F(xiàn)TL 不僅會對數(shù)據(jù)的布局進行重映射，同時在后臺還會運行 GC 任務，這使得 SSD 的性能是無法預測的，也無法進行隔離。Open-Channel SSD 將底層信息暴露給上層應用，通過將數(shù)據(jù)放置在不同的 NAND 芯片上，可以在物理層面達到數(shù)據(jù)分布隔離，同時也就打到了性能的隔離的效果。
為了方便的管理和操作 Open-Channel SSD，LightNVM?應運而生。LightNVM 是在 Linux Kernel 中一個針對 Open-Channel SSD 的 Subsystem。LightNVM 提供了一套新的接口，用于管理 Open-Channel SSD，以及執(zhí)行 IO 操作。為了和 Kernel 中現(xiàn)有的 IO 子系統(tǒng)協(xié)同工作，還存在 pblk（Physical Block Device）層。他在 LightNVM 的基礎上實現(xiàn)了 FTL 的功能，同時對上層暴露傳統(tǒng)的 Block 層接口，使得現(xiàn)有的文件系統(tǒng)可以通過 pblk 直接運行在 Open-Channel SSD 上。2017 年 FAST 上的一篇 paper：『LightNVM: The Linux Open-Channel SSD Subsystem』專門介紹了 LightNVM。
目前 LightNVM 已經被合并入 Kernel 的主線。而對于用戶態(tài)的程序來說，可以通過 liblightnvm 操作 Open-Channel SSD。
2018 年 1 月，Open-Channel SSD 發(fā)布了?2.0?版本的標準。但無論是 Open-Channel SSD，還是 LightNVM 都還處于非常早期的階段，目前在市面上很難見到 Open-Channel SSD，不適合直接投入到生產中。盡管如此，Open-Channel SSD 和 Host based FTL 帶來的好處是非常巨大的。對于追求極致存儲性能的場景，在未來很可能會采用 Open-Channel SSD + LightNVM 的實現(xiàn)方式。
NVM，或者 PM（persistent memory），SCM（storage class memory），實際上都是一個意思，指的都是非易失性內存。NVM 在學術界火了很多年了， 相關的研究在不斷向前推進。
一直以來，由于 2：8 定律的特性，計算機系統(tǒng)的存儲一直是采用分層的結構，從上到下依次是 CPU Cache，DRAM，SSD，HDD。 其中，CPU Cache 和 DRAM 是易失性的（volatile），SSD 和 HDD 是非易失性的（non-volatile）。盡管 SSD 的速度遠高于 HDD，但和 DDR 相比，還是有一定的差距。SSD 提供 10us 級別的響應時間，而 DRAM 只有 ns 級別，這中間有一萬倍的差距。由于 DRAM 和 SSD 之間巨大的性能差距，使得應用程序需要非常仔細的設計 IO 相關的操作，避免 IO 成為系統(tǒng)的性能瓶頸。
而 NVM 的出現(xiàn)彌補了這個差距。NVM 在保持非易失性的前提下，將響應時間降低到 10ns 級別，同時單位容量價格低于 DRAM。此外，NVM 是按字節(jié)訪問（byte-addressable），而不像磁盤按照塊（Block）訪問。NVM 的出現(xiàn)打破了傳統(tǒng)的存儲層次，將對軟件架構設計產生巨大的影響。
NVM 看上去很美好，但目前并不能像內存或磁盤一樣，做到即插即用。在傳統(tǒng)的操作系統(tǒng)中，Virtual Memory Manager（VMM）負責管理易失性內存，文件系統(tǒng)負責管理存儲。而 NVM 既像內存一樣可以通過字節(jié)訪問，又像磁盤一樣具有非易失性的特點。使用 NVM 的方式主要有兩種：
面向 NVM 進行編程和面向傳統(tǒng)的內存或磁盤編程是非常不同，這里我們舉一個非常簡單的例子。例如，有一個函數(shù)用于執(zhí)行雙鏈表插入操作：
void list_add_tail(struct cds_list_head *newp, struct cds_list_head *head) {
head->prev->next = newp;
newp->next = head;
newp->prev = head->prev;
head->prev = newp;
}
然而對于 NVM 來說，由于是非易失性的，假設在執(zhí)行到函數(shù)的第一行后發(fā)生了斷電，當系統(tǒng)恢復后，鏈表處于一個異常且無法恢復的狀態(tài)。同時，由于 CPU 和 NVM 之間還有 CPU Cache 作為緩存，以及 CPU 執(zhí)行具有亂序執(zhí)行的特性，所以 NVM 需要使用特殊的編程模型，也就是 NVM Programming Model。通過顯示的指定 Transaction，達到原子性操作的語義，保證當系統(tǒng)恢復時，不會產生中間狀態(tài)。
在分布式場景下，如果要充分發(fā)揮 NVM 的性能，就必須和 RDMA 結合。由于 NVM 的超高的性能，Byte Addressable 的訪問特性，以及 RDMA 的訪問方式，使得分布式的 NVM + RDMA 需要全新的架構設計，包括單機數(shù)據(jù)結構，分布式數(shù)據(jù)結構，分布式一致性算法等等。在這方面，清華計算機系高性能所去年發(fā)表的?Octopus?提供了一個思路，通過 NVM + RDMA 實現(xiàn)了分布式文件系統(tǒng)，同時在自己實現(xiàn)一套基于 RDMA 的 RPC 用于進行節(jié)點間的通信。
然而尷尬的是，盡管學術界在 NVM 上已經研究了數(shù)十年，但在工業(yè)界目前還沒有可以大規(guī)模商用的 NVM 產品，大家還只能基于模擬器進行研究。Intel 和 Micro 在 2012 年合作一起研發(fā) 3D XPoint 技術，被認為是最接近能商用的 NVM 產品。Intel 在 2017 年發(fā)布了基于 3D XPoint 技術的磁盤產品 Optane，而 NVM 產品（代號 Apache Pass）還沒有明確的發(fā)布時間。
然而即使 NVM 產品面世，由于 NVM 的價格和容量的限制，以及復雜的編程模式，在實際生產中很少會出現(xiàn)純 NVM 的場景，更多的還是 tiering 的形式，也就是 NVM + SSD + HDD 的組合。在這個方面，2017 SOSP 上的一篇論文?Strata?也提供了一個不錯的思路。
去年 Jeff Dean 所在的 Google Brain 團隊發(fā)表了一篇非常重要的論文『The Case for Learned Index Structures』?？梢哉f從這篇文章開始，系統(tǒng)領域展開了一個新的方向，Machine Learning 與系統(tǒng)相結合。不得不贊嘆 Jeff Dean 對計算機科學的影響力。
這篇文章，以及 Jeff Dean 在 NIPS17 ML Systems Workshop 上的?talk，都釋放出了一個很強的信號，計算機系統(tǒng)中包含了大量的 Heuristics 算法，用于做各種各樣的決策，例如 TCP 窗口應該設置為多大，是否應該對數(shù)據(jù)進行緩存，應該調度哪一個任務等等。而每一種算法都存在性能，資源消耗，錯誤率，以及其他方面的 Tradeoff，需要大量的人工成本進行選擇和調優(yōu)。而這些正是Machine Learning 可以發(fā)揮的地方。
在?『The Case for Learned Index Structures』?文章中，作者提到了一個典型的場景，數(shù)據(jù)庫的索引。傳統(tǒng)的索引通常采用 B 樹，或 B 樹的變種。然而這些數(shù)據(jù)結構通常是為了一個通用的場景，以及最差的數(shù)據(jù)分布而進行設計的，并沒有考慮到實際應用中數(shù)據(jù)分布情況。對于很多特殊的數(shù)據(jù)分布場景，B 樹并不能夠達到最優(yōu)的時間和空間復雜度。為了達到最佳效果，需要投入大量的人力進行數(shù)據(jù)結構的優(yōu)化。同時，由于數(shù)據(jù)的分布在不斷的變化，調優(yōu)的工作也是持續(xù)不斷的。作者提出的的 Learned Index，則是通過與 Machine Learning 技術結合，避免人工調優(yōu)的開銷。
在這篇文章中，作者把索引數(shù)據(jù)結構當做一個 Model，這個 Model 的輸入是一個 Key，輸出是這個 Key 對應的 Value 在磁盤中的位置。而 B 樹或其他的數(shù)據(jù)結構只是實現(xiàn)這個 Model 的一種方式，而這個 Model 也可以存在其他的實現(xiàn)形式，例如神經網絡。
和 B 樹相比，神經網絡具有很大的優(yōu)勢：
通過進行離線的模型訓練，犧牲一定的計算資源，可以達到節(jié)省內存資源，以及提高性能的效果。
當然，這種方法也存在一定的局限性。其中最重要的一點，就是 Learned Index 只能索引固定數(shù)據(jù)分布的數(shù)據(jù)。當有數(shù)據(jù)插入時導致數(shù)據(jù)分布發(fā)生了變更，原有的模型就會失效。解決的方案是對于新增的數(shù)據(jù)，依然采用傳統(tǒng)的數(shù)據(jù)結構進行索引，Learned Index 只負責索引原有數(shù)據(jù)。當新增數(shù)據(jù)積累到一定程度時，將新數(shù)據(jù)與原有數(shù)據(jù)進行合并，并根據(jù)新的數(shù)據(jù)分布訓練出新的模型。這種方法是很可行的，畢竟和新增數(shù)據(jù)量相比，全量數(shù)據(jù)是非常大的。如果能對全量數(shù)據(jù)的索引進行優(yōu)化，那應用價值也是巨大的。
盡管存在一定的局限性，Learned Index 還是有很多適用的場景，例如 Google 已經將其應用在了 BigTable 中。相信 Learned Index 只是一個開端，未來會有越來越多的 System 和 Machine Learning 結合的工作出現(xiàn)。
LSM-Tree 是 LevelDB，以及 LevelDB 的變種，RocksDB，HyperDB 等單機存儲引擎的核心數(shù)據(jù)結構。
LSM-Tree 本身的原理我們不過多介紹。目前 LSM-Tree 最大的痛點是讀寫放大，這使得性能往往只能提供裸硬件的不到 10%。所以關于解決 LSM-Tree 讀寫放大問題成為近些年研究的熱點。
在 2016 年 FAST 會議上發(fā)表的論文?WiscKey?提出了將 Key 與 Value 分開存放的方法。傳統(tǒng) LSM-Tree 將 Key 和 Value 相鄰存放，保證 Key 和 Value 在磁盤上都是有序的。這提高了 Range Query 的效率。然而，當進行 Compaction 時，由于需要同時操作 Key 和 Value，所以造成了較大讀寫比例放大。而在 WiscKey 中，通過將 Key 和 Value 分開存放，Key 保持 LSM-Tree 結構，保證 Key 在磁盤上的有序性，而 Value 使用所謂 『Value Log』 結構，很像 Log-Structured File System 中的一個 Segment。通過在 Key 中保存 Value 在磁盤上的位置，使得可以通過 Key 讀取到 Value。由于 LSM-Tree 中只保存 Key，不保存 Value，且 Key 的大小通常遠小于 Value 的大小，所以 WiscKey 中的 LSM-Tree 的大小遠小于傳統(tǒng) LSM-Tree 的大小，因此 Compaction 引入的讀寫放大可以控制在非常小的比例。WiscKey 的缺點是犧牲了 Range Query 的性能。由于相鄰 Key 的 Value 在磁盤上并沒有存在相鄰的位置，WiscKey 中對連續(xù)的 Key 讀取被轉化成隨機磁盤讀取操作。而作者通過將預讀（Prefetching）IO 并行化的方式，盡可能降低對順序讀性能的影響。
而在 2017 年 SOSP 上發(fā)表的論文?PebblesDB?提出了另外一種思路。在傳統(tǒng) LSM-Tree 中，每一層由多個 SSTable 組成，每一個 SSTable 中保存了一組排好序 Key-Value，相同層的 SSTable 之間的 Key 沒有重疊。當進行 Compaction 時，上層的 SSTable 需要與下層的 SSTable 進行合并，也就是將上層的 SSTable 和下層的 SSTable 讀取到內存中，進行合并排序后，組成新的 SSTable，并寫回到磁盤中。由于 Compaction 的過程中需要讀取和寫入下層的 SSTable，所以造成了讀寫放大，影響應能。
PebblesDB 將 LSM-Tree 和 Skip-List 數(shù)據(jù)結構進行結合。在 LSM-Tree 中每一層引入 Guard 概念。 每一層中包含多個 Guard，Guard 和 Guard 之間的 Key 的范圍是有序的，且沒有重疊，但 Guard 內部包含多個 SSTable，這些 SSTable 的 Key 的范圍允許重疊。
當需要進行 Compaction 時，只需要將上層的 SSTable 讀入內存，并按照下層的 Guard 將 SSTable 切分成多個新的 SSTable，并存放到下層對應的 Guard 中。在這個過程中不需要讀取下層的 SSTable，也就在一定程度上避免了讀寫放大。作者將這種數(shù)據(jù)結構命名為 Fragemented Log-Structured Tree（FLSM）。PebblesDB 最多可以減低 6.7 倍的寫放大，寫入性能最多提升 105%。
和 WiscKey 類似，PebblesDB 也會多 Range Query 的性能造成影響。這是由于 Guard 內部的 SSTable 的 Key 存在重疊，所以在讀取連續(xù)的 Key 時，需要同時讀取 Guard 中所有的 SSTable，才能夠獲得正確的結果。
WiscKey 和 PebblesDB 都已經開源，但在目前最主流的單機存儲引擎 LevelDB 和 RocksDB 中，相關優(yōu)化還并沒有得到體現(xiàn)。我們也期待未來能有更多的關于 LSM-Tree 相關的優(yōu)化算法出現(xiàn)。
Crash Consistency 的意思是，存儲系統(tǒng)可以在故障發(fā)生后，保證系統(tǒng)數(shù)據(jù)的正確性以及數(shù)據(jù)，元數(shù)據(jù)的一致性?？梢哉f Crash Consistency 是存儲領域永恒不變的話題。
早些年大家熱衷于通過各種方法在已實現(xiàn)的文件系統(tǒng)中尋找 Bug，而這兩年構造一個新的 Bug Free 的文件系統(tǒng)成為熱門的方向。在這方面最早做出突破的是 MIT 的團隊的?FSCQ。FSCQ 通過 Coq 作為輔助的形式化驗證工具，在 Crash Hoare Logic 的基礎上，實現(xiàn)了一個被證明過 Crash Safty 的文件系統(tǒng)。
然而使用 Coq 的代價是需要人工手動完成證明過程，這使得完成一個文件系統(tǒng)的工作量被放大了幾倍，例如 FSCQ 的證明過程花費了 1.5 年。
而 Washington 大學提出的?Yggdrasil?則基于 Z3，將文件系統(tǒng)證明過程自動化，也就是最近非常流行的『Push-Button Verification』 的方法。
值得注意的是，無論是 FSCQ 還是 Yggdrasil 都存在著巨大的局限性，例如不支持多線程訪問，文件系統(tǒng)功能并不完備，性能較弱，以及代碼生成過程中依賴一些沒有被驗證過的工具等等。我們距離構建一個在通用場景下可以完全替代已有文件系統(tǒng)（如 ext4）還有很長的路要走。這也依賴于形式化驗證方面的技術突破。
隨著虛擬化技術的成熟和普及，存儲的接入端逐漸從 HBA 卡或傳統(tǒng)操作系統(tǒng)，轉變?yōu)?Hypervisor。在 Linux KVM 方面，隨著存儲性能逐漸提高，原有的 virtio 架構逐漸成為了性能瓶頸，vhost 逐漸開始普及。所謂 vhost 就是把原有 Qemu 對于 IO 設備模擬的代碼放到了 Kernel 中，包含了 vhost-blk，以及 vhost-net。由 Kernel 直接將 IO 請求發(fā)給設備。通過減少上下文的切換，避免額外的性能開銷。
在容器方面，隨著 K8S 的應用和成熟，在 K8S 的存儲方面也誕生了一些新的項目。比如?rook.io?是基于 K8S 的編排工具。而 K8S 本身也發(fā)布了?Container Storage Interface（CSI），用于第三方存儲廠商更好的開發(fā) K8S 的存儲插件。未來也會看到越來越多的存儲廠商對 K8S 進行支持。
2017 年 Linux Kernel 共發(fā)布了 5 個版本，從 4.10 到 4.14，目前最新的版本是 4.15。其中存儲相關比較值得注意的變化包括：AIO 改進，Block Layer 錯誤處理改進，基于 MQ 的調度器 Kyber?等等。然而比較悲傷的消息是，為了修復 Meltdown 和 Spectrue 漏洞，Kernel 引入了?Kernel Page Table Isolation（KPTI）技術，這導致系統(tǒng)調用和上下文切換的開銷變得更大。Brendan Gregg 在他的博客中詳細分析了 KPTI 對性能產生的影響。對于系統(tǒng)調用與上下文切換越頻繁的應用，對性能的影響越大。也就是說，IO 密集型的應用將受到比較大的影響，而計算密集型的應用則影響不大。
在企業(yè)級存儲方面，去年有很多存儲廠商都開始向純軟件廠商進行轉型，包括 Nutanix，Kaminario 以及 E8 等等。向軟件化轉型并不是處于技術的原因，而是商業(yè)的考慮?？紤]到 Dell 和 EMC 的合并，存儲硬件的利潤率必定會不斷下降。軟件化最大的好處，就是可以提升財務報表中的利潤率，使得公司的財務狀況更加健康，也避免了和 Dell EMC 的存儲硬件發(fā)生競爭。
在資本市場方面，2017 年可以說是波瀾不驚。上圖是 2017 年存儲行業(yè)發(fā)生的并購案。其中 Toshiba Memory 被收購的案件是存儲行業(yè)歷史上第三大收購案（第一名是 Dell 收購 EMC）。
以上是作者對當前存儲熱點和趨勢的不完整的總結。希望幫助讀者對存儲領域增加一點點了解，或者是對存儲技術產生一點點的興趣。也歡迎大家把自己感興趣的話題寫在評論里，我們將在后面盡可能的為大家進行介紹。
順便廣告一下，SmartX 是全球技術領先的分布式存儲廠商，如果想在存儲領域做出一番事業(yè)的話，歡迎加入 SmartX。
@張凱(Kyle Zhang)，SmartX 聯(lián)合創(chuàng)始人 & CTO。SmartX?擁有國內最頂尖的分布式存儲和超融合架構研發(fā)團隊，是國內超融合領域的技術領導者。
文章 來源：SmartX知乎專欄
