Hbase分布式策略

• 在學(xué)習(xí)Hbase之前，一定要帶著一個(gè)問題，為什么Hbase比傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)性能要高很多？
  說到這里就不得不提Hbase的數(shù)據(jù)結(jié)構(gòu)，簡(jiǎn)而言之，Hbase維護(hù)的是一個(gè)Map數(shù)據(jù)，對(duì)于每一條數(shù)據(jù)，在Hbase上都是一個(gè)獨(dú)立的Map，其中有一個(gè)RowKey，然后我們的查詢都是基于這個(gè)RowKey進(jìn)行的，在Hbase內(nèi)部，維護(hù)了一個(gè)RowKey到具體分片數(shù)據(jù)的映射，類似于查字典，Hbase Master Server維護(hù)了一個(gè)字典的目錄，這樣查詢的時(shí)候，你只需要提供RowKey，就能知道對(duì)應(yīng)的數(shù)據(jù)存儲(chǔ)的位置。但是關(guān)系型數(shù)據(jù)庫(kù)，相當(dāng)于從字典的第一頁(yè)，查詢直到查到數(shù)據(jù)位置，所以Hbase的時(shí)間復(fù)雜度理論上是接近O(1)，而Mysql等關(guān)系型數(shù)據(jù)庫(kù)盡管也通過B+樹等數(shù)據(jù)結(jié)構(gòu)做了優(yōu)化，但是復(fù)雜度依然是O(Logn)。
  當(dāng)然，Hbase的缺點(diǎn)也很明顯，無(wú)法根據(jù)條件進(jìn)行查詢，不支持事物，而且也不支持?jǐn)?shù)據(jù)分析（如果是聚合，統(tǒng)計(jì)，最好使用ES），所以說，我們?cè)谧黾夹g(shù)選型的時(shí)候，不能一味的追求一些高大上的技術(shù)，要牢記一點(diǎn)，技術(shù)永遠(yuǎn)是服務(wù)于業(yè)務(wù)的，要找到合適的技術(shù)，而不是高大上的技術(shù)。
  Hbase主要的組件有：MasterServer,Zookeeper,Region Server.
  其中：
  MaserService負(fù)責(zé)表，列創(chuàng)建，維護(hù)集群狀態(tài)
  RegionServer處理查詢數(shù)據(jù)的操作，每個(gè)Region存儲(chǔ)了Startkey-EndKey數(shù)量的數(shù)據(jù)，因?yàn)镸asterServer維護(hù)了RowKey到Region的映射，因此可以很清楚的知道每一個(gè)RowKey存儲(chǔ)在哪臺(tái)RegionServer上。
  那么問題來(lái)了，Hbase是如何管理這些映射呢？
  通過下圖就可以清晰的了解了，.META.表記錄了Row和Region的映射關(guān)系，但是由于這個(gè)映射關(guān)系本身數(shù)據(jù)量可能很大，因此，又通過-ROOT-表來(lái)存儲(chǔ).META.表和Region的映射關(guān)系，而-ROOT-表要小得多，因此-ROOT-表是只有一個(gè)Region的，在Zookeeper中存儲(chǔ)了-ROOT-表的地址

  
  
  image.png
  
  

  也就是說，一個(gè)Client訪問HBase操作數(shù)據(jù)的時(shí)候，首先要經(jīng)過Zookeeper
  查詢到-ROOT-的地址，然后，查詢.META.表，最后查詢RegionServer，進(jìn)行相應(yīng)的操作，但是HBase對(duì)這些數(shù)據(jù)做了Cache，所以不需要太擔(dān)心性能問題。