一種基于LSM樹的鍵值存儲系統性能優化方法

王海濤 李戰懷 張 曉 趙曉南

(西北工業大學計算機學院 西安 710129) (大數據存儲與管理工業和信息化部重點實驗室(西北工業大學) 西安 710129)

隨著Web 2.0和云計算的快速發展，現代社會已經步入大數據時代，數據體量和訪問量呈爆發式增長，傳統的關系型數據庫管理系統逐漸難以適應大量高并發的數據存儲和訪問需求[1-2].在此場景下，鍵值(key-value, KV)存儲架構應運而生.簡而言之，KV存儲將一組鍵(key)映射到關聯的值(value)，用戶通過GET,PUT以及DELETE等簡單的接口進行操作，相對于傳統的關系型數據庫管理系統具有更好的性能、可伸縮性和可用性[3-4]，成為了眾多大數據應用系統的關鍵組件，廣泛應用在各種數據密集型的服務系統中，例如Web索引、電子商務和云存儲等.

目前流行的KV存儲系統大都基于日志結構合并(log-structured merge, LSM)樹[5]而不是傳統的B樹索引結構，如BigTable[6],Cassandra[7],HBase[8],LevelDB[9]以及RocksDB[10]等.主要原因是在眾多的大數據系統中，KV存儲的寫入性能非常關鍵，而LSM樹對數據的寫入操作進行了優化.其基本思路是首先在內存中對寫請求進行緩存和合并，然后再批量寫入到存儲設備中，從而將隨機寫操作轉換為順序寫操作，提升用戶寫入性能.但是這種KV存儲在處理頻繁的小塊數據更新負載時，寫性能開銷依舊很大.

LSM樹的寫性能開銷主要由2部分構成：

1) 由數據壓縮(compaction)操作引入的開銷.數據壓縮是LSM樹必需的操作，其目的是保證KV數據的有序性以及進行垃圾回收，使得用戶在進行查詢操作的時候能夠迅速定位到所需的KV數據，提高用戶的讀性能.數據壓縮操作需要讀取多個key范圍有重合的數據文件，對數據進行合并排序后再寫入到新的文件中，然后刪除舊的數據文件.這個過程中涉及大量數據的重復寫入，造成了數據的寫放大，增加了性能開銷.

2) 由KV存儲系統的日志機制引入的性能開銷.首先，KV存儲通常利用預寫日志(write-ahead log, WAL)來保證KV數據的可靠性，以確保在系統崩潰時能夠恢復正常數據.因此，每次寫入操作的數據需要首先寫入WAL，然后才能寫入目標文件.其次，基于LSM樹的KV存儲系統一般使用通用的文件系統(如Ext4)來存儲數據，文件系統本身也通過自帶的日志機制來保證數據一致性，因此造成了多重日志的問題，進一步增加了性能開銷.此外，通用文件系統中復雜的功能和軟件棧也會增加性能開銷.本文中將這些性能開銷統稱為日志開銷.對于插入密集型的小塊KV負載，WAL文件的更新將非常頻繁，從而導致嚴重的日志開銷，造成KV存儲系統寫入性能的劇烈下降.

本文針對上述性能問題，提出了一個稱為RocksFS的優化文件系統，避免了通用文件系統中復雜的功能和軟件棧引入的額外負載，同時通過優化日志存儲結構以及更新流程來減小日志更新引入的元數據負載，從而提升KV存儲系統寫性能.最終在業界廣泛應用的KV存儲系統RocksDB上進行了驗證，結果表明相對于通用文件系統，RocksFS能夠有效提高KV存儲的寫入和更新性能，特別是對于插入密集型的小塊KV負載.

1 相關工作

基于LSM樹的KV存儲系統在大數據系統中應用廣泛，受到了工業界和學術界的持續關注.針對這類KV存儲系統的寫性能問題，國內外的研究人員從不同的角度提出了一些優化方案.

WiscKey[11]基于LevelDB實現了一種新的存儲機制，其核心思路是將key和value解耦并分開存儲，只對key進行排序，而value則追加到獨立的日志中.該機制可避免數據排序時value的移動，減小數據壓縮過程中的讀寫放大.但是由于沒有對value進行排序，因此KV數據范圍檢索的性能降低，且需要有垃圾回收操作來處理日志中的舊數據，引入了額外的負載.

