LevelDB是什么？为什么我们需要K-V存储？
文章目錄
- 為什么需求K-V數(shù)據庫？
- BigTable與LevelDB
- 特點
- 應用場景
- RocksDB
LevelDB 是一個由 Google 公司所研發(fā)的 K-V 存儲嵌入式數(shù)據庫管理系統(tǒng)編程庫，以開源的 BSD 許可證發(fā)布。其作為 LSM Tree 的經典實現(xiàn)，具有很高的隨機寫，順序讀/寫性能，但是隨機讀的性能很一般，也就是說，LevelDB很適合應用在查詢較少，而寫很多的場景。
為什么需求K-V數(shù)據庫？
K-V 數(shù)據庫主要用于存取、管理關聯(lián)性的數(shù)組。關聯(lián)性數(shù)組又稱映射、字典，是一種抽象的數(shù)據結構，其數(shù)據對象為一個個的 key-value 數(shù)據對，且在整個數(shù)據庫中每個 key 均是唯一的。
隨著近年來互聯(lián)網的興起，云計算、大數(shù)據應用越來越廣泛，對于數(shù)據庫來說也出現(xiàn)了一些需要面對的新情況：
- 數(shù)據量呈指數(shù)級增長，存儲也開始實現(xiàn)分布式。
- 查詢響應時間要求越來越快，需在1秒內完成查詢操作。
- 應用一般需要 7 × 24 小時連續(xù)運行，因此對穩(wěn)定性要求越來越高，通常要求數(shù)據庫支持熱備份，并實現(xiàn)故障下快速無縫切換。
- 在某些應用中，寫數(shù)據比讀數(shù)據更加頻繁，對數(shù)據寫的速度要求也越來越高。
- 在實際應用中，并不是所有環(huán)境下的數(shù)據都是完整的結構化數(shù)據，非結構化數(shù)據普遍存在，因此如何實現(xiàn)對靈活多變的非結構化數(shù)據的支持是需要考慮的一個問題。
正是在上述情況的催生下，2010年開始興起了一場 NoSQL 運動，而 K-V 數(shù)據庫作為 NoSQL 中一種重要的數(shù)據庫也日益繁榮，因此催生出了許多成功的商業(yè)化產品，并得到了廣泛應用。
BigTable與LevelDB
早在 2004 年，Google 開始研發(fā)一種結構化的分布式存儲系統(tǒng)，它被設計用來處理海量數(shù)據，通常是分布在數(shù)千臺普通服務器上的 PB 級的數(shù)據——這一系統(tǒng)就是風靡全球的 Bigtable。
2006 年，Google 發(fā)表了一篇論文——《Bigtable: A Distributed Storage System for StructuredData》。這篇論文公布了 Bigtable 的具體實現(xiàn)方法，揭開了 Bigtable 的技術面紗。Bigtable 雖然也有行、列、表的概念，但不同于傳統(tǒng)的關系數(shù)據庫，從本質上講，它是一個稀疏的、分布式的、持久化的、多維的排序鍵-值映射。
雖然 Google 公布了 Bigtable 的實現(xiàn)論文，但 Bigtable 依賴于 Google 其他項目所開發(fā)的未開源的庫，Google 一直沒有將 Bigtable 的代碼開源。然而這一切在 2011 年迎來了轉機。Sanjay Ghemawat 和 Jeff Dean 這兩位來自 Google 的重量級工程師，為了能將 Bigtable 的實現(xiàn)原理與技術細節(jié)分享給大眾開發(fā)者，于2011年基于 Bigtable 的基本原理，采用 C++ 開發(fā)了一個高性能的 K-V 數(shù)據庫——LevelDB。由于沒有歷史的產品包袱，LevelDB 結構簡單，不依賴于任何第三方庫，具有很好的獨立性，雖然其有針對性地對 Bigtable 進行了一定程度的簡化，然而Bigtable的主要技術思想與數(shù)據結構均在 LevelDB 予以體現(xiàn)了。因此 LevelDB 可看作 Bigtable 的簡化版或單機版。
特點
優(yōu)點：
-
key 與 value 采用字符串形式，且長度沒有限制。
-
數(shù)據能持久化存儲，同時也能將數(shù)據緩存到內存，實現(xiàn)快速讀取。
-
基于 key 按序存放數(shù)據，并且 key 的排序比較函數(shù)可以根據用戶需求進行定制。
-
支持簡易的操作接口 API，如 Put、Get、Delete，并支持批量寫入。
-
可以針對數(shù)據創(chuàng)建數(shù)據內存快照。
-
支持前向、后向的迭代器。
-
采用 Google 的 Snappy 壓縮算法對數(shù)據進行壓縮，以減少存儲空間。
-
基本不依賴其他第三方模塊，可非常容易地移植到 Windows、Linux、UNIX、Android、iOS。
缺點：
-
不是傳統(tǒng)的關系數(shù)據庫，不支持SQL查詢與索引。
-
只支持單進程，不支持多進程。
-
不支持多種數(shù)據類型。
-
不支持 C/S 的訪問模式。用戶在應用時，需要自己進行網絡服務的封裝。
應用場景
LevelDB主要應用于查少寫多的場景，如：
-
常見的 Web 場景，可以存儲用戶的個人信息資料、對文章或博客的評論、郵件等。
-
具體到電子商務領域，可以存儲購物車中的商品、產品類別、產品評論。
-
存儲整個網頁，其將網頁的 URL 作為 key，網頁的內容作為 value。
-
構建更為復雜的存儲系統(tǒng)，如日志系統(tǒng)、緩存、消息隊列等。
-
……
RocksDB
RocksDB 是基于 LevelDB 開發(fā)的，并保留、繼承了 LevelDB 原有的基本功能，也是一個嵌入式的 K-V 數(shù)據存儲庫。RocksDB 設計之初，正值 SSD 硬盤興起。然而在當時，無論是傳統(tǒng)的關系數(shù)據庫如 MySQL，還是分布式數(shù)據庫如 HDFS、HBase，均沒有充分發(fā)揮 SSD 硬盤的數(shù)據讀寫性能。因而 Facebook 當時的目標就是開發(fā)一款針對 SSD 硬盤的數(shù)據存儲產品，從而有了后面的 RocksDB。RocksDB 采用嵌入式的庫模式，充分發(fā)揮了 SSD 的性能。
為什么要基于LevelDB實現(xiàn)RocksDB？
一般而言，數(shù)據庫產品有兩種訪問模式可供選擇。一種是直接訪問本地掛載的硬盤，即嵌入式的庫模式；另一種是客戶端通過網絡訪問數(shù)據服務器，并獲取數(shù)據。假設 SSD 硬盤的讀寫約 100 μs，機械硬盤的讀寫約 10 ms，兩臺 PC 間的網絡傳輸延遲為 50 μs。可以分析得知，如果在機械硬盤時代，采用 C/S 的數(shù)據服務模式，客戶端進行一次數(shù)據查詢約為 10.05 ms，可見網絡延遲對于數(shù)據查詢速度的影響微乎其微；而在 SSD 硬盤時代，客戶端進行一次數(shù)據查詢約為 150 μs，但與直接訪問 SSD 硬盤相比，整體速度慢了 50%，因而直接影響了整體性能。正是在這樣的背景下，Facebook的工程師們選擇了 LevelDB 來實現(xiàn) RocksDB 的原型。
RocksDB 使用了一個插件式的架構，這使得它能夠通過簡單的擴展適用于各種不同的場景。插件式架構主要體現(xiàn)在以下幾個方面：
- 線程池：可以定義一個線程池進行 Level 0～Level 5 的 Compaction 操作，另一個線程池進行將MemTable 生成為 SSTable 的操作。如果 Level 0～Level 5 的 Compaction 操作沒有重疊的文件，可以并行操作，以加快 Compaction 操作的執(zhí)行。
- 多個 Immutable MemTable：當 MemTable 寫滿之后，會將其賦值給一個 ImmutableMemTable，然后由后臺線程生成一個 SSTable。但如果此時有大量的寫入，MemTable 會迅速再次寫滿，此時如果Immutable MemTable 還未執(zhí)行完 Compaction 操作就會阻塞寫入。因此 RocksDB 使用一個隊列將Immutable MemTable 放入，依次由后臺線程處理，實現(xiàn)同時存在多個 ImmutableMemTable。以此優(yōu)化寫入，避免寫放大，當使用慢速存儲時也能夠加大寫吞吐量。
總結
以上是生活随笔為你收集整理的LevelDB是什么？为什么我们需要K-V存储？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 现代的缓存设计方案：Window-Tin
- 下一篇： LevelDB 源码剖析（一）准备工作：