点击蓝字 关注我们
来自DataStax的首席架构师孟亚斌老师曾经做过IBM DB2数据库的引擎核心开发，目前专注于NoSQL数据库平台的咨询工作。
本文中，孟老师解释了DataStax压力测试工具NoSQLBench的核心概念，并展示了相对其它类似工具，NoSQLBench所具有的优势。
点击文末“阅读原文”观看活动录像，了解更多技术细节。
我今天向大家介绍的这个工具虽然并非是Cassandra原生包括的，但是也是一个非常有用的工具，叫做NoSQLBench。
这个工具一直被DataStax内部用来做压力测试和性能测试。从今年开始，NoSQLBench变成了开源工具，可以供社区使用。这个工具最早用于Cassandra的测试，但是时至今日，其应用范围已经慢慢扩展到更多的NoSQL数据库。
为什么要做压力测试呢？
从数据库的角度来讲，主要是有三个原因——一是评估数据库和相关系统的基准特性。二是系统容量规划。最后一点是需要评估Cassandra数据库的模型本身是否设计合理。
Cassandra这个系统也有自己的挑战。
比如修理repair和压实compaction，这些与应用程序完全无关，而是Cassandra的后台操作，而这些操作会影响应用程序的性能。如何评估这些操作的对性能的影响以及如何优化相关参数来调整性能，这些都需要一个定量的评估方式。
同样的，我们也需要考虑墓碑的影响。在Cassandra的数据被删除之后，它其实是软删除，会生成墓碑，而墓碑则会占用系统资源(比如增加修理和压实操作的工作量)。因为墓碑很消耗系统资源，我们也需要评估它带来的影响。
针对Cassandra数据模型本身，我们需要考虑定义的数据模型是否有不平衡的数据分区以及是否会造成过大的数据分区。如果有不平衡或过大的数据分区，整体的稳定性会变差，系统的性能也会受到影响。
除此之外还需要考虑的包括是否有轻量级事务、用户自定义数据类型UDT等等，这些都需要压力测试工具的评估，才能得到具体的数据。
NoSQLBench不仅仅是用于对Cassandra数据库进行压力测试的工具，而是一个专门用来对NoSQL生态系统进行系统性能测试的工具。
在NoSQLBench已经支持的系统中，核心的就是开源的Cassandra数据库和DataStax Enterprise系统，以及我们新上线的Cassandra-as-a-service的Astra云平台。
同时，NoSQLBench还支持Kafka、MongoDB、基本的TCP/IP网络流量。可以说NoSQLBench是一个非常强大的工具。
我们为什么要使用NoSQLBench呢？虽然社区中已经有不同的压力测试工具，但是NoSQLBench提供的一些功能是其它工具没有的。
首先是基于配方的程序化的数据生成和决定性的负载行为。
在很多情况下，如果我要做压力测试，我并不希望每次测试的数据都是随机的。如果数据完完全全是随机的，有可能造成两次测试的负载是不一样的。
有时我们需要在多次测试中的负载是完全一样的，这样我们才能评估不同的参数的影响并作出相应的调整。在这点上别的工具都不是很容易实现。
另外NoSQLBench不需要用户写程序，它是基于非常直观的脚本语言，所以没有太高的入门门槛。经过我今天的介绍，我相信大家基本上可以直接拿来用了。
NoSQLBench的核心概念是什么呢？它的核心概念主要分两部分：场景定义和场景执行。
在场景定义层面，所有的场景定义其实是一个yaml文件，在这个文件中需要定义几个核心概念。
一是绑定(bindings)，这是核心的数据生成的部分。二是声明(statements)，这是定义核心执行语句的部分。在Cassandra的环境下，就是CQL statements。如果你了解prepared statement，这个和CQL prepared statement非常类似。
三是区块(blocks)，它将一些绑定和声明组合在一起，是一个用于逻辑组合的部分。另外还有执行参数(parameters)和标记(tags)，能够帮助用户在运行测试时简化测试的一些元素。
在场景执行层面，我们关注的一是驱动程序/协议(driver/protocol)，比如是面向Kafka的、开源版的Cassandra，或是DataStax Enterprise的。这些就是由驱动程序和协议来定义的。
另外一个关键概念是周期(cycles)。简单来讲，如果我想测试一些数据写入，cycles定义了写入数据的量。最后是线程(threads)，它定义了有多少线程来执行测试场景。
我们需要一个场景文件，这里面包括三个phases：模型定义、热身阶段、主负载阶段。命令行像这个幻灯片里显示的这样。
比如热身阶段，你想写入一百万条记录，就把cycles设成1M (one million)。
在主负载阶段，如果你想写一亿条数据，可以设成一百条线程去写。当然，这个是在你的客户端执行的，如果你的客户端的CPU强大到可以支持一百条线程，那是最好的了，如果一个客户端没法负担这么大量的数据，可以用多个客户端来完成。
NoSQLBench本身有一些预定义的场景和负载，基本上用户不需要写场景文件。用户可以在预定义场景的基础上进行调整，这样降低了用户的入门难度。
针对运行场景，用户需要指定driver，比如Kafka、Cassandra、DSE或是HTTPS。关于驱动程序类型，用户可以使用 --list-drivers 命令来查阅目前支持的驱动程序。另外像是CQL，其实它支持非常多的次级选项，用户可以根据需求进行选择。
下面要展开讲一下NoSQLBench最核心的部分，就是数据绑定。
每一条绑定由一个绑定名和一个绑定配方组成。数据绑定是基于一个叫做虚拟数据集(virtual data)的项目。
虚拟数据集也是DataStax开发的，它能保证每次绑定都是程序化的(procedural)、决定性的(deterministic)，即每次测试的数据都可以保证是一致的。
对于PPT中的machine_id来说，它的输入流永远都是cycle_number。每次这个cycle_number会做一个mod，再经过一个hash函数生成一个UUID。
在我们的例子中，如果cycles等于10，因为mod 5，则生成的数据每五个cycle一重复。也就是说，这个数据集是有确定性的、可以精准控制的。
NoSQLBench有一些命令行输出，比如在进行压力测试时可以显示进度条，方便用户知道测试的进展状况，交互性更好。另外还可以看压力测试生成的日志文件的位置和级别，以及其中包含的错误、警告或是信息。
NoSQLBench支持不同的输出方式，有很丰富的输出指标以及选项。我个人认为，drivermetrics是最有用的选项之一，它会对连接数据库后的各种错误进行统计。
这些错误有助于用户了解Cassandra集群的工作状况。有时我们只能看到server端的指标，但是没法看到客户端的指标，而NoSQLBench可以帮助我们看到。
本文内容版权归DataStax所有
未经书面允许禁止转载
DataStax在中国
技术资讯 | 行业动态 | 活动信息
阅读这篇文章有收获？
请通过点赞、分享和在看告诉我们
