hbase0.96版本後刪除了root 表，因為覺的目的是根據rroot表獲取meta地址，過程是通過zookeeper獲取root表地址，在根據root表記錄meta表地址進行訪問，還不如和zookeeper通訊一次。新增了namespace，詳細見patch設計（https://issues.apache.org/jira/browse/HBASE-8015）

Meta的地址存放在zookeeper的(老版本是存放在root表裡)如圖：

Meta 表結構：

每條Row記錄了一個Region的資訊。首先是RowKey，RowKey由三部分組成：TableName, StartKey 和 R

          regioninfo該列包含了META表的region資訊：region名稱、開始rowkey、結束rowkey、encode值：

         a）region名稱的組成規則：

       b）startKey，region的開始key，第一個region的startKey是空字串；

       c）endKey，region的結束key，最後一個region的endKey是空字串；

       d）encode值，該值會作為hdfs檔案系統的一個目錄，如上圖encode值為：da1aec29c13725e29786e920bcc2d7b0，存放如下如圖：

每次查詢meta表後，客戶端都有有region location info cache

下面就講講定位到region後的查詢過程，首先一個store和column family是一一對應的。每個HStore對應了Table中的一個Column Family的儲存，可以看出每個Column Family其實就是一個集中的儲存單元，因此最好將具備共同IO特性的column放在一個Column Family中，這樣最高效。什麼是相同的IO特性，其實這個是由業務決定的。

前面的大家都弄明白了吧，下面我介紹下的client與region server查詢互動過程。

1、查詢memstore[memstore是是一個按key排序的樹形結構的緩衝區]，即寫記憶體是否儲存rowkey資料，如果有就返回，沒有進行第二步查詢；

2、查詢region server的讀快取BlockCache 是否存在rowkey對應資料，如果有就返回，沒有的話就行進行第三步查詢。

3、在HFile裡面根據rowkey查詢資料，不管有沒有都返回到client。

 HFile的核心設計思想是分塊和分級[查詢速度也相對的快了]：

     查詢資料block的次數和HFile內部資料分開+索引分塊

1、bloomfilter改進查詢次數

2、hbase的三維順序，按照rowkey，column，ts進行排序，rowkey和column是升序，

ts是降序

3、對於一次隨機讀block的訪問順序是bloomblock(多次) 、indexblock(1次) 、datablock(1次)

        分塊+分級索引(RootDataIndex、 IntermediateLevel ROOT INDEX 【備選如果HFile size 過大，就啟用】、Leaf index block)

  blockCache的優化和HFile V2格式我的另外兩個部落格文章單獨介紹。

轉載請附原文連結:http://blog.csdn.net/map_lixiupeng/article/details/40857825