技術標籤：技術分享資料庫

LevelDB內容概述：

•簡介

•設計思想（LSM-Tree）

•整體框架（6大元件）

•主要操作（增刪改查等）

1、簡介：

Leveldb是一個google實現的非常高效的KV資料庫，能夠支援billion（十億）級別的資料量。

在這個數量級別下還有著非常高的效能，主要歸功於它的良好的設計。特別是LSM演算法（Log Structured Merge Trees(LSM)原理,即日誌結構合併樹）。
官方網站報道其寫效能40萬/s，讀效能達到6萬/s，寫操作要遠快於讀操作。

不像二叉樹，平衡樹，紅黑樹，是一種單獨的資料結構，我理解的LSM是一種思想。

2、設計思想：

如圖：LSM-Tree的思路是將索引樹結構拆成一大一小兩顆樹，較小的一個常駐記憶體，較大的一個持久化到磁碟，他們共同維護一個有序的key空間。

LevelDB的資料是儲存在磁碟上的。levelDB寫效能極高，因為LSM-Tree將磁碟的隨機寫轉化為順序寫，從而大大提高了寫速度。

此部分內容瞭解：隨機讀寫和順序讀寫，有助於深入理解leveldb；
1 隨機讀寫和順序讀寫： 
1.1 訪問磁碟耗時
一個磁碟從內到外有許多磁軌，一個磁軌又被劃分成多個相同的扇區。 一次訪盤請求（讀/寫）完成過程由三個動作組成： 
1）尋道（時間）：磁頭移動定位到指定磁軌
2）旋轉延遲（時間）：等待指定扇區從磁頭下旋轉經過 
3）資料傳輸（時間）：資料在磁碟與記憶體之間的實際傳輸

1.2 連續IO和隨機IO
1）連續 I/O ：是本次 I/O 給出的初始扇區地址和上一次 I/O 的結束扇區地址是完全連續或者相隔不多的。反之，如果相差很大，則算作一次隨機 I/O。
2）連續 I/O 比隨機 I/O 效率高的原因是：在做連續 I/O 的時候，磁頭幾乎不用換道，或者換道的時間很短；而對於隨機 I/O，如果這個 I/O 很多的話，會導致磁頭不停地換道，造成效率的極大降低。
3）總的來說是因為隨機讀寫是儲存在不同的位置，所以需要不斷的尋道和旋轉延遲，這就耗費了大量的時間，這個時間可能是傳輸時間的許多倍，而順序讀則都是按順序儲存，是以追加的方式進行儲存，因此順序讀比隨機讀快，而且快的是好幾個數量級的。   

levelDB的設計思想，LSMTree就是存資料的時候，把資料做好排序，順序寫入到磁碟中，從而提高寫的速度；
而leveldb真正寫的快的原因，不在於此，需要區分一下（這裡的順序寫入磁碟是指:從記憶體到磁碟的合併過程；而真正的寫入操作只有兩步就完成了：1.一次磁碟log檔案追加寫；2.一次記憶體寫操作，這才是levelDb寫入速度高效的根本原因）
 

如上圖：LSM-Tree日誌結構合併樹，顧名思義需要合併的樹。

寫入操作會首先操作記憶體中的樹，隨著記憶體中樹的不斷變大，會觸發與磁碟中樹的歸併操作。

隨著資料的不斷寫入，磁碟中的樹會不斷膨脹，為了避免每次參與歸併操作的資料量過大，LevelDB將磁碟中的資料又拆分成多層，每一層的資料達到一定容量後會觸發向下一層的歸併操作，每一層的資料量比其上一層成倍增長。

這也就是LevelDB的名稱來源。

這是levelDB的設計思想，接下來詳細介紹，levelDB的整體架構，和6大元件，請看：
二、levelDB整體框架，及memtable、log檔案、immutable memtable


相關內容快速導航：

三、levelDB整體框架之sstable,manfest檔案,current檔案