通過前文的描述，我們知道在hbase寫時，相同cell(rowkey/columnfamily/column相同)并不保證在一起，甚至删除一個cell也隻是寫入一個新的cell，它含有delete标記，而不一定将一個cell真正删除了，因而這就引起了一個問題，如何實作讀的問題？要解決這個問題，我們先來分析一下相同的cell可能存在的位置：首先對新寫入的cell，它會存在于memstore中；然後對之前已經flush到hdfs中的cell，它會存在于某個或某些storefile(hfile)中；最後，對剛讀取過的cell，它可能存在于blockcache中。既然相同的cell可能存儲在三個地方，在讀取的時候隻需要掃瞄這三個地方，然後将結果合并即可(merge read)，在hbase中掃瞄的順序依次是：blockcache、memstore、storefile(hfile)。其中storefile的掃瞄先會使用bloom filter過濾那些不可能符合條件的hfile，然後使用block index快速定位cell，并将其加載到blockcache中，然後從blockcache中讀取。我們知道一個hstore可能存在多個storefile(hfile)，此時需要掃瞄多個hfile，如果hfile過多又是會引起性能問題。
minor compaction是指選取一些小的、相鄰的storefile将他們合并成一個更大的storefile，在這個過程中不會處理已經deleted或expired的cell。一次minor compaction的結果是更少并且更大的storefile。（這個是對的嗎？bigtable中是這樣描述minor compaction的：as write operations execute, the size of the memtable in- creases. when the memtable size reaches a threshold, the memtable is frozen, a new memtable is created, and the frozen memtable is converted to an sstable and written to gfs. this minor compaction process has two goals: it shrinks the memory usage of the tablet server, and it reduces the amount of data that has to be read from the commit log during recovery if this server dies. incom- ing read and write operations can continue while com- pactions occur. 也就是說它将memtable的資料flush的一個hfile/sstable稱為一次minor compaction）
major compaction是指将所有的storefile合并成一個storefile，在這個過程中，标記為deleted的cell會被删除，而那些已經expired的cell會被丢棄，那些已經超過最多版本數的cell會被丢棄。一次major compaction的結果是一個hstore隻有一個storefile存在。major compaction可以手動或自動觸發，然而由于它會引起很多的io操作而引起性能問題，因而它一般會被安排在周末、淩晨等叢集比較閑的時間。
更形象一點，如下面兩張圖分别表示minor compaction和major compaction。
在hregion split後，兩個新的hregion最初會和之前的父hregion在相同的hregionserver上，出于負載均衡的考慮，hmaster可能會将其中的一個甚至兩個重新配置設定的其他的hregionserver中，此時會引起有些hregionserver處理的資料在其他節點上，直到下一次major compaction将資料從遠端的節點移動到本地節點。
當一台hregionserver當機時，由于它不再發送heartbeat給zookeeper而被監測到，此時zookeeper會通知hmaster，hmaster會檢測到哪台hregionserver當機，它将當機的hregionserver中的hregion重新配置設定給其他的hregionserver，同時hmaster會把當機的hregionserver相關的wal拆分配置設定給相應的hregionserver(将拆分出的wal檔案寫入對應的目的hregionserver的wal目錄中，并并寫入對應的datanode中），進而這些hregionserver可以replay分到的wal來重建memstore。
在nosql中，存在著名的cap理論，即consistency、availability、partition tolerance不可全得，目前市場上基本上的nosql都采用partition tolerance以實作資料得水準擴充，來處理relational database遇到的無法處理資料量太大的問題，或引起的性能問題。因而隻有剩下c和a可以選擇。hbase在兩者之間選擇了consistency，然後使用多個hmaster以及支援hregionserver的failure監控、zookeeper引入作為協調者等各種手段來解決availability問題，然而當網絡的split-brain(network partition)發生時，它還是無法完全解決availability的問題。從這個角度上，cassandra選擇了a，即它在網絡split-brain時還是能正常寫，而使用其他技術來解決consistency的問題，如讀的時候觸發consistency判斷和處理。這是設計上的限制。
從實作上的優點：
hbase采用強一緻性模型，在一個寫傳回後，保證所有的讀都讀到相同的資料。
通過hregion動态split和merge實作自動擴充，并使用hdfs提供的多個資料備份功能，實作高可用性。
采用hregionserver和datanode運作在相同的伺服器上實作資料的本地化，提升讀寫性能，并減少網絡壓力。
内建hregionserver的當機自動恢複。采用wal來replay還未持久化到hdfs的資料。
可以無縫的和hadoop/mapreduce內建。
實作上的缺點：
wal的replay過程可能會很慢。
災難恢複比較複雜，也會比較慢。
major compaction會引起io storm。
。。。。
https://www.mapr.com/blog/in-depth-look-hbase-architecture#.vdnsn6yp3qx
http://jimbojw.com/wiki/index.php?title=understanding_hbase_and_bigtable
http://hbase.apache.org/book.html
http://www.searchtb.com/2011/01/understanding-hbase.html
http://research.google.com/archive/bigtable-osdi06.pdf