Hbase的数据结构及分布式策略实现

Hbase分布式策略

• 在学习Hbase之前，一定要带着一个问题，为什么Hbase比传统的关系型数据库性能要高很多？
  说到这里就不得不提Hbase的数据结构，简而言之，Hbase维护的是一个Map数据，对于每一条数据，在Hbase上都是一个独立的Map，其中有一个RowKey，然后我们的查询都是基于这个RowKey进行的，在Hbase内部，维护了一个RowKey到具体分片数据的映射，类似于查字典，Hbase Master Server维护了一个字典的目录，这样查询的时候，你只需要提供RowKey，就能知道对应的数据存储的位置。但是关系型数据库，相当于从字典的第一页，查询直到查到数据位置，所以Hbase的时间复杂度理论上是接近O(1)，而Mysql等关系型数据库尽管也通过B+树等数据结构做了优化，但是复杂度依然是O(Logn)。
  当然，Hbase的缺点也很明显，无法根据条件进行查询，不支持事物，而且也不支持数据分析（如果是聚合，统计，最好使用ES），所以说，我们在做技术选型的时候，不能一味的追求一些高大上的技术，要牢记一点，技术永远是服务于业务的，要找到合适的技术，而不是高大上的技术。
  Hbase主要的组件有：MasterServer,Zookeeper,Region Server.
  其中：
  MaserService负责表，列创建，维护集群状态
  RegionServer处理查询数据的操作，每个Region存储了Startkey-EndKey数量的数据，因为MasterServer维护了RowKey到Region的映射，因此可以很清楚的知道每一个RowKey存储在哪台RegionServer上。
  那么问题来了，Hbase是如何管理这些映射呢？
  通过下图就可以清晰的了解了，.META.表记录了Row和Region的映射关系，但是由于这个映射关系本身数据量可能很大，因此，又通过-ROOT-表来存储.META.表和Region的映射关系，而-ROOT-表要小得多，因此-ROOT-表是只有一个Region的，在Zookeeper中存储了-ROOT-表的地址

  
  
  

  image.png
  
  

  也就是说，一个Client访问HBase操作数据的时候，首先要经过Zookeeper
  查询到-ROOT-的地址，然后，查询.META.表，最后查询RegionServer，进行相应的操作，但是HBase对这些数据做了Cache，所以不需要太担心性能问题。

---