选择NoSQL内存解决方案：性能测试实践

Posted 2021-05-01 小象

译者：孙薇

原文链接：http://highscalability.com/blog/2015/12/30/how-to-choose-an-in-memory-nosql-solution-performance-measur.html

小象科技原创作品，欢迎大家疯狂转发；

机构、自媒体平台转载务必至后台留言，申请版权。

这项工作主要是为了展示用YCSB对一些顶尖内存NoSQL数据库进行测试的结果。

我们选择了三种普及度最高的内存数据库管理系统：Redis（下载版，云服务版被称为Azure Redis缓存），Tarantool和CouchBase，外加缓存系统Memcached。Memcached并不是数据库管理系统，无法访问持久性数据资源，不过由于被广泛用于高速存储，我们决定将这个系统也列进来。我们的“演习场地”是位于Microsoft Azure Cloud上的一组虚拟机，它们彼此紧邻，就在同一个数据中心里。为了降低网络延迟对测试的影响，这种做法十分必要。这些虚拟机的镜像可点击下载：一、二、三、四（登录：nosql；密码：qwerty）。一对虚拟机（nosql-1和nosql-2）适用于Tarantool和CouchBase系统，另一对虚拟机（nosql-3和nosql-4）适合Redis、Azure Redis Cache和Memcached。镜像中安装配置了数据库与测试。

虚拟机配置：标准A3，4核，7G内存，120G硬盘。

1

数据库及配置

内存NoSQL数据库管理系统会将所有数据放到主存储中，在硬盘上维护更新。持久化通过将每个数据修改请求都保存到二进制日志中来实现，鉴于日志以append-only模式记录，几乎没什么瓶颈。读写的工作量都不会带来太大的磁头移动。

从2009年Salvatore Sanfilippo发布Redis之后，现在的最新版是3.0.5版。 我们为Redis 3.0.4版本提供了2个配置文件，用append-only文件保证持久性，不具备缓存服务器之类，Redis从源打包构建。

我们还用到了Microsoft Azure Redis缓存，它是由微软所管理的，基于Redis的云服务。 Tarantool是开源NoSQL数据库管理系统，由my.com开发的Lua应用服务器。

Tarantool的首个版本于2008年发布，最新版本号为1.6.7。 我们为Tarantool 1.6.7-126-gb35aff9提供了4个配置文件，有两个采用了预写式日志，另两个则没有用到，而是采用了树索引（有序）和哈希索引（无序）。在Tarantool中没有调整选项存在，也没有执行调整。

Memcached是通用型分布式内存缓存系统，于2003年开发。Memcached没有任何数据持久化模式，因此只能与其他未配置append-only二进制日志的数据库一同测试。我们使用了Memcached1.4.14-0ubuntu9，下载自Ubuntu资源库。

Couchbase服务器最初被叫做Membase，它也是开源的分布式NoSQL文档数据库。最新稳定发布版是4.0版本。

我们使用的是从官网下载的Couchbase 4.0.0-4047-1，未加任何额外配置。 Redis的append-only文件与Tarantool的预写式选项为现有数据库提供持久化服务。在本文中，仅记录了不同数据库的类似配置之间的比较。也就是说，像开启append-only文件的Redis，和未开启预写式日志的Tarantool之间的比较未被列入。

2

Yahoo!

Cloud Serving Benchmark

（YCSB）

YCSB是雅虎所开发的工具，功能十分强大，用于测试各类NoSQL数据库的性能，包括内存与硬盘。YCSB可以针对NoSQL数据库的性能进行测试，这也是我们选择它的原因。YCSB中包含了Redis和Tarantool的驱动，而我们根据spymemcached库创建了Memcached的驱动。点击这里下载YCSB源。 YCSB自带库中的核心workload type配置文件很少，只有6种主要的，分别被命名为workload A到F。

Workload A是更新量巨大的类型，50/50的读写；应用案例是存有近期执行的session。Workload B主要是读入负载，读写分别为95/5；应用案例是照片标签：添加标签属于更新，但大多操作只是读标签。Workload C是100%读入，应用案例是用户资料缓存：资料在别处构建（比如Hadoop中）；Workload D是插入新纪录，最受欢迎的是最新插入的记录。应用案例是用户状态更新：用户想要阅读最新的那些。Workload E则是小范围记录查询，用以取代逐个记录的查询。应用案例是线程式会话：每次都在给定的线程中查找相关内容（假设按线程id分组）。在Workload F中，客户端读取、修改记录，并传回变更。应用案例是用户数据库：读取用户记录，由用户修改或者记录用户行为。

我们在每个配置文件中修改了两个参数：recordcount改为2000000，operationcount改为5000000。YCSB支持多线程工作，我们同时开启了8, 16, 32, 64, 128, 256个线程。

下面会展示一些我们所制的图示，点击这里下载图示脚本源。

图示

Tarantool (HASH)：深蓝

Tarantool (TREE)：浅蓝

Redis：红色

Azure Redis Cache：橙色

Memcached：绿色

CouchBase：灰色

在所有调查到的workload中，Tarantool（hash与tree索引的）都是最高的，它创造了一种无锁内存引擎，不包含任何互斥器（mutexes）、其他并发原语（concurrency primitives），且使用了协同式多任务处理机制。根据这些图表，我们可以得出结论：高吞吐量是Tarantool数据库的优势之一。

Tarantool的设计也优化了读取请求，达到最小平均延时。如图表所见，任何workload都是如此。在95%的请求中，Tarantool达到了最低延迟。（这种测量方式与平均延迟有关，但并不相同）。但是，在速度最快的请求中Tarantool有99%并未达到最低延迟。也就是说，Tarantool在大多情况下性能与Redis很接近，但是其中一些不如Redis。可以这样描述：Tarantool执行查询时，部分延迟很低，另外的延迟很高，而Redis在执行所有请求时，延迟均属中等。

在未开启预写式日志的案例中，Memcached和Couchbase在延迟方面表现更优。如果按平均延迟以及按第95百分位计算，任何情况下Tarantool都要优过Redis，但如果按第99百分位计算则不然。读取延迟的情况也是类似的。

在插入请求，以及未开启预写式日志的情况下，如果按平均延迟以及按第95百分位计算，Memcached和Couchbase的表现要优于其他系统，但如果按第99百分位计算的话，结果却完全相反——配上Azure Redis缓存之后，所提供的性能都不如其他数据库。

在这种情况下（Read-Modify-Write），如果按平均延迟以及按第95百分位计算，Tarantool再次优于Redis，而按第99百分位计算的话也非常接近Redis的性能。

3

结论

我们对YCSB进行了描述，并提供了四种主流数据库的对比结果，不过本文最重要的目的是为了解决如何为当前workload选择正确解决方案的问题。通过本文中的图表，很容易根据workload type、数据库客户端数量以及使用者的预期，来找出最合适的解决方案。

我们的虚拟机镜像、安有Memcached模块与R语言脚本的YCSB都提供下载链接，读者可以自行测试，验证结果或者测试不同（硬件和软件）配置的结果。在我们执行的所有测试中，Tarantool每秒处理的请求数最多，在任何workload下多数测试中延迟值最低。

因此我们确定，Tarantool比Redis、CouchBase或Memcached之类的主流解决方案更为适合大多典型项目案例。这也是我们决定在my.com项目中使用Tarantool的原因。

更多精彩内容，请点击"阅读原文"