转载

NoSQL性能测试白皮书

最近，bankmark公司针对目前市面上流行的NoSQ数据库SequoiaDB、Cassandra、MongoDB进行了详细的性能测试，InfoQ经授权发布中文版白皮书。正文

1.简介

作为一项快速发展的极具创新性的IT技术，NoSQL 技术在大数据和实时网页应用中的运用在最近几年呈现了大量的增长。因为NoSQL数据库的存储允许更灵活的开发方式和执行方式，这些NoSQL数据库能够在许多的工商业应用领域很好地替代传统关系型数据库（RDBMS）。因为弱化了RDBMS的一些特征，如一致性和关系型数据模型，NoSQL技术大大提高了数据库的可扩展能力和可用性。在这份报告中，bankmark针对一系列的基准测试实验做了报告，这些测试是为了对比SequoiaDB和现在市面上的其他一些NoSQL产品在不同的负载情境下的性能表现。因此，bankmark的测试团队使用了 Yahoo Cloud Serving Benchmark（YCSB）方案作为测试的工具。bankmark团队针对所有的系统使用了可能出现的所有配置方案，最终选择了哪些造成了较大的性能瓶颈的配置方案，在此过程中，我们参考了所有这些数据库的官方文档，和其他所有公开的技术资料。所有的主要方案我们都会在报告中详细记录，一份完全详细的报告还会包括所有的配置细节。现在的这一份报告，bankmark着重于每款数据库在不同的用例下的性能表现，同时也保证了不同结果间的最大可比性。这些大量测试的一个目的之一就是得到这些产品最真实的性能表现。另一方面，分布式的测试环境需要一定的优化来满足数据库集群环境运行的需要。所有的被测试系统都按照集群的需求来进行配置，其中还有一些针对分区操作进行的优化，以满足结果的可比较性。所有的测试都由bankmark团队完成，所有重要的细节包括物理环境、测试配置信息等都在测试报告中有详细的记录，我们还将一份详细版本的报告，这份报告将能确保我们进行的实验都是可重复的。

2.测试结果概述

在我们的测试中，对三款数据库产品进行了比较，SequoiaDB[1]、Cassandra[2]以及 MongoDB[3]。所有的产品都在一个10节点集群的“全内存环境”（原始数据大小为总RAM大小的1/4）或是“大部分内存环境”（原始数据大小为总RAM大小的1/2）的环境下进行安装测试。我们选用业界广泛使用的YCSB工具作为基准性能测试的平台。在所有测试中，所有的数据都进行3次复制备份，以应对容错操作。复制测试则使用了倾斜负载（Zipfian或是最新的分发版）。详细的配置将在下面展示，也会在之后的详细版报告中记录。所有测试的结果没有显示出三款之中一个完全的最优者。我们的“大部分内存环境”下的测试显示Cassandra 使用了最多的内存，因此也需要在多读少写负载的情况下，进行更多的磁盘I/O操作，这也导致了其严重的性能下降。在“大部分内存环境”的设定下，SequoiaDB的性能在大多数情境下都大大优于其他的产品，除了在Cassandra的强项多写少读负载。在“全内存环境”（原始数据大小为总RAM大小的1/4）下，SequoiaDB在读请求下表现更好，而Cassandra在写请求下表现稍好。MongoDB则几乎在所有的测试情境下都垫底。

3.硬件和软件配置

这一个部分，我们将介绍这次测试中我们所使用的软件和硬件环境。这次的测试是在SequoiaDB的实验室中一个集群上进行的，所有的测试都在物理硬件上进行，没有使用任何虚拟化的层级。基本系统的搭建以及MongoDB和SequoiaDB的基本安装操作都是由训练有素的专业人员进行的。bankmark有着完全的访问集群和查看配置信息的权限。Cassandra则由bankmark来进行安装。

3.1集群硬件

所有的数据库测试都在一个10节点的集群上进行（5台 Dell PowerEdge R520 服务器，5台Dell PowerEdge R720 服务器），另外还有5台HP ProLiant BL465c刀片机作为YCSB客户端。详细硬件信息如下：

3.1.1 5x Dell PowerEdge R520 (server)

1x Intel Xeon E5-2420, 6 cores/12 threads, 1.9 GHz
47 GB RAM
6x 2 TB HDD, JBOD

3.1.2 5x Dell PowerEdge R720 (server)

1x Intel Xeon E5-2620, 6 cores/12 threads, 2.0 GHz
47 GB RAM
6x 2 TB HDD, JBOD

3.1.3 5x HP ProLiant BL465c (clients)

1x AMD Opteron 2378
4 GB RAM
300 GB logical HDD on a HP Smart Array E200i Controller, RAID 0

3.2集群软件

集群以上述的硬件为物理系统，而其中则配置了不同的软件。所有的软件实用信息以及对应的软件版本信息如下：