PebblesDB[12]實現了一種基于片段的日志結構合并(fragmented log-structured merge, FLSM)樹，只維持片段之間的有序性，而片段內部的不同文件之間無序，避免了KV數據壓縮過程中引入的同一層數據的重寫操作，從而減小了壓縮操作引入的數據寫放大.但是由于無法保證每一層數據完全有序，讀性能以及范圍檢索性能有所降低.

SkipStore[13]在LSM樹結構基礎上實現了一個針對壓縮操作優化的KV存儲系統，在KV數據壓縮的過程中跳過一些中間層，將相關的數據直接壓縮到不相鄰的組件中，從而加速數據壓縮流程，減少壓縮操作造成的寫放大，提高KV存儲系統寫入性能.但是由于增加了讀流程的復雜性，讀取性能有所下降.

這些研究工作能夠減小KV數據壓縮過程中引入的寫放大，從而提高寫入性能.然而讀性能以及范圍檢索性能有所損失，且忽略了本地文件系統以及多重日志引入的負載.FlashKV[14-15]在LevelDB的基礎上，利用Open-Channel SSD[16-17]實現了一個由用戶層直接管理閃存存儲空間的KV存儲系統，去除了文件系統層以及SSD內部的閃存轉換層(flash translation layer, FTL)等功能有重合的層級，從而解決了多重日志的問題，但是依賴于特定的硬件設備.

總之，現有研究工作主要關注KV存儲系統中的壓縮負載，忽略了多重日志以及文件系統引入的負載，或者是需要特定的硬件支持來降低多重日志開銷.本文主要關注在通用硬件基礎上，如何減小文件系統以及多重日志的開銷以提升KV存儲系統的寫入和更新性能.

2 研究背景和動機

本節以流行的KV存儲系統RocksDB為例，簡要介紹基于LSM樹的KV存儲系統的架構以及基本操作，分析WAL文件引入的日志開銷問題.

2.1 LSM樹的基本架構和操作

LSM樹[3]是一種支持高效索引的數據持久性存儲結構，其基本思路是通過聚合內存中的多個更新操作并將其批量刷新到存儲中，從而將隨機寫轉換為順序寫以提升寫性能.圖1以RocksDB為例，展示了典型的LSM樹架構.RocksDB是由Facebook開源的一個典型的基于LSM樹的KV存儲系統，目前廣泛用于Facebook等眾多大數據系統中.RocksDB包含6個基本組件：memtable,immutable memtable,sstfile,WAL,Manifest和Current.其中memtable和immutable memtable常駐內存，而其他文件位于硬盤上.

Fig. 1 Typical architecture of LSM-tree[3]圖1 LSM樹的典型架構[3]

插入KV數據時，首先將數據追加到WAL文件中，然后將其刷新到磁盤以保證數據的持久性和安全性，之后將數據插入memtable以方便KV數據的查找與合并.memtable中的KV數據按照key的順序進行排序，方便對最近插入的KV進行高效查找和掃描.當memtable填滿時，將其轉化為只讀的immutable memtable，然后將其順序寫入到存儲設備上的有序字符串表文件(sorted string table file, sstfile)中.Manifest和Current是輔助文件，前者存儲sstfile的元數據；后者記錄當前Manifest文件的名稱，方便數據的檢索.

RocksDB為每個Li層配置了數據量閾值，當達到閾值時將啟動壓縮(compaction)操作，選擇該層中的部分sstfile與Li+1中key范圍與之有重合的sstfile進行合并排序，然后將排序好的數據順序寫入Li+1中新的sstfile中，再刪除相關的舊文件.因此memtable中包含最新的數據，然后依次是L0，L1，…層中的文件.由于L0層的數據是由內存中的memtable直接刷新到磁盤生成的，因此L0層的不同sstfile中的key可能會有重合，而L0層以外的各層是通過壓縮操作生成的，具有相同key的數據已經進行了合并，因此沒有重合數據.

