文章目錄

• • 為什么需求K-V數據庫？
  • BigTable與LevelDB
  • 特點
  • 應用場景
  • RocksDB

---

LevelDB 是一個由 Google 公司所研發的 K-V 存儲嵌入式數據庫管理系統編程庫，以開源的 BSD 許可證發布。其作為 LSM Tree 的經典實現，具有很高的隨機寫，順序讀/寫性能，但是隨機讀的性能很一般，也就是說，LevelDB很適合應用在查詢較少，而寫很多的場景。

為什么需求K-V數據庫？

K-V 數據庫主要用于存取、管理關聯性的數組。關聯性數組又稱映射、字典，是一種抽象的數據結構，其數據對象為一個個的 key-value 數據對，且在整個數據庫中每個 key 均是唯一的。

隨著近年來互聯網的興起，云計算、大數據應用越來越廣泛，對于數據庫來說也出現了一些需要面對的新情況：

• 數據量呈指數級增長，存儲也開始實現分布式。
• 查詢響應時間要求越來越快，需在1秒內完成查詢操作。
• 應用一般需要 7 × 24 小時連續運行，因此對穩定性要求越來越高，通常要求數據庫支持熱備份，并實現故障下快速無縫切換。
• 在某些應用中，寫數據比讀數據更加頻繁，對數據寫的速度要求也越來越高。
• 在實際應用中，并不是所有環境下的數據都是完整的結構化數據，非結構化數據普遍存在，因此如何實現對靈活多變的非結構化數據的支持是需要考慮的一個問題。

正是在上述情況的催生下，2010年開始興起了一場 NoSQL 運動，而 K-V 數據庫作為 NoSQL 中一種重要的數據庫也日益繁榮，因此催生出了許多成功的商業化產品，并得到了廣泛應用。

BigTable與LevelDB

早在 2004 年，Google 開始研發一種結構化的分布式存儲系統，它被設計用來處理海量數據，通常是分布在數千臺普通服務器上的 PB 級的數據——這一系統就是風靡全球的 Bigtable。

2006 年，Google 發表了一篇論文——《Bigtable: A Distributed Storage System for StructuredData》。這篇論文公布了 Bigtable 的具體實現方法，揭開了 Bigtable 的技術面紗。Bigtable 雖然也有行、列、表的概念，但不同于傳統的關系數據庫，從本質上講，它是一個稀疏的、分布式的、持久化的、多維的排序鍵-值映射。

雖然 Google 公布了 Bigtable 的實現論文，但 Bigtable 依賴于 Google 其他項目所開發的未開源的庫，Google 一直沒有將 Bigtable 的代碼開源。然而這一切在 2011 年迎來了轉機。Sanjay Ghemawat 和 Jeff Dean 這兩位來自 Google 的重量級工程師，為了能將 Bigtable 的實現原理與技術細節分享給大眾開發者，于2011年基于 Bigtable 的基本原理，采用 C++ 開發了一個高性能的 K-V 數據庫——LevelDB。由于沒有歷史的產品包袱，LevelDB 結構簡單，不依賴于任何第三方庫，具有很好的獨立性，雖然其有針對性地對 Bigtable 進行了一定程度的簡化，然而Bigtable的主要技術思想與數據結構均在 LevelDB 予以體現了。因此 LevelDB 可看作 Bigtable 的簡化版或單機版。

特點

優點：

• key 與 value 采用字符串形式，且長度沒有限制。

• 數據能持久化存儲，同時也能將數據緩存到內存，實現快速讀取。

• 基于 key 按序存放數據，并且 key 的排序比較函數可以根據用戶需求進行定制。

• 支持簡易的操作接口 API，如 Put、Get、Delete，并支持批量寫入。

• 可以針對數據創建數據內存快照。

• 支持前向、后向的迭代器。

• 采用 Google 的 Snappy 壓縮算法對數據進行壓縮，以減少存儲空間。

• 基本不依賴其他第三方模塊，可非常容易地移植到 Windows、Linux、UNIX、Android、iOS。

  
  

缺點：

• 不是傳統的關系數據庫，不支持SQL查詢與索引。

• 只支持單進程，不支持多進程。

• 不支持多種數據類型。

• 不支持 C/S 的訪問模式。用戶在應用時，需要自己進行網絡服務的封裝。

  
  

應用場景

LevelDB主要應用于查少寫多的場景，如：

• 常見的 Web 場景，可以存儲用戶的個人信息資料、對文章或博客的評論、郵件等。

