簡介
HBase是模仿google bigtable的開源產品，又是hadoop的衍生品，hadoop作爲離線計算系統已經得到業界的普遍認可，並經過N多公司大規模使用的驗證，自然地認爲Hbase也將隨之獲得成功。
《HBase: The Definitive Guide》第8章講述hbase的架構，從架構上看，其架構很完美：
- LSM - 解決磁盤隨機寫問題(順序寫纔是王道)；
- HFile - 解決數據索引問題(只有索引才能高效讀)；
- WAL - 解決數據持久化(面對故障的持久化解決方案)；
- zooKeeper - 解決核心數據的一致性和集羣恢復；
- Replication - 引入類似MySQL的數據複製方案，解決可用性；
此外還有：自動分拆Split、自動壓縮(compaction,LSM的伴生技術)、自動負載均衡、自動region遷移。
HBase的一致性
關於HBase的一致性模型，衆說紛紜，到底是強一致性還是最終一致性，還需要多瞭解一下，這裏不做討論。但是有一點可以確認的是對於單行鍵，具有秒級別的讀寫性能（強一致性？？？）
------------updated 2015-01-14------------------
HBase具有單行寫入的強一致性
HBase運算有多快
定義一些變量：
- n = 表中KeyValue條目數量（包括Put的結果和Delete留下的墓碑標示）；
- b = HFile裏數據塊（HFile Block）的數量；
- e = 平均一個HFile裏KeyValue條目的數量（如果知道行的大小，可以計算得到）
- c = 每行裏列的平均數量
注意，這是在單列族語境中討論這一點。
先來定義針對指定行健查找相關HFile數據塊需要的時間。無論是你在單行上執行get()命令，還是爲一次掃描查找起始鍵，都會有這個動作。
第一步，客戶端尋找正確的RegionServer和region。花費3次固定預算找到正確的region——查找ZK，查找--ROOT--， 查找.META.。這是一次O(1)運算。
在指定的region上，行在讀過程裏可能存在於兩個地方：如果還沒有刷寫到硬盤就位於MemStore，如果已經刷寫則位於一個HFile裏。簡化起見，我們假設只有一個HFile，這一行要門在這個文件裏，要麼還沒刷寫，在MemStore裏。
讓我們用 e 合理代表指定時間在MemStore裏的條目數量。如果一行在MemStore裏，因爲MemStore是使用SkipList實現的，所以查找行的時間複雜度是O(log e)。如果一行已經刷寫到硬盤上，需要找到正確的HFile數據塊。數據塊索引是排過序的，所以查找正確的數據塊是一次時間複雜度爲O(log b)的運算。查找行裏KeyValue對象是在數據塊裏的一次線性掃描操作。在你找到第一個KeyValue對象後，隨後查找剩下的對象就是一次線性掃描。假設行裏的單元都在同一個數據塊裏，掃描的時間複雜度是O(e/b)。如果行裏的單元不在同一個數據塊裏，這種掃描需要訪問多個連續數據塊裏的數據，所以這時的運算由讀取的行數決定，其時間複雜度是O(c)。也就是說，這種掃描的時間複雜度是O(max(c,
e/b)).
總之，查找某一行的開銷如下所示：
O(1) 用於查找region
+ O(log e)用來在MemStore裏定位KeyValue，如果它還在MemStore裏；
或者O(1)用來查找region
+ O(log b) 用來在HFile裏查找正確的數據塊
+ O(max(c, e/b))用來查找掃描的決定性部分，如果它已經刷寫到硬盤上了
在訪問HBase中的數據時，決定性因素是掃描HFile數據塊找到相關KeyValue對象所花費的時間。如果使用寬行，這會在掃描過程中增加處理整行的開銷。所有這些分析，都假設知道要查找的行的行健。
如果不知道行健，你需要掃描整個區間（可能是整張表）來查找你關心的行，這個時間複雜度是O(n)。在這樣的情況下，你將不再有益於把掃描限定在若干Hfile數據塊裏。
這裏沒有討卵硬盤尋道開銷。如果要從HFile裏讀取的數據已經被加載進數據塊緩存，前面的分析是正確的。如果數據還需要從HDFS讀到數據塊緩存，從硬盤讀取數據的開銷會增加很多，從學術上將這種分析已經沒有意義。
因爲行健是所有這些索引的決定性因素，所以結論是訪問寬行要比訪問窄行開銷大。如果知道行健，按照HBase建立索引的內部工作原理，你會從中得到很大好處。
reference
1、HBase權威指南
2、HBase實戰