LSM樹中數據的刪除操作通過插入刪除標記的形式來處理，以利用插入操作的性能優勢.具體而言，當需要刪除某個KV數據時，LSM樹首先在memtable中搜索key并為其設置刪除標記以表示該KV數據已被刪除.如果memtable中找不到該key，則LSM樹只為該key創建索引并插入刪除標記.在后續的壓縮操作中，所有包含刪除標記的KV數據都不會合并到新的sstfile中.通過這種方法，隨機刪除操作轉換為順序插入從而提高了操作性能.

LSM樹的數據查找基本流程是，從內存中的memtable開始，由上到下逐層搜索，直到找到所需的key或者確定其不在系統中.與B樹相比，LSM樹的點查詢操作可能需要多次的磁盤讀操作，從而導致讀取性能不高.因此，在實際中，LSM樹一般應用于寫密集型的場景，并利用布隆過濾器(Bloom filter)[18]等方法加速查詢操作.

2.2 LSM樹的日志負載

LSM樹在進行寫入操作時，數據首先持久化到WAL文件中，然后才可以寫入指定的文件，目的是保證數據的可靠性.雖然用戶可以選擇在RocksDB的配置中關閉WAL，或者設置WAL為非同步，即不及時將WAL中的數據刷新入磁盤.但是，對于許多云存儲系統或Web應用的數據管理系統，確保數據的可靠性通常至關重要，這意味著必須盡快將WAL同步到磁盤.因此，本文關注于WAL同步的場景.

圖2展示了RocksDB中WAL的寫I/O路徑.一次WAL的寫入會觸發多個磁盤操作，因為除了WAL中新加的數據需要及時寫入磁盤之外，WAL文件的元數據(主要是有效數據的大小)在每次數據更新之后都會發生變化，也必須同步到磁盤以保持文件系統的數據一致性.具體來說，當WAL寫請求到達時，將執行5個步驟：①將新數據寫入WAL文件；②將新數據刷新到磁盤；③將WAL文件的元數據寫入到元數據文件中；④將元數據文件刷新到磁盤;⑤向用戶返回WAL寫入成功的消息.因此，小塊KV數據的頻繁更新會引入大量的WAL寫操作，造成嚴重的性能開銷.本文將這些由于WAL寫入造成的性能開銷稱為日志開銷.

具體來說，日志開銷包括WAL數據寫入開銷及其引入的元數據更新開銷.WAL是保證數據可靠性所必需的，因此無法減小其數據寫入開銷.但是可以通過減少元數據更新來降低日志開銷.圖3展示了元數據更新引入的日志開銷的嚴重性.具體測試方法是調用RocksDB的PUT接口將具有不同value大小的KV數據(總量為256 MB)寫入RocksDB，并收集WAL文件的元數據更新數據量與實際寫入磁盤的數據量進行對比.

Fig. 2 Write path of WAL in RocksDB圖2 RocksDB中WAL的寫I/O路徑

Fig. 3 Metadata overhead of WAL file圖3 WAL文件元數據負載

由圖3可以看到，寫入磁盤的元數據量遠超原始的WAL寫入數據量.例如，當value大小為16 B時，數據更新造成的元數據寫入量達到了35 GB，而實際寫入磁盤的元數據量超過了70 GB，超過了原始的WAL寫入量(256 MB)的200倍.主要原因是為了保證WAL文件的元數據及時更新到磁盤，RocksDB使用直接I/O(即寫入文件時設置O_DIRECT選項)來同步元數據，每次寫入都必須與塊大小一致(在RocksDB中默認為4 KB)，因此不足4 KB的元數據寫入請求需要進行補零操作進行塊對齊才能寫入磁盤.因此，在小塊數據頻繁更新的場景下，WAL的頻繁寫入會造成嚴重的寫放大，大幅降低寫性能.

在通用文件系統中，上層應用無法細粒度地控制元數據更新，因而難以根據負載模式進行元數據更新流程的優化.同時，通用文件系統中的日志功能與KV存儲系統中的WAL機制在功能上有重疊，造成了多重日志的問題.雖然通用文件系統中可能有一些配置選項可以關閉日志，但這樣會增大當前系統中其他應用的數據安全性風險.

