HBase写的初步测试中的表现

第四年HBase。在上线的机HBase集群做一个初步的测试写入性能。下面具体说明做测试内容。

说明

HBase周围环境

0.96版本号,8台region server。默认配置

写数据说明

单column family。两个column qualifier的值为字符串+随机8位正整数,Row Key为两个quailifer值相连后串上随机Long

比方:val1 = dd1977285, val2 =cc6549921, rowkey = rondom.nextLong() + val1 + val2

測试涵盖到的维度

单线程、多线程比較

Rowkey不hash、Rowkey MD5 Hash (hash后每份rowkey等长,分发Region Server时随机性更好)

单Put写(每次Put一次RPC)、批量写(带write buffer的刷写)

批量写情况下write buffer的大小设置

測试未涵盖到的维度

WAL是开启的(线上应用不推荐关闭WAL来换取写速度)

备份数没有改(3份)

每台Region Server的RPC handler数目没有设定(本次单机測试中,RPC响应肯定不会是瓶颈)

没有使用压缩(数据量小)

没有比較ColumnQualifier数目增长

关于Region Server很多其它的系统设置都是默认的(请求数分布、region文件块大小设置及Compaction影响、Split文件数阀值等等)

结果

測试结果比較:

HBase写的初步测试中的表现

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvcGVsaWNr/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="" />

总结

批量写性能提升不少

线上应用最好是禁用buffer刷写功能的。即每个Put一次RPC写。只是看到这样的情况下写速度慢。考虑到机器、网络环境的区别的话。预计能上1K

启用buffer刷写功能的话,要避免未flush的put记录丢失。(HTable在close的时候最后是会自己主动flush,我们在写服务节点故障的时候也须要flush一次)

Rowkey哈希后性能有小量提升

Rowkey Hash之后对写性能的确有小量提升,但假设要基于rowkey做范围查找的话,rowkey可能不适合hash,具体看业务场景再考虑。

单线程每秒上万行写能力

本机上单线程在开启writerbuffer刷写后,每秒写行数轻松上万。

多线程下,本机上每个线程最多到每秒7K行的速度,相信考虑到机器、网络环境的区别的话,也能上万。

并发写能力乐观

本机没有模拟到多个节点上百线程的并发写场景。只是依据前一点看的话,还是乐观的。并且本次測试的集群级别的设置都是默认的,集群规模也一般,有非常多集群级别的优化手段。

等项目开发到一定阶段时候,会測试多节点上百线程并发写的场景,且依据对HBase逐步的了解,之后会有很多其它经验,相关測试报告再具体产出,这份初步的測试就大致先了解下。

掌声 :)

版权声明:本文博主原创文章,博客,未经同意不得转载。

上一篇:caffe初试(一)happynear的caffe-windows版本的配置及遇到的问题


下一篇:【2017-05-05】timer控件、三级联动、帐号激活权限设置