HBase在单Column和多Column情况下批量Put的性能对比分析

标签: 系统架构 | 发表时间:2014-11-29 07:28 | 作者:原 攀峰
出处:http://www.blogread.cn/it/

标签:   HBase   Put

针对HBase在单column family单column qualifier和单column family多column qualifier两种场景下,分别批量Put写入时的性能对比情况,下面是结合HBase的源码来简单分析解释这一现象。

1. 测试结果

在客户端批量写入时,单列族单列模式和单列族多列模式的TPS和RPC次数相差很大,以客户端10个线程,开启WAL的两种模式下的测试数据为例,

  • 单列族单列模式下,TPS能够达到12403.87,实际RPC次数为53次;

  • 单列族多列模式下,TPS只有1730.68,实际RPC次数为478次。

二者TPS相差约7倍,RPC次数相差约9倍。详细的测试环境这里不再罗列,我们这里关心的只是在两种条件下的性能差别情况。

2. 粗略分析

下面我们先从HBase存储原理层面“粗略”分析下为什么出现这个现象:

HBase 的KeyValue类中自带的字段占用大小约为50~60 bytes左右(参考HBase源码org/apache/hadoop/hbase/KeyValue.java),那么客户端Put一行数据时(53 个字段,row key为64 bytes,value为751 bytes):

1)  开WAL,单column family单column qualifier,批量Put:(50~60) + 64 + 751 = 865~875 bytes;

2)  开WAL,单column family多column qualifier,批量Put:((50~60) + 64) * 53 + 751 = 6793~7323 bytes。

因 此,总体来看,后者实际传输的数据量是前者的:(6793~7323 bytes) / (865~875 bytes) = 7.85~8.36倍,与测试结果478 / 53 = 9.0倍基本相符(由于客户端write buffer大小一样,实际请求数的比例关系即代表了实际传输的数据量的比例关系)。

3. 源码分析

接下来我们通过对HBase的源码分析来进一步验证以上理论估算值:

HBase客户端执行put操作后,会调用put.heapSize()累加当前客户端buffer中的数据,满足以下条件则调用flushCommits()将客户端数据提交到服务端:

1)每次put方法调用时可能传入的是一个List<Put>,此时每隔DOPUT_WB_CHECK条(默认为10条),检查当前缓存数据是否超过writeBufferSize(测试中被设置为5MB),超过则强制执行刷新;

2)autoFlush被设置为true,此次put方法调用后执行一次刷新;

3)autoFlush被设置为false,但当前缓存数据已超过设定的writeBufferSize,则执行刷新。

private void doPut(final List<Put> puts) throws IOException {
        int n = 0;
        for (Put put : puts) {
            validatePut(put);
            writeBuffer.add(put);
            currentWriteBufferSize += put.heapSize();
            // we need to periodically see if the writebuffer is full instead 
            // of waiting until the end of the List
            n++;
            if (n % DOPUT_WB_CHECK == 0
                    && currentWriteBufferSize > writeBufferSize) {
                flushCommits();
            }
        }
        if (autoFlush || currentWriteBufferSize > writeBufferSize) {
            flushCommits();
        }
    }

由上述代码可见,通过put.heapSize()累加客户端的缓存数据,作为判断的依据;那么,我们可以按照测试数据的实际情况,编写代码生成Put对象后就能得到测试过程中的一行数据(由53个字段组成,共计731 bytes)实际占用的客户端缓存大小:

import org.apache.hadoop.hbase.client.Put;
import org.apache.hadoop.hbase.util.Bytes;

public class PutHeapSize {
    /**
     * @param args
     */
    public static void main(String[] args) {
        // single column Put size
        byte[] rowKey = new byte[64];
        byte[] value = new byte[751];
        Put singleColumnPut = new Put(rowKey);
        singleColumnPut.add(Bytes.toBytes("t"), Bytes.toBytes("col"), value);
        System.out.println("single column Put size: " + singleColumnPut.heapSize());

        // multiple columns Put size
        value = null;
        Put multipleColumnsPut = new Put(rowKey);
        for (int i = 0; i < 53; i++) {
            multipleColumnsPut.add(Bytes.toBytes("t"), Bytes.toBytes("col" + i), value);
        }
        System.out.println("multiple columns Put size: " + (multipleColumnsPut.heapSize() + 751));
    }
}

程序输出结果如下:

single column Put size: 1208
multiple columns Put size: 10575

