leveldb只是單純的在檔案末尾增加，並不改寫原有的內容，那麼如果刪除乙個key，或者更新乙個key應該怎麼辦呢？比如：
table[
"liming"]=
18del table[
"liming"
]table[
"liming"]=
20table[
"liming"]=
21
leveldb將每乙個操作變化成如下的格式：
userkey sequence type : value
// user_key: 即使用者儲存的key
// 比如 table["liming"] = 18 table["wangdong"] = 20
// "liming", "wangdong" 就是user_key。
// sequence為操作序列號
// type操作是刪除還是更新
// value是值
上面的一系列操作就變為:
liming 1 ktypevalue :
18liming 2 ktypedeletion
liming 3 ktypevalue :
20liming 4 ktypevalue :
21
內部按照key非遞減，sequence非遞增，ktypevalue非遞增排序(保證ktypedeletion在前面)進行排序（儲存在skiplist中），這樣查詢時便可以找到key對應的最新值，如果type位ktypedeletion則不存在。
下面介紹一下什麼是user_key memtablekey internalkey lookupkey
memtable的內容是：
key_size : varint32 of internal_key.size()
key_bytes :
char
[internal_key.size()
]value_size : varint32 of value.size()
value_bytes:
:char
[value.size()
][ksize]
[---internalkey---
][vsize]
[---value---
]memtablekey為：[ksize]
[---internalkey---
]即internalkey的序列化
internalkey的格式
[
--------user_key--------
][sequence type]
[ 低8位元組 ]
如何獲得user_key
slice(internal_key.data(), internal_key.size() - 8 )
lookupkey
[klength]
[--------user_key--------
][sequence type]
[klength]
[-------------internal_key---------------
]
為什麼要lookupkey？ 主要是和內部memtablekey一致。
為什麼要internalkey？把memtablekey從記憶體中讀出來就是internalkey，及memtable_key是internalkey的序列化。
leveldb原始碼分析1
leveldb是乙個key value型的儲存引擎，由google開發，並宣布在bsd許可下開放源 plain git clone plain cd leveldb make all 此時生成libleveldb.a庫檔案。拷貝leveldb的標頭檔案到 usr include下 plain cp ...
levelDB原始碼分析 SSTable
sstable是bigtable中至關重要的一塊，對於leveldb來說也是如此，對leveldb的sstable實現細節的了解也有助於了解bigtable中一些實現細節。本節內容主要講述sstable的靜態布局結構，sstable檔案形成了不同level的層級結構，至於這個層級結構是如何形成的我們...
Leveldb原始碼分析 1
前言 看了一點oceanbase，沒有意志力繼續堅持下去了，暫時就此中斷，基本上算把master看完了，比較重要的update server和merge server 卻沒有細看。中間又陸續研究了hadoop的原始碼，主要是name node和寫入pipeline。主要的目的是想看看name nod...