基于上述背景，本文提出了一個名為RocksFS的優化文件系統，針對LSM樹的KV存儲系統的負載模式進行優化，只保留KV負載所需的功能和接口，并重新設計WAL的存儲結構和更新流程以減小元數據負載，大幅提升了小塊KV數據的寫入和更新性能.

3 設計與實現

本節分析RocksFS的系統架構以及WAL寫入流程的優化方法.

3.1 RocksFS系統架構

如圖4所示，RocksFS是一個用戶庫，RocksDB可通過RocksFS管理塊設備，繞過復雜的通用文件系統，從而去除不必要的文件系統開銷.RocksFS只有2種不同的磁盤結構(即塊和文件)，存儲設備的第1個塊是版本塊(Version)，用于記錄此文件系統的版本信息；第2個塊是超級塊(Super Block)，用于記錄文件系統的元數據，例如設備路徑和元數據文件的位置等.元數據文件(metadata file)位于超級塊之后，用于記錄文件系統中的其他文件的元數據.每次文件更新時，必須將相應的元數據更新寫入元數據文件，并且同步到磁盤以確保數據一致性.當RocksDB掛載RocksFS時，將會加載元數據文件到內存中并重放，從而恢復RocksFS的所有元數據.RocksFS中每個文件的元數據量很小(不超過128 B)，因此對于RocksFS這樣的輕量級文件系統，將所有元數據緩存在內存中以提高性能是合理的.

Fig. 4 Architecture of RocksFS圖4 RocksFS架構

需要注意的是，元數據文件由一塊連續空間加上元數據塊索引信息組成，以支持元數據文件的動態變化.索引信息常駐內存，可迅速定位到分布在硬盤其他位置的各個元數據塊以保證訪問性能.由于元數據塊分布在硬盤的不同位置，因此一般不會造成硬盤某一位置成為熱點.此外，對于目前流行的SSD來說，設備內部的閃存轉化層會將上層應用的寫請求分散在不同的物理位置上，并且以異地更新的方式寫入新數據，同時預留空間、垃圾回收以及磨損均衡等技術放置某一物理位置的頻繁擦除.因此即使上層應用對某塊元數據頻繁更新，對SSD的整體壽命也影響不大.

Fig. 5 Main data structures in RocksFS圖5 RocksFS主要數據結構

圖5展示了RocksFS中的主要數據結構.RocksFS僅支持2層目錄，即目錄中只有文件但沒有子目錄.目錄映射表(dirmap)將目錄名稱映射到目錄結構(dir)，目錄結構中包含此目錄下的文件映射表(filemap)，而文件映射表將索引節點(inode)映射到具體文件結構(file).文件結構只包含5個成員，包括1個文件節點(fnode)、1個64 b文件引用計數(refs)，3個bool變量指示這個文件是否臟(dirty)、鎖定(locked)或刪除(deleted).fnode結構封裝了文件的關鍵元數據，包括inode編號(ino)、數據大小(size)、修改時間(mtime)以及表示此文件磁盤空間映射表(extents).通過這些結構，RocksFS能夠支持RocksDB所需的文件操作.

3.2 優化WAL存儲結構

圖6展示了RocksDB中的WAL文件格式.WAL文件由一系列不同長度的記錄組成(即r0，r1等)，每條記錄中包含了一次寫請求對應的數據以及校驗信息，并按kBlockSize(默認32 KB)的大小進行分組，不足的空間用空(null)數據填充(即P).讀寫操作都以kBlockSize為單位進行.

Fig. 6 Original WAL file format in RocksDB圖6 RocksDB中原始的WAL文件格式

Fig. 8 WAL write path in RocksFS圖8 RocksFS中的WAL寫流程

每個數據塊寫入WAL之后，首先將其刷新到底層磁盤，然后將元數據的更新寫入元數據文件，并及時將元數據文件寫入磁盤中以保證數據和元數據的一致性.通用的文件系統(如Ext4)必須在將新數據寫入WAL后及時將WAL的元數據(關鍵是有效數據量)寫入元數據文件，否則RocksDB將難以確定需要從WAL文件讀取的數據量，導致無法恢復正確的數據.然而正如2.2節所述，這些頻繁的元數據更新操作造成了嚴重的日志負載.

