介绍HBase在taobao的使用规模，使用过程中我们碰到的问题以及我们对使用HBase的建议。

1. 毕玄

2.  Taobao HBase规模
 碰到的问题
 建议

3.  基于0.90.3；
 10个独立集群，大约300台机器；
 机器配置
 16 core，24G/48G，SATA 1T*12/SAS 300G *12；
 大约200k ops/sec，70%写，30%读。

4.  region数越来越多，写TPS会疯狂下降
 修改写操作时统计各region memstore的办法；
 解决此问题。

5.  RegionServer OOM
 太多版本；
▪ rowKey设计问题；
 通过setMaxFileSize设置了一个巨大的region文
件大小；
 HBASE-3209 & 3290 provided by Facebook；

6.  Master OOM
 region太多就会导致这个问题；
 HBASE-3906。

7.  .meta.表空洞
 我们碰到的原因
▪ split失败，不仅造成了空洞，还造成了数据丢失；
 HBASE-4562 & 4563 provided by TAOBAO

8.  .meta.表中出现了两个startKey/endKey相同
的region
 HBASE-3946
 不过我们打上patch后还是碰到了；
 这个问题非常棘手...
▪ 如何恢复？

9.  master split hlog阶段失败会造成数据丢失
 master以128M为单位读.logs，写入
recovered.edits，最后一个128M读完，会先移
动.logs到.oldlogs，此时如果写失败...
 patch暂时未提交到官方；
 Facebook也正在处理这个patch。

10.  .meta.和-root-重复分配
 HBASE-3914 & HBASE-4590

11.  如读取的数据量大，很容易造成写变慢
 原因是目前HBASE的RPC机制
 临时解决方案
▪ 读写分开；
▪ 对同一个region server也建多个连接。

12.  Jothan Gray(Facebook) said: “HBase is a pre-
1.0 DB”
 适用场景
 瞬间写入量很大，数据库不好支撑或需要很高
成本支撑的场景；
 数据需要长久保存，且量会持续增长到比较大
的场景。

13.  实践经验
 合理设计rowKey，非常重要；
 数据最好是可恢复的(Facebook也如此建议)；
 生产环境关闭split，region数不要太多(此建议
来自Facebook)。