在  中，  介绍了 HBase 的一个新特性 Counter Increment，即把一个 column 当作 一个 counter，这样便于给某些在线应用提供实时统计功能。（PS：比如帖子的实时浏览量：PV）

传统上，如果没有 counter，当我们要给一个 column 的值 +1 或者其他数值时，就需要先从该 column 读取值，然后在客户端修改值，最后写回给 Region Server，即一个 Read-Modify-Write (RMW) 操作。在这样的过程中，按照 Lars 的描述，还需要对操作所在的 row 事先加锁，事后解锁。这会引起许多 contention，以及随之而来的很多问题。而 HBase 的 increment 接口就保证在 Region Server 端原子性的完成一个客户端请求。

至于 increment 的性能如何，我们只有做测试才能知道。 已经提供了 Read-Modify-Write 的测试接口，而 increment 接口需要自己完成。

recordcount=12000

operationcount=12000000

workload=com.yahoo.ycsb.workloads.CoreWorkload

readallfields=false

incrementproportion=1

readproportion=0

updateproportion=0

scanproportion=0

insertproportion=0

requestdistribution=zipfan

recordcount=12000

operationcount=12000000

workload=com.yahoo.ycsb.workloads.CoreWorkload

readallfields=false

readproportion=0

updateproportion=0

scanproportion=0

insertproportion=0

readmodifywriteproportion=1

requestdistribution=zipfan

测试放在集群上进行：1台 master，6台 regionserver，独立的 zookeeper 集群；底层 HDFS 与 HBase 重叠。当前每个 Region Server 负责 255 左右的 region。YCSB 在另一台机器上，开 120 个线程。测试结果如下。

首先看 throughput：

测试图说明测试的时间基本上已经足够长，性能的波动也有反映出来。RMW 虽然波动较大，但总体性能居然优于 Increment，这是比较意外的事情。而 Increment 的表现非常稳定。从箱线图的角度来看也一致。Latency 的情况类似。

最后对测试结果做下简单的分析。出乎意料，RMW 没有想象的那么差，不过中间波动的情况值得深究一下；Increment 的平均 latency 在 10ms 左右，比 RMW 的 15ms 要好，而且几乎没有性能波动现象。

仔细分析 YCSB 的 RMW 操作的代码，它其实只是简单的将 read() 和 update() 封装起来：

db.read (table,keyname,fields, new HashMap < String,String > ( ) ) ; db.update (table,keyname,values ) ;

它并没有对所操作的 row 进行加锁、解锁操作，而是简单的读取改写。这在 counter 的应用场景中是不可接受的。不加锁在大并发情况下，很容易导致 counter 的值与预期不符。

继续修改 YCSB，由发起请求的客户端对相应的 row 加锁。之后再进行 Increment 与 RMW 之间的性能比较。

可以预期的是新的 RMW 的性能会非常的差。这里给个测试结果的片段：

200 sec: 15818 operations; 91.3 current ops/sec; [RMW AverageLatency(ms)=2903.83]

210 sec: 15818 operations; 0 current ops/sec;

220 sec: 15818 operations; 0 current ops/sec;

230 sec: 16880 operations; 106.2 current ops/sec; [RMW AverageLatency(ms)=3136.13]

240 sec: 16880 operations; 0 current ops/sec;

250 sec: 16880 operations; 0 current ops/sec;

260 sec: 17747 operations; 86.69 current ops/sec; [RMW AverageLatency(ms)=4262.21]

270 sec: 17747 operations; 0 current ops/sec;

280 sec: 17747 operations; 0 current ops/sec;

290 sec: 18412 operations; 66.5 current ops/sec; [RMW AverageLatency(ms)=5508.39]

在这里修改 RMW 中的关键代码在于：

lock  = _hTable.lockRow (Bytes.toBytes (key) ) ; r  = _hTable.get (g ) ; _hTable.put (p ) ; _hTable.unlockRow (lock ) ;

即在读之前先加锁，写之后放锁。之前的 RMW 的瓶颈在 Read 操作，并且 put 操作可以在 server 端批处理；而这里，锁的引入导致线程间的 contention 陡增。也就是说，线程数量的增加不一定会带来性能的提升，可能反而使性能变差。我们可以以线程数为变量做些测试（以 100s 为限）。

可以看到当线程数超过 16 之后，throughput 反而稍微变差了，更糟糕的是，latency 大幅度的提升。当线程数定在 128 时，情况就变的非常糟糕：latency 基本上是几秒，或者 NA；而 throughput 只能维持在 200 左右。这验证了之前的想法。

所以 HBase 引入 Increment/Counter 是非常重要的，对某些需要原子性更改操作的应用来说则是“致命”的。除了单个 increment 的接口 incrementColumnValue() 外，还有批量 increment 的接口increment(Increment)，方便客户端调用。

除此之外，HBase 还在进行  的开发，使计算直接在 Region Server 上进行，省去了繁琐耗时的数据移动。（PS：这就是所谓的移动计算比移动数据更划算）

Tips：以上测试数据由于 Hbase 版本很老，加上作者硬件、集群规模限制，仅供参考~

Refer：