為了解決這個問題，RocksFS重新設計了WAL存儲結構，如圖7所示.將來自RocksDB的記錄(即r0，r1等)封裝到事務中.每個事務都有一個頭字段(Head)來指示其開始，一個長度字段(Len)記錄其數據量，以及一個尾部字段(Tail)包含數據校驗信息并標志事務的結束.由于事務中包含了記錄的長度信息以及校驗信息，因此不再需要頻繁地向元數據文件中更新WAL的元數據，而只需順序讀取WAL并解碼數據即可恢復有效事務.RocksFS接收到上層傳來的寫請求之后，首先將其包裝為事務，然后將數據追加到WAL中，通過優化后的WAL寫入流程(見3.3節)有條件地更新元數據，能夠大幅降低元數據更新頻率，提升存儲性能.

Fig. 7 New WAL file format in RocksFS圖7 RocksFS中新的WAL格式

RocksFS中的kBlockSize參數是根據RocksDB的對應參數設置的.RocksDB使用直接I/O讀寫WAL，因此I/O塊大小必須與磁盤塊(默認4 KB)大小對齊.設置較大粒度的I/O塊(如32 KB)能夠提升WAL讀寫帶寬，但是也會造成數據可靠性的粒度增大，寫入失敗時可能丟失的數據會增多.因此根據實際應用場景的權衡，RocksDB將其默認值設置為32 KB.由于RocksFS文件系統是根據此參數格式化創建的，因此無法動態調整該參數.并且寫入性能主要取決于元數據更新負載，而kBlockSize對元數據的更新頻率影響不大，實現該參數的動態調整難以提升寫入性能.

3.3 優化WAL寫入流程

優化后的WAL寫流程如圖8所示.當一批來自RocksDB的WAL文件寫操作到達RocksFS時，執行4個步驟：

1) 將寫請求編碼到事務中.

2) 檢查WAL文件的大小，確定是否可以容納當前事務.

3) 如果WAL中有足夠的空閑空間，則只需將事務追加到WAL中并將數據同步到磁盤.

4) 如果WAL中沒有足夠的空閑空間，為此WAL分配一塊新的空間(默認為4 MB)，將事務寫入其中并將數據同步到磁盤，然后更新WAL文件的元數據并將其同步到磁盤.

由于RocksDB中memtable的默認大小為4 MB，因此在將memtable寫入磁盤之前，系統會創建4 MB大小的WAL文件.默認配置下，這種粒度的WAL足以承載memtable的所有更新，因此無須將其設置得更大.在RocksFS中，只要WAL文件有充足的可用空間，就不需要更新其元數據，從而消除了大量的元數據更新，尤其是對于寫密集型的小塊KV負載.

RocksFS利用直接I/O(direct I/O)實現文件讀寫.通用文件系統中，使用緩存I/O(buffered I/O)一般可以提升性能，但是會造成數據在多級緩存中重復拷貝，消耗大量內存的同時也引入了額外的數據拷貝開銷以及緩存一致性開銷.由于RocksDB中的WAL更新需要盡快同步到磁盤以保證數據可靠性，因此在這種情況下使用直接I/O更簡單有效，并且能夠減小系統內存消耗.

3.4 崩潰一致性保證

為了保證RocksFS的崩潰一致性(crash consist-ency)，RocksFS中提供2類恢復機制：數據恢復機制和元數據恢復機制.數據的寫入通過WAL文件來保證原子性和安全性，只有在WAL寫入完成后，才將更新的數據寫入實際的文件.如果在文件寫入過程中發生崩潰，則使用WAL文件重做寫入操作以替換損壞的數據，恢復正確的數據.為了保證元數據的可靠性，元數據的更新以事務的形式同步到元數據文件，并立即將元數據文件刷新到磁盤中.如果在更新元數據的過程中發生崩潰，則在重新掛載RocksFS時，將元數據文件加載到內存中并重放其中的有效事務以恢復元數據，保持數據與元數據之間的一致性.

