Hbase就不介紹了，直入正題。

為了讓客戶端找到包含特定主鍵的region，Hbase0.96之前提供了兩張特殊的目錄表-ROOT-和.META表，一下簡稱root和meta。

root表用來查詢所有meta表中熱region的位置。meta表則是用來查詢所有table的region的位置。Hbase原來的設計中只有一個root region，則root從不拆分，從而保證類似於B+樹結構的三層查詢結構：第一層是zookeeper中包含root region位置資訊的節點，第二層是從root表中查詢對應meta表的region的位置，第三層是從meta表中查詢使用者表對應region的位置。

這次不講region表的構成和怎麼查詢。

既然0.96之前是這麼做的，那為什麼只有就捨棄了呢？接下來就好好分析分析。

BigTable的論文論述了meta的region大小為128M時，可以定位2^34個region，這是怎麼計算的呢？

假設紀錄每個meta位置的一行紀錄是1kB，每個region大小是128M(實際可能更大)，那麼meta表就能紀錄128M/1kB個region，即217個，再加上root表，只有一個region，所以也是128M/1kB，這樣，一個region的root和一個region的meta，就可以定位217*217，即234個region，假設每個region128M，那麼2ZB的資料都可以定位，這個在一個HBase叢集中2ZB是不可想象的，這還是按照最小的情況。

除了三層架構定位的資料過多之外，還有網路請求的原因。

雖然客戶端快取了region的地址，但是初始化需求的時候需要重新查詢region，例如：當快取過期了，併發生了region的拆分、合併或者移動。客戶端使用遞迴查詢的方式從目錄中重新定位當前region的位置，它從對應的meta表region中查詢對應行鍵的地址。如果對應的meta的region地址無效，它就向root請求當前對應meta表的職位，最後，如果連root都沒有用了，就回向zookeeper節點查詢root表的新地址。

在最壞的情況下，客戶端需要6次網路往返請求來定位一個使用者region，這也是三層架構的一個弊端之一。

所以，在0.96之後，將root表去接去掉了，我們再來看看。

沒有了root表，直接從meta查詢，和上面條件一個，假設一個region有128M，一行地址資料1KB，那麼就可以定位128M/1kB個region，有2^24的大小，有16T，因為meta表肯定不止一個region，一個region肯定不止128M，所以，從meta來定位的資料大小遠大於16T，對於一個Hbase叢集來說，完全夠了。

而且，少了一層root，網路請求次數肯定會減少，這也是優勢之一。

二層架構的定位步驟如下：

（1）使用者通過查詢zk（zookeeper）的/hbase/meta-region-server節點查詢哪臺RegionServer上有hbase:meta表。

（2）客戶端連線含有hbase:meta表的RegionServer。Hbase:meta表儲存了所有Region的行健範圍資訊，通過這個表就可以查詢出你要存取的rowkey屬於哪個Region的範圍裡面，以及這個Region又是屬於哪個RegionServer。

（3）獲取這些資訊後，客戶端就可以直連其中一臺擁有你要存取的rowkey的RegionServer，並直接對其操作。

（4）客戶端會把meta資訊快取起來，下次操作就不需要進行以上載入HBase:meta的步驟了。