[TOC] # 讀寫過程 ## 讀請求過程： 1. 客戶端通過zookeeper以及root表和meta表找到目標數據所在的regionserver 2. 聯系regionserver查詢目標數據 3. regionserver定位到目標數據所在的region，發出查詢請求 4. region先在memstore中查找，命中則返回 5. 如果在memstore中找不到，則在storefile中掃描（**可能會掃描到很多的storefile----bloomfilter**） 布隆過濾器參數類型有2種:Row,column+row ## 寫請求過程： 1. client向region server提交寫請求 2. region server找到目標region 3. region檢查數據是否與schema(表描述信息)一致 4. 如果客戶端沒有指定版本，則獲取當前系統時間作為數據版本 5. 將更新寫入WAL log 6. 將更新寫入Memstore 7. 判斷Memstore的是否需要flush為Store文件。 # 細節描述 hbase使用MemStore和StoreFile存儲對表的更新。 數據在更新時首先寫入Log(WAL log)和內存(MemStore)中，MemStore中的數據是排序的，當MemStore累計到一定閾值時，就會創建一個新的MemStore，并 且將老的MemStore添加到flush隊列，由單獨的線程flush到磁盤上，成為一個StoreFile。于此同時，系統會在zookeeper中記錄一個redo point，表示這個時刻之前的變更已經持久化了。 當系統出現意外時，可能導致內存(MemStore)中的數據丟失，此時使用Log(WAL log)來恢復checkpoint之后的數據。 **StoreFile是只讀的，一旦創建后就不可以再修改。因此Hbase的更新其實是不斷追加的操作。當一個Store中的StoreFile達到一定的閾值后，就會進行一次合并(minor_compact, major_compact),將對同一個key的修改合并到一起，形成一個大的StoreFile，當StoreFile的大小達到一定閾值后，又會對 StoreFile進行split，等分為兩個StoreFile** 由于對表的更新是不斷追加的，compact時，需要訪問Store中全部的 StoreFile和MemStore，將他們按row key進行合并，由于StoreFile和MemStore都是經過排序的，并且StoreFile帶有內存中索引，合并的過程還是比較快。