Lars
Hofhansl 在HBASE-5268提出一個(gè)"prefix
delete marker"的建議投储，大概的思想是
如果數(shù)據(jù)如下：
row column family：qualifier value
r1 cf1:101 XX
r1 cf1:102 XX
r1 cf1:103 XX
r1 cf1:201 XX
r1 cf1:202 XX
如果我們想刪除qualifier 101~103的數(shù)據(jù)技竟，那么在當(dāng)前hbase中只能一個(gè)接一個(gè)刪除啦桌，即打入三個(gè)delete
marker。Lars想引入一個(gè)前綴刪除機(jī)制辆它，即刪除某個(gè)family下面所有以XX開頭的qualifier榜晦，這樣有一個(gè)比較明顯的好處就是只需要加一次delete
marker玲献，在一些inner row很多的schema下软舌，要進(jìn)行range
delete時(shí)，這樣節(jié)省的開銷還是很大的牛曹。然而這個(gè)fix和get的一些邏輯有一定的沖突佛点，后來并未引入到新版本中，Lars也寫了一篇博客解釋了原因。結(jié)合這篇博客和https://issues.apache.org/jira/browse/HBASE-5268的comments
list可以對(duì)hbase的scan和delete機(jī)制有進(jìn)一步的了解超营。
在HBase的Delete操作一文中鸳玩，已經(jīng)對(duì)HBase的刪除做了介紹，文中有一點(diǎn)沒有提到就是delete marker的位置演闭。column delete marker和他們影響的KV對(duì)保存在一起不跟，而family delete marker永遠(yuǎn)置頂。
hbase(main):001:0> scan 'x2', {RAW=>true, VERSIONS=>10}
ROW COLUMN+CELL
r1 column=f:c, timestamp=1323323611106, value=v3
r1 column=f:c, timestamp=1323323609988, type=DeleteColumn
r1 column=f:c, timestamp=1323323609988, value=v2
r1 column=f:c, timestamp=1323323608554, value=v1
r2 column=f:c, timestamp=1323323617759, value=v3
r2 column=f:c, timestamp=1323323616226, value=v2
r2 column=f:c, timestamp=1323323614496, value=v1
2 row(s) in 0.6380 seconds
上圖中米碰，r1對(duì)f:c的刪除標(biāo)記是和kv排在一起的窝革，按照timestamp時(shí)間戳的先后排序
hbase(main):005:0> scan 'x1', {RAW=>true, VERSIONS=>10}
ROW COLUMN+CELL
r2 column=f:, timestamp=1323323616226, type=DeleteFamily
r2 column=f:c, timestamp=1323323617759, value=v3
r2 column=f:c, timestamp=1323323616226, value=v2
r2 column=f:c, timestamp=1323323614496, value=v1
2 row(s) in 0.0500 seconds
上圖中，刪除column family f的操作是排在最前面的吕座，盡管從時(shí)間順序上它是發(fā)生在v2之后虐译，插入v3之前。
在HBase的存儲(chǔ)結(jié)構(gòu)中吴趴，每個(gè)Column family對(duì)應(yīng)的是一個(gè)Store漆诽，數(shù)據(jù)存儲(chǔ)在數(shù)個(gè)Storefile中。Scan在Hbase中類似于由RegionScanner進(jìn)行的MergeSort锣枝，由StoreFileScanner厢拭，StoreScanner和RegionScanner將結(jié)果一級(jí)一級(jí)匯總。
RegionScanner / \ StoreScanner StoreScanner / \ / \ StoreFileScanner StoreFileScanner StoreFileScanner StoreFileScanner | | | | StoreFile StoreFile StoreFile StoreFile
當(dāng)我們進(jìn)行如下一系列操作時(shí)：
put: row1, family, col1, value1, T
delete family: row1, family, T+1
put: row1, family, col1, value2, T+2
delete columns: row1, family, col1, T+3
put: row1, family, col1, value3, T+4
實(shí)際上撇叁，存下來的數(shù)據(jù)格式類似于
family-delete row1, T+1
row1,col1,value3, T+4
column-delete row1,col1, T+3
row1,col1,value2, T+2
row1,col1,value1, T
family delete marker在最前面是因?yàn)樗鼤?huì)影響到很多行數(shù)據(jù)供鸠，所以Hbase進(jìn)行了優(yōu)化，讓Scanner一開始就可以知道它税朴，然后繼續(xù)向下掃回季。這就帶來了如下結(jié)果：
就算我們想找到一個(gè)特定的Qualifier對(duì)應(yīng)的Value，我們也需要先seek到這行的開始來看看是否有family delete marker正林，他們的時(shí)間戳是否大于等于我們感興趣的那個(gè)qualifier-value的version泡一。
Lars對(duì)Prefix delete marker一開始的設(shè)計(jì)是讓它處于kv對(duì)之間，如同column delete marker一樣觅廓，但是這樣的設(shè)計(jì)會(huì)帶來如下問題：
一個(gè)row或者一個(gè)Qualifier的開始是一個(gè)定點(diǎn)鼻忠，然而一個(gè)Qualifier
prefix不一定。如當(dāng)前qualifier有1013,102,103杈绸，我們可以認(rèn)為Qualifier
prefix為10的點(diǎn)在1013前面帖蔓，然而如果我們加入一個(gè)新的Qualifier1012，那么這個(gè)點(diǎn)就要在1012前面瞳脓，為了確定某個(gè)qualifier是否被刪掉塑娇，scanner必須掃描所有可能影響到他的prefix
marker，而這個(gè)很可能需要進(jìn)行全表掃描劫侧，開銷太大埋酬。
然后Lars改變了prefix delete
marker的位置哨啃，把他等同于family delete
marker，也就是在行內(nèi)置頂写妥，這樣做可以work拳球，不過會(huì)有一些潛在的問題。因?yàn)閷?duì)于每一個(gè)row珍特，delete
family的次數(shù)不會(huì)太多祝峻，因?yàn)橐粋€(gè)storefile只有一個(gè)column
family，所以對(duì)于scanner來說扎筒，它只需要記住這個(gè)family delete發(fā)生的時(shí)間戳莱找，而prefix
delete可能會(huì)很多，組合也會(huì)比較復(fù)雜砸琅，如果每掃到一行KV宋距，都要對(duì)delete
marker集合進(jìn)行判斷，scan開銷就會(huì)較大症脂，也就達(dá)不到一開始設(shè)計(jì)的初衷了谚赎。于是最后他們決定won‘t
fix,不過patch做好了，只是不會(huì)加入新版本中诱篷。如果業(yè)務(wù)中有這樣的需求：需要對(duì)某些具有共同前綴的qualifier進(jìn)行刪除壶唤，然而這種刪除操作不太頻繁（每兩次major
compaction之間這樣的操作在少數(shù)幾次），那么可以考慮加入這個(gè)patch棕所，這樣可以優(yōu)化下存儲(chǔ)和刪除的效率闸盔。
PS：在jira里面，他們討論的還是很熱烈的琳省，差不多一天內(nèi)lars改了6版迎吵，真勤奮啊~