3.2.1 Dell PowerEdge R520 and R720 (used as server)

操作系统（OS）: Red Hat Enterprise Linux Server 6.4
架构（Architecture）: x86_64
内核（Kernel）: 2.6.32
Apache Cassandra: 2.1.2
MongoDB: 2.6.5
SequoiaDB: 1.8
YCSB: 0.1.4 master (brianfrankcooper version at Github) with bankmark changes (see 4.1)

3.2.2 HP ProLiant BL465c (used as client)

操作系统（OS）: SUSE Linux Enterprise Server 11
架构（Architecture）: x86_64
内核（Kernel）: 3.0.13
YCSB: 0.1.4 master (brianfrankcooper version at Github) with bankmark changes (see 4.1)

4.安装过程

三款数据库系统使用YCSB进行基准测试，分别是Apache Cassandra、MongoDB 以及 SequoiaDB。下来这一部分，分别介绍了这三者如何安装。集群上运行的数据库系统使用3组副本以及3组不同的磁盘。压缩性能的比较只在带有此功能的系统上进行。

4.1集群内核参数

下面的配置参数为三款数据库系统共同使用：

vm.swappiness = 0
vm.dirty_ratio = 100
vm.dirty_background_ratio = 40
vm.dirty_expire_centisecs = 3000
vm.vfs_cache_pressure = 200
vm.min_free_kbytes = 3949963

4.2 APACHE CASSANDRA

Apache Cassandra在所有服务器上都按照官方文档^[4]进行安装，其配置也按照推荐的产品配置^[5]进行。提交的日志和数据在不同的磁盘进行存储（disk1 存储提交的日志，disk5和disk6 存储数据）。

4.3 MONGODB

MongoDB由专业的工作人员安装。为了使用三个数据磁盘以及在集群上运行复制组，我们根据官方文档有关集群安装的介绍^[6]，使用了一套复杂的方案。3个集群点上都启动了配置服务器。在十台服务器上，每台一个mongos实例（用于分区操作）也同时启动。每一个分区都被加入集群当中。为了使用所有三个集群以及三个复制备份，10个复制组的分布按照下表进行配置（列为集群节点）：

	Node1	Node2	Node3	Node4	Node5	Node6	Node7	Node8	Node9	Node10
Disk3	dg0	dg0	dg0	dg1	dg1	dg1	dg2	dg2	dg2	dg3
Disk4	dg3	dg3	dg4	dg4	dg4	dg5	dg5	dg5	dg6	dg6
Disk5	dg6	dg7	dg7	dg7	dg8	dg8	dg8	dg9	dg9	dg9

MongoDB没有提供自动启动已分区节点的机制，我们专门为了10个集群节点将手动启动的步骤写入了YCSB工具当中。

4.4 SEQUOIADB

SequoiaDB由专业的工作人员按照官方文档进行安装^[7]。安装设置按照了广泛文档中有关集群安装和配置^[8]的部分进行。SequoiaDB可以用一个统一的集群管理器启动所有的实例，内置的脚本 “sdbcm”能用来启动所有服务。三个数据库系统的节点由catalog节点进行选择。三个SequoiaDB的实例在每个节点启动，访问自己的磁盘。

4.5 YCSB

YCSB在使用中存在一些不足。它并不能很好的支持不同主机的多个YCSB实例运行的情况，也不能很好支持多核物理机上的连续运行和高OPS负载。此外，YCSB也不是很方便温服。bankmark根据这些情况，对资源库中的YCSB 0,1,14版本其做了扩展和一些修改优化。较大的改动如下：

增加了自动测试的脚本
Cassandra的jbellis驱动（https://github.com/jbellis/YCSB ）
MongoDB的achille驱动（https://github.com/achille/YCSB ）
增加批插入功能（SequoiaDB提供）
更新了MongoDB 2_12的驱动借口，同时增加了flag属性来使用批处理模式中的”无序插入“操作。
SequoiaDB驱动
针对多节点安装配置以及批量加载选项的一些改动

5.基准测试安装

如下的通用和专用参数为了基准测试而进行运行：

十台服务器（R520、R720）作为数据库系统的主机，五台刀片机作为客户端。
使用第六台刀片机作为运行控制脚本的系统
每个数据库系统将数据写入3块独立的磁盘
所有测试运行都以3作为复制备份常数

bankmark的YCSB工具，根据工作说明中的测试内容提供了负载文件：