RocksFS基于Ceph[19]的本地存儲引擎文件系統BlueFS實現，通過Ceph中自帶的文件系統功能測試工具(bluefs_test)進行了完備性檢查，證明了其功能的完備性.BlueFS是分布式存儲系統Ceph針對RocksDB開發的簡化版文件系統，用于支持其本地存儲引擎的小塊數據以及元數據存儲.與BlueFS類似，RocksFS僅支持RocksDB所必需的操作，從而降低文件系統開銷.不同之處在于，RocksFS同時優化了WAL的存儲結構以及事務寫入流程，大幅降低了元數據更新負載.此外，RocksFS以共享庫的方式實現，可脫離RocksDB獨立使用，方便其他應用程序調用.

4 實驗與分析

本節在RocksDB的場景下，對比了RocksFS以及其他4個典型通用文件系統的性能，證明了RocksFS能夠大幅提升小塊KV數據的寫入和更新性能.

4.1 實驗設置

實驗設置如表1所示，通過RocksDB自帶的db_bench基準測試工具進行性能測試，測試的負載模式包括fillseq,fillrandom,readseq,readrandom,overwrite以及updaterandom.在配置不同文件系統的前提下，使用16個線程進行壓力測試，對比RocksDB的性能.由于在典型的KV存儲應用場景中，絕大部分的key大小不超過16 B，而value大小不超過1 KB[20]，因此實驗中設置key的大小為16 B，value的大小分別設置為16 B,64 B,256 B,1 KB,4 KB以及16 KB，這可以代表大多數場景下的KV工作負載.實驗中開啟了RocksDB的WAL同步選項，以測試在高數據可靠性要求場景下的KV存儲性能.

Table 1 Experiment Settings表1 實驗設置

由于每輪測試中value大小都是常量，因此可以使用每次基準測試的IOPS(即每秒完成的I/O操作)中位數統計值來代表各個文件系統下RocksDB的性能.每項測試中進行100萬次KV數據操作，每次測試之前首先清空系統緩存，然后按順序執行6個基準測試：

1) fillseq.隨機生成key和value，并按照key的順序插入KV數據.

2) readseq.從已有KV數據庫中按照key的順序讀取value.

3) readrandom.從已有KV數據庫中以隨機的key序列讀取value.

4) overwrite.以異步的方式，通過隨機的key序列重寫已有KV數據庫中的value.

5) updaterandom.以讀改寫的方式，通過隨機的key序列修改已有KV數據庫中的value.

6) fillrandom.以異步的方式，通過隨機的key序列向已有KV數據庫中寫入KV數據.

需要注意的是，在進行SSD上的性能測試時，隨著寫入數據量的增加，可能會觸發SSD內部的垃圾回收操作，導致性能突然下降.因此，在每輪文件系統測試之前，首先擦除整個SSD，以最大限度地減小前一輪測試的影響，從而獲得公平的性能.測試結果通過Ext4上的性能數據進行標準化以方便對比.

4.2 HDD上的性能對比

本節對比了HDD上采用不同文件系統后端時RocksDB在典型負載下的性能，結果如圖9所示:

如圖9所示，對于KV數據的寫入(即fillseq和fillrandom)或者更新(即updaterandom和overwrite)負載，RocksFS的性能遠高于其他文件系統，特別是對于小塊的KV數據.例如，當value大小為16 B時，RocksFS的寫入和更新性能比Ext4高5倍以上，比BlueFS高約1倍.主要原因是RocksFS通過優化WAL存儲結構以及寫入流程，大幅減小了日志開銷，從而提升了KV數據的寫入和更新性能.相反，通用的文件系統無法減少WAL文件更新引入的日志開銷以及其他不必要的文件系統開銷.而BlueFS雖然通過去除不必要的文件系統功能，減少了額外的文件系統開銷，同時提高了文件讀寫的順序性，但是日志開銷仍然很嚴重.因此，在BlueFS上，RocksDB的小塊KV寫入和更新性能比通用文件系統高，但是比RocksFS低.

Fig. 10 Performance comparison on SSD圖10 SSD上的性能對比

