较少的 IO 线程，适用于处理单次请求内存消耗较高的 Big PUT 场景（大容量单
次 PUT 或设置了较大 cache 的 scan，均属于 Big PUT）或 ReigonServer 的内存
比较紧张的场景。
较多的 IO 线程，适用于单次请求内存消耗低，TPS 要求非常高的场景。设置该
值的时候，以监控内存为主要参考。
这里需要注意的是如果 server 的 region 数量很少，大量的请求都落在一个
region 上，因快速充满 memstore 触发 flush 导致的读写锁会影响全局 TPS，不
是 IO 线程数越高越好。
压测时，开启 Enabling RPC-level logging，可以同时监控每次请求的内存消耗
和 GC 的状况，最后通过多次压测结果来合理调节 IO 线程数。
这里是一个案例 Hadoop and HBase Optimization for Read Intensive Search
Applications，作者在 SSD 的机器上设置 IO 线程数为 100，仅供参考。
hbase.hregion.max.filesize
默认值：256M
说明：在当前 ReigonServer 上单个 Reigon 的最大存储空间，单个 Region 超过
该值时，这个 Region 会被自动 split 成更小的 region。
调优：小 region 对 split 和 compaction 友好，因为拆分 region 或 compact 小
region 里的 storefile 速度很快，内存占用低。缺点是 split 和 compaction 会
很频繁。
特别是数量较多的小 region 不停地 split, compaction，会导致集群响应时间
波动很大，region 数量太多不仅给管理上带来麻烦，甚至会引发一些 Hbase 的
bug。
一般 512 以下的都算小 region。
大 region，则不太适合经常 split 和 compaction，因为做一次 compact 和 split
会产生较长时间的停顿，对应用的读写性能冲击非常大。此外，大 region 意味
着较大的 storefile，compaction 时对内存也是一个挑战。
当然，大 region 也有其用武之地。如果你的应用场景中，某个时间点的访问量
较低，那么在此时做 compact 和 split，既能顺利完成 split 和 compaction，
又能保证绝大多数时间平稳的读写性能。
既然 split 和 compaction 如此影响性能，有没有办法去掉？
compaction 是无法避免的，split 倒是可以从自动调整为手动。
只要通过将这个参数值调大到某个很难达到的值，比如 100G，就可以间接禁用
自动 split（RegionServer 不会对未到达 100G 的 region 做 split）。
再配合 RegionSplitter 这个工具，在需要 split 时，手动 split。
