论坛编辑有问题，见博客地址：https://bbs.huaweicloud.com/blogs/23a25012a06e11e89fc57ca23e93a89f

测试HBase性能的主流工具有2种，分别是YCSB和HBase自带的PerformanceEvaluation（简称PE），2种工具的对比分析如下： 1.YCSB：最大的优势在于其支持多平台测试，当需要测试不同类型数据库性能对比时，为了统一测试工具，通常会选用YCSB 2.PE：最大的优势为HBase的原生测试工具，当HBase对客户端连接有优化时，PE会最早获得优化效果。而YCSB当前最新版本的hbase client还是基于HBase1.0.2版本，如果在1.0.2版本到1.3.0版本之间，HBase对客户端连接有相关优化时，YCSB享受不到优化效果。 至于其他的一些说法，例如： PE测试case及提供给外界的接口比YCSB更丰富，提供了RandomWrite，SequenceWrite，scan，randomSeekScan，scanRange10 ，scanRange100等说法，个人觉得其实并不准确。YCSB和PE都提供了丰富的可选配置，来模拟指定的用户业务模型。YCSB的常用配置项说明请参考：https://github.com/brianfrankcooper/YCSB/wiki/Core-Properties 那为什么2款工具在默认配置下，测试性能结果会有很大的差异，PE会明显好于YCSB呢？主要原因有2个：1.写入流程不一样，PE使用了批量写HTable.put(List)，而YCSB是使用基本的put接口。批量写最大的好处是可以减少写入时建立网络连接的次数。默认情况下，一次Put操作即要与Region Server执行一次RPC操作，其执行过程可以被拆分为以下三个部分：T1：RTT(Round-Trip Time)，即网络往返时延，它指从客户端发送数据开始，到客户端收到来自服务端的确认，总共经历的时延，不包括数据传输的时间；T2：数据传输时间，即Put所操作的数据在客户端与服务端之间传输所消耗的时间开销，当数据量大的时候，T2的时间开销不容忽略； T3：服务端处理时间，对于Put操作，即写入WAL日志（如果设置了WAL标识为true）、更新MemStore等。其中，T2和T3都是不可避免的时间开销，那么能不能减少T1呢？List put将多次Put操作打包起来一次性提交到服务端，则可以将T1部分的总时间从T1 * N降低为T1，其中T1指的是单次RTT时间，N为Put的记录条数。假设都写入N条记录，PE的RTT为T1，YCSB的RTT为T1*N可见，PE通过引入批量写入，来提升写入性能。但带来的劣势就是可靠性有所降低。 2.两种工具的默认业务模型不一样我们以100%insert场景来说明该问题： 测试过程： 1.使用YCSB和PE分别**10000行数据，每行数据1000B 2.扫描**数据，结果如下： YCSB**数据的scan结果 PE**数据的scan结果： 可以看到，二者的默认数据模型有很大差异： YCSB：1行有1个ColumnFamily，包含了10个Column，每个Column长度为100B。 PE：1行有1个ColumnFamily，包含了1个Column，每个Column长度为1000B。 这种情况下，YCSB没**1行数据，需要调用10次put kv的操作，而PE只需要调用1次，这应该就是测试相同集群时，PE性能明显优于YCSB的原因。 那么，有没有办法让二者的数据模型保持一致呢？ 答案是肯定的，YCSB和PE都提供了灵活的接口来重新定义数据模型，例如： YCSB通过指定fieldlength和fieldcount分别指定column大小和column数量 PE也可以通过column参数指定column数量 总结： YCSB和PE都是优秀的性能测试工具，对于对比测试来说，只有统一测试工具和数据模型、业务模型才能测出有意义的对比数据。跨平台测试优先选择YCSB，只针对HBase进行测试，二者都可选，但PE相对简单，上手速度更快。