• 具體到電子商務領域，可以存儲購物車中的商品、產品類別、產品評論。

• 存儲整個網頁，其將網頁的 URL 作為 key，網頁的內容作為 value。

• 構建更為復雜的存儲系統，如日志系統、緩存、消息隊列等。

• ……

  
  

RocksDB

RocksDB 是基于 LevelDB 開發的，并保留、繼承了 LevelDB 原有的基本功能，也是一個嵌入式的 K-V 數據存儲庫。RocksDB 設計之初，正值 SSD 硬盤興起。然而在當時，無論是傳統的關系數據庫如 MySQL，還是分布式數據庫如 HDFS、HBase，均沒有充分發揮 SSD 硬盤的數據讀寫性能。因而 Facebook 當時的目標就是開發一款針對 SSD 硬盤的數據存儲產品，從而有了后面的 RocksDB。RocksDB 采用嵌入式的庫模式，充分發揮了 SSD 的性能。

為什么要基于LevelDB實現RocksDB？

一般而言，數據庫產品有兩種訪問模式可供選擇。一種是直接訪問本地掛載的硬盤，即嵌入式的庫模式；另一種是客戶端通過網絡訪問數據服務器，并獲取數據。假設 SSD 硬盤的讀寫約 100 μs，機械硬盤的讀寫約 10 ms，兩臺 PC 間的網絡傳輸延遲為 50 μs。可以分析得知，如果在機械硬盤時代，采用 C/S 的數據服務模式，客戶端進行一次數據查詢約為 10.05 ms，可見網絡延遲對于數據查詢速度的影響微乎其微；而在 SSD 硬盤時代，客戶端進行一次數據查詢約為 150 μs，但與直接訪問 SSD 硬盤相比，整體速度慢了 50%，因而直接影響了整體性能。正是在這樣的背景下，Facebook的工程師們選擇了 LevelDB 來實現 RocksDB 的原型。

RocksDB 使用了一個插件式的架構，這使得它能夠通過簡單的擴展適用于各種不同的場景。插件式架構主要體現在以下幾個方面：

不同的壓縮模塊插件：例如 Snappy、Zlib、BZip 等（LevelDB 只使用 Snappy）。

Compaction 過濾器：一個應用能夠定義自己的 Compaction 過濾器，從而可以在 Compaction 操作時處理鍵。例如，可以定義一個過濾器處理鍵過期，從而使 RocksDB 有了類似過期時間的概念。

MemTable 插件：LevelDB 中的 MemTable 是一個 SkipList，適用于寫入和范圍掃描，但并不是所有場景都同時需要良好的寫入和范圍掃描功能，此時用 SkipList 就有點大材小用了。因此 RocksDB 的 MemTable 定義為一個插件式結構，可以是 SkipList，也可以是一個數組，還可以是一個前綴哈希表（以字符串前綴進行哈希，哈希之后尋找桶，桶內的數據可以是一個 B 樹）。因為數組是無序的，所以大批量寫入比使用 SkipList 具有更好的性能，但不適用于范圍查找，并且當內存中的數組需要生成為 SSTable 時，需要進行再排序后寫入Level 0。前綴哈希表適用于讀取、寫入和在同一前綴下的范圍查找。因此可以根據場景使用不同的MemTable。

SSTable 插件：SSTable 也可以自定義格式，使之更適用于 SSD 的讀取和寫入。除了插件式架構，RocksDB 還進行了一些寫入以及 Compaction 操作方面的優化，主要有以下幾個方面：

• 線程池：可以定義一個線程池進行 Level 0～Level 5 的 Compaction 操作，另一個線程池進行將MemTable 生成為 SSTable 的操作。如果 Level 0～Level 5 的 Compaction 操作沒有重疊的文件，可以并行操作，以加快 Compaction 操作的執行。
• 多個 Immutable MemTable：當 MemTable 寫滿之后，會將其賦值給一個 ImmutableMemTable，然后由后臺線程生成一個 SSTable。但如果此時有大量的寫入，MemTable 會迅速再次寫滿，此時如果Immutable MemTable 還未執行完 Compaction 操作就會阻塞寫入。因此 RocksDB 使用一個隊列將Immutable MemTable 放入，依次由后臺線程處理，實現同時存在多個 ImmutableMemTable。以此優化寫入，避免寫放大，當使用慢速存儲時也能夠加大寫吞吐量。

總結

以上是生活随笔為你收集整理的LevelDB是什么？为什么我们需要K-V存储？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。