由运行结果可得到,9719/1192 = 8.75,与上述理论分析值(7.85~8.36倍)、实际测试结果值(9.0倍)十分接近,基本可以验证测试结果的准确性。

如 果你还对put.heapSize()方法感兴趣,可以继续阅读其源码实现,你会发现对于一个put对象来说,其中KeyValue对象的大小最主要决定 了整个put对象的heapSize大小,为了进一步通过实例验证,下面的这段代码分别计算单column和多columns两种情况下一行数据的 KeyValue对象的heapSize大小:

import org.apache.hadoop.hbase.KeyValue;
public class KeyValueHeapSize {
    /**
     * @param args
     */
    public static void main(String[] args) {

        // single column KeyValue size
        byte[] row = new byte[64]; // test row length
        byte[] family = new byte[1]; // test family length
        byte[] qualifier = new byte[4]; // test qualifier length
        long timestamp = 123456L; // ts
        byte[] value = new byte[751]; // test value length
        KeyValue singleColumnKv = new KeyValue(row, family, qualifier, timestamp, value);
        System.out.println("single column KeyValue size: " + singleColumnKv.heapSize());

        // multiple columns KeyValue size
        value = null;
        KeyValue multipleColumnsWithoutValueKv = new KeyValue(row, family, qualifier, timestamp, value);
        System.out.println("multiple columns KeyValue size: " + (multipleColumnsWithoutValueKv.heapSize() * 53 + 751));
    }

}

程序输出结果如下:

single column KeyValue size: 920
multiple columns KeyValue size: 10079

与前面PutHeapSize程序的输出结果对比发现,KeyValue确实占据了整个Put对象的大部分heapSize空间,同时发现从KeyValue对象级别对比两种情况下的传出数据量情况:10079/920 = 10.9倍,也与实际测试值比较接近。

4. 相关结论

经过以上分析可以得出以下结论:

  • 在实际应用场景中,对于单column qualifier和多column qualifier两种情况,如果value长度越长,row key长度越短,字段数(column qualifier数)越少,前者和后者在实际传输数据量上会相差小些;反之则相差较大。

  • 如果采用多column qualifier的方式存储,且客户端采取批量写入的方式,则可以根据实际情况,适当增大客户端的write buffer大小,以便能够提高客户端的写入吞吐量。


您可能还对下面的文章感兴趣:

  1. 使用HBase EndPoint(coprocessor)进行计算 [2014-11-27 12:58:20]
  2. HBase解决Region Server Compact过程占用大量网络出口带宽的问题 [2013-07-31 13:12:54]
  3. HBase Thrift 接口使用注意事项 [2012-12-23 23:19:41]
  4. HBase集群出现NotServingRegionException问题的排查及解决方法 [2012-12-21 13:37:58]
  5. HBase Block Cache实现机制分析 [2012-11-27 13:37:30]
  6. HBase如何合理设置客户端Write Buffer [2012-11-27 13:36:42]
  7. HBase在淘宝主搜索的Dump中的性能调优 [2012-08-05 22:46:21]
  8. (H2与HBase)面向行or面向列的存储模型? [2012-08-03 00:17:03]
  9. 一个DBA眼中的HBase [2012-06-03 14:10:01]
  10. HBase中如何开发LoadBalance插件 [2012-05-17 23:34:55]
  11. 关于HBase的一些零碎事 [2012-03-25 20:50:39]
  12. HBase性能优化方法总结 [2012-03-11 22:39:14]
  13. HBase在数据统计应用中的使用心得 [2012-01-27 18:44:39]
  14. 记录碰到的HBase问题 [2011-10-25 13:36:23]
  15. hbase运维 [2011-08-22 12:22:03]
  16. HBase随机写以及随机读性能测试 [2011-08-17 13:48:20]
  17. HBase Java客户端编程 [2011-07-24 14:59:57]
  18. 关于HBase的一些零碎事 [2011-06-20 13:41:39]
  19. HBase性能调优 [2011-06-15 14:13:05]
  20. Cassandra和HBase主要设计思路对比 [2011-06-02 23:03:08]
  21. HBase二级索引与Join [2011-06-01 13:29:51]
  22. 菜鸟谈HBase之写速度篇 [2011-05-08 22:50:26]
  23. HFile存储格式 [2011-02-28 23:15:03]
  24. hbase介绍 [2011-01-29 22:36:10]
  25. HBase技术介绍 [2011-01-18 22:18:09]

相关 [hbase column column] 推荐:

HBase在单Column和多Column情况下批量Put的性能对比分析