至于讀取性能，RocksFS和BlueFS通常略低于通用文件系統.具體來說，在順序讀取KV數據(即readseq)的負載下，RocksFS的性能基本與通用文件系統持平(差距小于10%)，而BlueFS的性能最多比通用文件系統低20%.主要原因是在順序讀取KV數據時，RocksDB中的memtable緩存的效果較好，大部分的KV數據可以在緩存中命中.因此雖然RocksFS以及BlueFS沒有文件系統緩存，但是順序讀取KV數據的性能與通用文件系統相比差距較小，特別是在value較小(如value小于1 KB時)的情況下.在隨機讀取KV數據(即readrandom)的負載下，RocksFS與BlueFS的小塊KV(如value小于1 KB時)隨機讀取性能基本與通用文件系統持平，而大塊KV隨機讀取性能則低于通用文件系統(不超過50%).主要是因為RocksDB中設置的memtable緩存有限，因此value越小，能夠緩存到的數據項越多，讀取操作的緩存命中率越高.當KV數據塊較大(如value大于1 KB)時，內存中的memtable不足以容納大量的KV數據項，降低了緩存命中率.但是通用文件系統依然可通過文件系統緩存來提升讀取性能，而RocksFS以及BlueFS采用直接I/O操作塊設備，在文件系統級別上沒有緩存機制，因此隨機讀取性能有所降低.

總之，與傳統文件系統相比，RocksFS能夠大幅提高RocksDB在HDD上的寫性能，并保持小塊KV數據的讀性能基本不受損失，但是大塊KV數據的讀性能有所降低.

4.3 SSD上的性能對比

本節對比了SSD上采用不同文件系統后端時RocksDB在典型負載下的性能，圖10展示了性能對比結果.每輪測試之前將整個SSD擦除以避免垃圾回收操作對后一輪測試造成的干擾.性能對比的總體結果與HDD上的結果類似.

如圖10所示，RocksFS的數據寫入(即fillseq和fillrandom)和更新(即updaterandom和overwrite)性能遠高于其他文件系統，尤其是在KV數據塊較小的場景下.例如當執行隨機更新KV數據的負載(即updaterandom)且value為16 B時，RocksFS的性能可達其他文件系統的8倍.而BlueFS在寫性能方面幾乎沒有提升.這主要是因為SSD上的隨機I/O操作的性能與順序I/O操作的性能差異很小，因此寫入和更新性能的高低主要取決于日志負載的大小，而BlueFS無法減小日志負載，因此難以有效提升寫入和更新性能.

至于SSD上的讀取(即readseq和readrandom)性能，在value比較小(例如小于1 KB)時，RocksFS和BlueFS的讀取性能與通用文件系統基本持平；而當value比較大(達到1 KB以上)時，RocksFS和BlueFS的讀取性能低于(最低約50%)通用文件系統.這主要因為傳統文件系統的文件系統緩存機制有助于提高讀取性能，而BlueFS和RocksFS利用直接I/O讀寫數據，因而沒有文件系統緩存機制，且RocksDB的memtable緩存有限，無法緩存大量的大塊KV數據項，因此memtable的緩存命中率較低，降低了讀性能.

總之，在SSD上，RocksFS作為RocksDB的后端文件系統的寫入和更新性能也遠高于BlueFS以及Ext4等通用文件系統，讀性能基本與通用文件系統持平，大塊KV數據的讀性能有所降低.因此，RocksFS非常適用于插入密集型的工作負載，特別是小塊的KV數據操作.

5 結果與討論

KV存儲已經成為大數據系統中的關鍵組件，其中基于LSM樹的KV存儲系統獲得了廣泛的應用.針對這些KV存儲系統中的文件系統開銷以及日志開銷引入的性能下降問題，本文提出了RocksFS，一個針對LSM樹優化的文件系統，去除通用文件系統中不必要的開銷，并優化日志存儲結構和更新流程以減少日志開銷，從而提高數據寫入和更新性能.實驗結果表明，與通用文件系統相比，RocksFS可以將RocksDB的小塊KV寫入和更新性能提高8倍左右，同時保證讀性能基本不受損失.

對于基于LSM樹的KV存儲系統，數據壓縮負載也是一個重要的問題，一些現有的研究試圖通過提高壓縮操作的性能加快存儲系統的寫操作.這些工作與本文是互補的，未來的研究工作可嘗試將這2種方法結合起來以進一步提高KV存儲系統的性能.