workload1	warmup	Single load	Zipfian distribution	100% read
workload1		bulk load (1k records)	Zipfian distribution	100% read
workload2	warmup	Single load	Zipfian distribution	50% read, 50% update
workload2		bulk load (1k records)	Zipfian distribution	50% read, 50% insert
workload3	warmup	Single load	Zipfian distribution	5% read, 95% update
workload3		bulk load (1k records)	Zipfian distribution	5% read, 95% update
workload4	warmup	Single load	Zipfian distribution	95% read, 5% update
workload4		bulk load (1k records)	Zipfian distribution	95% read, 5% update
workload5	warmup	Single load	latest distribution	95% read, 5% update
workload6		bulk load (1k records)	latest distribution	95% read, 5% insert

对于数据载入，workload[1-5]-warmup或者workload[1-5]文件都可以使用，需要根据具体的需求载入类型选择。5种负载中的每一个都会被分为一个针对最终结果的负载文件和一个在真正运行测试之前运行的预热文件。为了避免和YCSB的内部访问记录控制部分冲突，预热阶段将不会进行插入操作。通过一个线程扩展的测试，我们发现每个YCSB实例将会使用64个线程对于所有的3个系统都是表现最好的。

如下是测试中用到的其他的参数：

尽可能的使用压缩功能
每个YCSB客户端的线程数：64
产生：
- 测试用例1：2亿（2000万每个节点）记录
- 测试用例2：1亿（1000万每个节点）记录
- 每条记录由键user<ID> 和十个域 Field<ID> 组成。YCSB默认的记录大小为100byte，最终的平均记录大小为1128 Bytes （10 fields + field names + key）
每个key value存储的通用基准测试步骤为：
- 启动数据库服务器
- 迭代提供的负载文件中的5个负载：
  - 运行单数据载入（无时间限制，负载文件中的 workload[1-5]-warmup）
  - 暂停30分钟给每个系统进行清空等操作
  - 运行30分钟的负载预热操作（负载文件中的 workload[1-5]-warmup）
  - 运行30分钟的负载（负载文件中的 workload[1-5]）
- 停止数据库服务器

5.1指导方针/ 步骤

所有的系统都运行一次单条载入，一次预热还有一次正式测试。对于支持批量载入的系统，MongoDB和SequoiaDB，还有一项批量载入的测试要运行。

5.2配置信息矩阵

Database Options	Cassandra	MongoDB	SequoiaDB
Nodes	10 instances (1 per node)	10 “mongos” instances (1 per node) 30 “mongod” replica instances (3 per node) 3 configuration Servers (every 3^rd node)	10 SequoiaDB instances 30 Replica instances (3 per node)
Disks	Log :disk1 Data: disk5,disk6	Replicas: disk3,disk4,disk5	Replicas: disk3,disk4,disk5
Sharding/ Replication	3replicas(on db creation)	10 shards with 3 replicas each	10 shards with 3 replicas each
Compression	Yes	No(not support)	Yes
Consistency	Read/write/scan/ delete:ONE	Read preference: nearest, Write concern: Journaled	Write concern: Journaled (not changeable)
Bulk	No	Yes(1k records per batch)	Yes(1k records per batch)

6.基准测试结果

6.1测试用例1（2亿记录/ 2000万每节点）

在此测试中，原始数据大约为总系统RAM的45%。

1.载入

2. 批量载入（1000条记录一批次）

3. 负载1，Zipfian，100%读

4. 负载2，Zipfian，50%读，50%更新

5. 负载3，Zipfian，5%读，95%更新

6. 负载4，Zipfian，95%读，5%更新

7. 负载5，最新的分布，95%读，5%插入

6.2测试用例2（1亿记录/ 1000万每节点）

在此测试中，原始数据大约为总系统RAM的22%。

1. 载入

2. 批量载入

3. 负载1，Zipfian，100%读

4. 负载2，Zipfian，50%读，50%更新

5. 负载3，Zipfian，5%读，95%更新

6. 负载4，Zipfian，95%读，5%更新

7. 负载5，最新的分布，95%读，5%插入

7.关于作者

Tilmann Rabl是多伦多大学（University of Toronto）的博士后以及bankmark公司的CEO。他的研究主要针对于大数据的基准测试以及大数据系统方面。Michael Frank是bankmark公司的CTO，他是工业标准的基准测试方案Parallel Data Generation Framework(PDGF)的核心开发成员之一。ManuelDanisch是bankmark公司的COO。他是BigBench大数据分析基准测试系统的主要开发者之一，此外他还是Transaction Processing Performance Council(TPC) 基准测试 TPC-DI的数据贡献者。

bankmark是一家独立的基准测评机构，公司为大数据提供了革命性的基准测试方案。受创新技术的推动，bankmark产生了许多优秀而有质量的测试，同时还对很多概念系统进行了验证并成功的将这些概念系统进行生产力模拟以及成本模拟。以前沿科学研究为基础的技术，保证了史无前例的质量和速度。

bankmark是工业基准测试标准化协会SPEC和TPC的独立成员之一，他们的技术基于TPC-DI和BigBench等基准测试标准。