- - IT技术博客大学习
标签:   HBase   Put. 针对HBase在单column family单column qualifier和单column family多column qualifier两种场景下,分别批量Put写入时的性能对比情况,下面是结合HBase的源码来简单分析解释这一现象. 在客户端批量写入时,单列族单列模式和单列族多列模式的TPS和RPC次数相差很大,以客户端10个线程,开启WAL的两种模式下的测试数据为例,.

hbase介绍

- AreYouOK? - 淘宝数据平台与产品部官方博客 tbdata.org
hbase是bigtable的开源山寨版本. 是建立的hdfs之上,提供高可靠性、高性能、列存储、可伸缩、实时读写的数据库系统. 它介于nosql和RDBMS之间,仅能通过主键(row key)和主键的range来检索数据,仅支持单行事务(可通过hive支持来实现多表join等复杂操作). 主要用来存储非结构化和半结构化的松散数据.

Riak对比HBase

- - NoSQLFan
文章来自 Riak官方wiki,是一篇Riak与HBase的对比文章. Riak官方的对比通常都做得很中肯,并不刻意偏向自家产品. 对比的Riak版本是1.1.x,HBase是0.94.x. Riak 与 HBase 都是基于 Apache 2.0 licensed 发布. Riak 的实现是基于 Amazon 的 Dynamo 论文,HBase 是基于 Google 的 BigTable.

[转]HBase简介

- - 小鸥的博客
   Hbase是一个分布式开源数据库,基于Hadoop分布式文件系统,模仿并提供了基于Google文件系统的Bigtable数据库的所有功能. 其目标是处理非常庞大的表,可以用普通的计算机处理超过10亿行数据,并且有数百万列元素组成的数据表. Hbase可以直接使用本地文件系统或者Hadoop作为数据存储方式,不过为了提高数据可靠性和系统的健壮性,发挥Hbase处理大数据量等功能,需要使用Hadoop作为文件系统.

HBase表设计

- - 互联网 - ITeye博客
默认情况下,在创建HBase表的时候会自动创建一个region分区,当导入数据的时候,所有的HBase客户端都向这一个region写数据, 直到这 个region足够大了才进行切分. 一种可以加快批量写入速度的方法是通过预先创建一些空的regions,这样当数据写入HBase时,会按 照 region分区情况,在集群内做数据的负载均衡.

HBase Memstore配置

- - 行业应用 - ITeye博客
HBase Memstore配置. 本文为翻译,原英文地址:http://blog.sematext.com/2012/07/16/hbase-memstore-what-you-should-know/.     当regionserver(以下简称RS)收到一个写请求,会将这个请求定位到某个特定的region.

hbase原理

- - CSDN博客云计算推荐文章
1.hbase利用hdfs作为其文件存储系统,利用mapreduce来处理数据,利用zookeeper作为协调工具. 2.行键(row key),类似于主键,但row key是表自带的. 3.列族(column family) ,列(也称作标签/修饰符)的集合,定义表的时候指定的,列是在插入记录的时候动态增加的.

hbase锁机制

- - 数据库 - ITeye博客
博文说明:1、研究版本hbase0.94.12;2、贴出的源代码可能会有删减,只保留关键的代码.   hbase的锁是采用jdk的ReentrantReadWriteLock类实现.   一、HRegion有两种锁:lock、updatesLock,这两种锁均是ReentrantReadWriteLock类的实例,基本上所有的region操作均需要获取lock的read共享锁,在获取了lock的read锁后,如果是增加或者删除等影响数据内容的操作则还需要获取updatesLock的read锁.

Hbase入门

- - CSDN博客云计算推荐文章
Hbase 全称是Hadoop DataBase ,是一种开源的,可伸缩的,高可靠,高性能,面向列的分布式存储系统. 类似于Google的BigTable,其分布式计算采用MapReduce,通过MapReduce完成大块数据加载和全表扫描操作. 文件存储系统是HDFS,通过Zookeeper来完成状态管理协同服务.

[原]HBase StoreFile Compaction

- - 芒果先生Mango的专栏
Store File的合并策略比较复杂,涉及多个参数,合并策略的好坏,直接影响HBase的读写性能. 发现这篇博文:http://blog.csdn.net/azhao_dn/article/details/8867036 对Compaction描述的言简意赅:. hbase为了防止小文件(被刷到磁盘的menstore)过多,以保证保证查询效率,hbase需要在必要的时候将这些小的store file合并成相对较大的store file,这个过程就称之为compaction.