1、使用bloomfilter和mapfile_index_interval
| Bloomfilter(开启/未开启=1/0) | mapfile_index_interval | Exists(0-10000)/ms | Get(10001 - 20000)/ms |
| 0 | 128 | 22460 | 23715 |
| 0 | 0 | 11897 | 11416 |
| 0 | 64 | 13692 | 14034 |
| 1 | 128 | 3275 | 3686 |
| 1 | 64 | 2961 | 3010 |
| 1 | 0 | 3339 | 3498 |
| 测试环境为:单机,规模为10万条数据。随机在10000条数据中有99条存在的情况下。 | |||
| 结论：开启bloomfilter比没开启要快3、4倍。而适当的减少mapfile_index_interval可以提升性能 |
注意：在1.9.3版本的hbase中，bloomfilter是不支持的，存在一个bug，可以通过如下的修改加以改正：
(1)、在方法org.apache.hadoop.hbase.regionserver.HStore.createReaders()中，找到如下行
BloomFilterMapFile.Reader reader = file.getReader(fs, false, false);
将其改成
BloomFilterMapFile.Reader reader = file.getReader(fs, this.family.isBloomfilter(), false);
(2)、在方法org.apache.hadoop.hbase.HColumnDescriptor.toString()中，找到如下的代码行
if (key != null && key.toUpperCase().equals(BLOOMFILTER)) {
// Don't emit bloomfilter. Its not working.
continue;
}
将其注释掉
2、hbase对于内存有特别的嗜好，在硬件允许的情况下配足够多的内存给它。
通过修改hbase-env.sh中的
export HBASE_HEAPSIZE=3000 #这里默认为1000m
3、修改java虚拟机属性
(1)、在环境允许的情况下换64位的虚拟机
(2)、替换掉默认的垃圾回收器，因为默认的垃圾回收器在多线程环境下会有更多的wait等待
export HBASE_OPTS="-server -XX:NewSize=6m -XX:MaxNewSize=6m -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode"
4、增大RPC数量
通过修改hbase-site.xml中的
hbase.regionserver.handler.count属性，可以适当的放大。默认值为10有点小
5、做程序开发是注意的地方
(1)、需要判断所求的数据行是否存在时，尽量不要用HTable.exists(final byte [] row) 而用HTable.exists(final byte [] row, final byte[] column)等带列族的方法替代。
(2)、不要使用HTable.get(final byte [] row, final byte [] column) == null来判断所求的数据存在，而是用HTable.exists(final byte [] row, final byte[] column)替代
(3)、HTable.close()方法少用.因为我遇到过一些很令人费解的错误
6、记住HBase是基于列模式的存储，如果一个列族能搞定就不要把它分开成两个，关系数据库的那套在这里很不实用.分成多个列来存储会浪费更多的空间，除非你认为现在的硬盘和白菜一个价。
7、如果数据量没有达到TB级别或者没有上亿条记录，很难发挥HBase的优势，建议换关系数据库或别的存储技术。
