打算从下面三个部分仔细了解一下HBase Region的三种操作：
Region的路由问题：
比如当你要读一个key/value的时候，你要确定它存储在哪台Region Server上面，这就涉及到region的路由问题，有一篇文章“HBase中的Client如何路由到正确的RegionServer
”已经非常详细的介绍了这部门内容，这里面就不多说了，有兴趣进入链接仔细阅读以下。
表中最主要的Family：info，info里面包含三个Column：regioninfo, server, serverstartcode。其中regioninfo就是Region的详细信息，包括StartKey, EndKey 以及每个Family的信息等等。server存储的就是管理这个Region的RegionServer的地址。
Region的分配问题：
当Region数量变多的时候，就需要把它们分配给不同的Region Server来保证每个Region Server都有事情做，但是当region数量远远大于Region Server个数的时候，就需要保证一个load balance问题，不能让一个Region Server上有大量的regions，而其他Region Server上只有几个regions，这样很可能导致负载不均衡。
关于load balance的问题可以参看我之前的一篇文章“Allow regions of specific table to be load-balanced
”，介绍了当Hbase启动的时候是如何分配region的，但是没有详细说动态分配region的问题。
hbase 0.90:
1) 启动的时候有两种策略: 一种是保持之前的regions分配情况，也就是说原来region在哪个region server上，启动的时候还是把这个region分配给这个region server；另外一种是采用round-robin方式，这样能够保证每个table里面的regions均匀分配给Region Servers，也就是这种均衡是针对的每张表。
2）目前动态分配region是由master来分配，貌似使用的是随机分配regions，所以这个是需要改进的地方!! 那到底是应该以均衡每张表为目的还是均衡负载为目的呢，当然是均衡负载，所以Jonathan Gray
打算使用cost-based的方式来分配regions，也就是把region分配给那些负载比较低的region server上面。虽然Jonathan Gray否定了使用一致性哈希，但是到底适不适合解决这个问题呢？
需要读源代码了解动态分配region，内容后续填充。。。。。。。。。
Region的拆分问题：
拆分说起来其实很简单，就是当某个HRegion下面的某个store file的大小超过了设定的max store file size，则会发生region的拆分，具体是如何拆分的需要看源代码。
内容后续填充。。。。。。。。。。
Compactions
:
When the number of StoreFiles exceeds a configurable threshold, a minor compaction is performed which consolidates the most recently written StoreFiles. A major compaction is performed periodically which consolidates all the StoreFiles into a single StoreFile. The reason for not always performing a major compaction is that the oldest StoreFile can be quite large and reading and merging it with the latest StoreFiles, which are much smaller, can be very time consuming due to the amount of I/O involved in reading merging and writing the contents of the largest StoreFile.
Compactions happen concurrently with the region server processing read and write requests. Just before the new StoreFile is moved into place, reads and writes are suspended until the StoreFile has been added to the list of active StoreFiles for the HStore and the StoreFiles that were merged to create the new StoreFile have been removed.