hbase中索引資料主要分為兩類：
一部分儲存在記憶體中
一部分儲存在磁碟中
常見的記憶體索引結構有紅黑樹和二叉樹，hbase使用了跳躍表
之所以使用跳躍表，一方面是因為跳躍表實現相對簡單；另一方面是因為跳躍表在併發場景下加鎖粒度更小，能夠乘載更多的併發
儲存在磁碟部分的索引使用的是lsm(log structure merge)，這裡儲存的不是資料，而是資料的操作記錄，包括資料的內容和對資料的操作型別
我們都知道mysql innodb儲存引擎底層使用的索引結構就是b+樹，那麼為什麼hbase沒有使用b+樹作為自己的索引結構呢？
主要是因為當只有少量寫的時候，b+樹的效能還好，但是當發生大量寫的時候，就會導致寫效能的下降。
這裡可以回憶一下b+樹的資料修改過程，使用待插入的key和當前樹節點儲存的幾個索引值進行比較，確定屬於下層哪個資料節點，然後使用待插入key來和其儲存的幾個索引值進行比較，重複上述過程，直到葉子節點。
如果有大量的併發寫操作，那麼就會在磁碟中發生大量的在磁碟塊中查詢資料的過程，如果這些大量的待插入的key不在同乙個或者相鄰的磁碟塊中，那麼會發生大量的隨機io，而我們知道磁碟的隨機io相較於順序io是很慢的
而lsm是如何解決的呢，主要通過一下幾個方面來解決：
lsm索引結構包含了兩個部分：記憶體部分和磁碟部分，在hbase中使用的lsm記憶體部分使用的資料結構就是前面說的跳躍表當發生寫操作的時，首先將這個操作作為記錄追加到乙個預寫日誌中，然後將其寫入到記憶體中，從上面這個過程我們可以看到，這裡發生的磁碟寫，因為是追加操作，所以是順序io，從而避免了隨機io
當記憶體中的memstore寫滿之後，會將memstore中的內容刷寫到磁碟中，因為記憶體中的跳躍表資料已經是有序的列，因此此時的刷寫仍然是順序io
當刷寫到磁碟的檔案過多時，此時一次查詢可能需要遍歷多個檔案，從而影響效能，因此為了減少磁碟中的檔案數量，hbase會對磁碟檔案進行合併
這裡需要注意，hbase底層的儲存時基於hdfs的，而hdfs本身是不支援插入操作的，只支援追加操作，這也為hbase選擇lsm作為索引結構提供了必然性
這裡的儲存結構沒什麼特別的，和一般的儲存結構相似，使用一部分位元組用來儲存帶儲存內容的位元組個數，然後用一部分位元組來儲存內容
但是這裡需要注意的是，hbase儲存的key，從上面這張圖可以看到，key部分主要包括了rowkey、family、qualifier、timestamp和type
其中type代表操作，比如put、delete等，也就是說hbase中的lsm是儲存了操作型別的
hbase中的檔案合併主要分為兩種：
minor compaction，只對少數幾個檔案進行合併，優點是合併的檔案個數少，對磁碟的較小；缺點是因為只對區域性資料進行了合併，因此無法徹底刪除那些delete操作刪除的資料（比如當前合併的檔案中並沒有包含某條資料的delete操作記錄，而該操作記錄在另外乙個檔案中，從而就無法在合併的時候真正刪除這些檔案）
major compaction，對全部檔案進行合併，因此會將標誌為刪除的資料真正刪除掉。優點是合併後只有乙個檔案，進行讀操作時只需要讀取乙個檔案，效率是最高的；缺點是對大量的檔案進行合併操作，肯定會加大對磁碟的壓力，從而會影響hbase的效能，會造成毛刺
hbase會周期性地執行major compaction，當檔案數量超過閾值時，則會執行minor compaction來合併少量檔案
當存在大量磁碟檔案時，如果每次執行讀操作都需要遍歷這些檔案來查詢資料，會極大地影響讀效能，因此為了提公升讀效能，一是通過上面所說的compaction，來減少檔案數量；另外乙個就是只對部分檔案進行查詢，那麼需要對哪些檔案進行查詢呢，這個時候使用的就是bloom filter，可以為每個檔案設定乙個bloom filter
bloom filter包含了乙個位元組陣列，因此每個位置上的資料只能是0和1，初始值都為0
插入資料
當向bloom filter中新增資料時，會對這個資料進行多次hash，將每次hash後的結果和位元組陣列的長度進行取模，確定乙個陣列中的位置，然後將該位置上的資料置為1，因此一次資料插入會對應陣列多個位置上資料被置為1
判斷資料是否存在
從上面的操作可以知道，如果乙個資料被插入到了bloom filter，那麼陣列上的一些位置上的資料一定是1
同理，為了判斷資料是否被插入，仍然對資料進行多次hash，然後取模，來判斷多個位置上的數字是否都為1即可
但是，這裡可能會發生誤判，可能這些位置上的1是其他資料插入導致的，但是可以保證如果這些位置上的數字有的為0，那麼當前判斷的資料是一定沒有插入到bloom filter中的（畢竟資料的插入只會將位置上的數字設定為1，而不會設定為0）
bloom filter的型別
Hbase二級索引
hbase的查詢都是通過rowkey 要把多條件組合查詢的字段都拼接在rowkey中顯然不太可能 或者全表掃瞄再結合過濾器篩選出目標資料 太低效 所以通過設計hbase的二級索引來解決這個問題。多個查詢條件構成了多維度的組合查詢，需要根據不同組合查詢出符合條件的資料。例如 按照電影維度查詢資料適合,...
Hbase 學習筆記 Hbase 概覽
hbase構建在 hdfs 之上，hbase內部管理的檔案全部儲存在hdfs 中 行鍵，table的主鍵，table中的記錄按照row key排序。型別為byte array 列簇，table在水平方向有乙個或者多個column family組成，乙個column family中可以由任意多個col...
Hbase學習筆記
1.table中行是按照row key的字典序排列的 2.在行的方向上分隔為多個region 3.hregion是hbase 中分布式儲存和負載均衡的最小單位，這表示不同的region可以分布在不同的regionserver上 當乙個region足夠大時，現在是256m 就會split，乙個regi...