本帖最后由 JaisonSnow 于 2018-2-26 17:48 编辑本文首发于：NoSQL漫谈(nosqlnotes.com)：关于Bigtable在近些年做了哪些演进，只能从Cloud Bigtable的官方资料中一探究竟。在详细的分析了Cloud Bigtable的官方资料之后，遗憾的发现，除了云服务本身所需要的一些基础能力，以及为了吸引HBase存量用户而做的HBase接口兼容性工作以外，其它的Features可谓是“捉襟见肘”。曾经的规划在Bigtable论文中，曾提及当时团队成员正忙于二级索引以及跨集群容灾特性的开发：We are in the process of implementing several additional Bigtable features, such as support for secondary indices and infrastructure for building cross-data-center replicated Bigtables with multiple master replicas.直到今天我们所看到的Cloud Bigtable，也未见到这两个特性，猜测当时的部分团队成员已经转向Megastore的开发，或者后来发现这些能力放在一个上层系统中更加合适：[*]在Bigtable中实现二级索引，无非是在现有的Key-Value的接口基础上实现增量。[*]如要支持跨集群容灾能力，在当前架构下，可基于WAL日志的异步复制方案来实现。如构建同步容灾方案，对当前的架构提出了非常大的挑战。这些能力本身已涵盖在Megastore的设计中，所以干脆放弃在Bigtable中支持这些能力，这样还可以继续保持其系统的精简性。Cloud Bigtable与HBaseCloud Bigtable的官方资料中，HBase接口被暴露在最显眼的位置，纵观整个资料上下文，也可以发现HBase的身影“处处可见”。HBase的实现基本上参考了Bigtable论文中的设计，但Bigtable如果介绍一套崭新的接口所需要付出的代价可想而知，所以不得不依靠兼容HBase接口来吸纳更多的用户，可以理解这其中有多少不得已的“苦衷”。相信在很多年前，Google内部关于Bigtable是否开源就已经做过不少讨论，但这是一个“牵一发而动全身”的动作，因为Bigtable用到了很多Google内部的组件。从接口能力上，可以简单对比出来Bigtable与HBase的一些异同：[*]Column Family的可配置参数[*]ACL控制的粒度[*]Reverse Scan能力[*]支持的Filter种类[*]Coprocessor/Snapshot/Namespace/Procedure等高级特性[*]集群管理/表管理接口在后面的文章中将会再给出Bigtable与HBase的详细对比分析。Bigtable在请求时延上的优化从2015年Cloud Bigtable刚刚开放公测时，他们的工程师曾发表过一篇博客文章：Announcing Google Cloud Bigtable这篇文章重点在写吞吐以及P99读写时延方面与HBase/Cassandra做了对比：可以看出，无论是在吞吐量以及P99 Read/Write Latency方面，Bigtable都有显著的优势。虽然近几年HBase在性能上已经取得了不少改进，在P99读写时延方面的确比较诟病，主要受限于底层的HDFS能力。Jeff Dean在2014年的一个演讲(Achieving Rapid Response Times in Large Online Services)中，曾提到Bigtable在读写时延优化方面所做的一些工作，一些关键点包括：[*]Request Adaptation 基于最近的一些读取时延统计来做出一些预判来改善接下来的读取请求时延[*]Backup Request 原理很简单，当某个副本查询响应超出一定时间之后立马将请求发送至另外一个副本，这样可有效降低时延毛刺，类似技术如DistributedLog中的Speculative Read以及HDFS的Hedged Read特性。其它Cloud Bigtable支持多语言客户端，以及与Google Cloud服务的一些对接，都可归类于云服务基础能力，本文不作过多的展开。写在最后与HBase的活跃社区相对比，Bigtable在近些年的发展似乎非常缓慢。一个闭源技术，如不是战略级产品，公司就难有坚定的投入，最后的结局似乎都可预见…..Reference[*]https://cloud.google.com/bigtable/[*]https://conferences.oreilly.com/velocity/velocity2014/public/schedule/detail/34266[*]https://cloudplatform.googleblog.com/2015/05/introducing-Google-Cloud-Bigtable.html声明：本文仅代表个人观点本文首发于：NoSQL漫谈(nosqlnotes.com) 永久链接：Bigtable在近些年的演进