赞
踩
在本篇测试报告中,我们使用Yahoo!发布的标准YCSB测试规则,对MongoDB、SequoiaDB、Cassandra、HBase进行对比,并尝试给出每种不同产品所适用的应用场景。在测试配置中,我们尽可能对全部产品做到高可用配置,而在一致性级别上则使用最终一致性。
在测试中我们会对两种类型的NoSQL数据库做横向对比,包括Document-Oriented文档类数据库、以及Big-Table宽表类数据库。由于每种类型的数据库具有很多自己独特的特性,我们不能将每种特性一一表现在该测评结果中。本测试主要针对数据库在不同任务类型下的性能指标进行,且仅依赖YCSB所提供的标准测试流程。
本测试将详细列出测试的物理环境以及配置信息,以便于读者能够使用自己的环境独立验证结果。
1.测试产品
本测试主要对比两种类型的NoSQL数据库,包括四款不同的产品:
其中MongoDB作为当前市场占有率最高的数据库,可能是众多读者所关心的产品,提供丰富的数据库功能,号称是最接近关系型数据库的NoSQL产品;而SequoiaDB由前IBM DB2团队的研发人员创建,据称在性能和功能上能够与MongoDB做正面抗衡,同样提供很多MongoDB所提供的功能(例如分片、多索引等特性)。
HBase则是Hadoop框架的一员,也已经被广大企业和互联网用户所接受,我们使用的版本0.94.6是跟随CDH 4.5.0安装包的版本;而Cassandra则是与HBase类似的产品,由Facebook研发并进行开源,同样拥有广大的用户市场。
我们的测试使用由Yahoo!研究院发布的Yahoo Cloud Serving Benchmark (YCSB)基准测试,并将接口对各自产品的最新版进行了修改和适配。我们在正文后的附录中也提供了SequoiaDB的YCSB测试接口。
需要重新强调的是,每种不同的产品都有各自的应用场景。YCSB测试尽管是Yahoo!研究院提供的测试框架,但是在很多场景下并不能完全发挥出每个产品各自的特点。在本测试中,我们尝试使用YCSB框架给出最为客观的评估结果。如果对于该测试结果或配置存在疑问,我们欢迎广大读者根据自身需要重新调整,并将结果开放以供参考。
2. 测试场景
YCSB测试框架提供了丰富的场景配置机制,允许用户根据需要选择需要导入的数据量和增删改查之间相应的比例。在本测试中,我们导入一亿条数据,并对如下场景进行对比。
场景编号 | 场景分类 | 描述 |
1 | 单条记录导入 | 单条记录导入 |
2 | 批量记录导入 | 批量记录导入 |
3 | 单纯查询 | 100%查询 |
4 | 查询导入平衡 | 50%导入,50%查询 |
5 | 更新为主 | 95%更新,5%查询 |
6 | 查询为主 | 95%查询,5%更新 |
7 | 查询最新 | 95%查询,5%导入 |
对于数据导入的场景,我们对单条记录插入和批量插入两个场景进行了区分。对于一些数据库来说,默认配置会在客户端将一批记录打包并统一发送给服务器,对于这类产品,尽管其接口为单条记录操作,我们依然将其归类为批量记录导入模式。
写入和查询的数据模拟典型日志记录的长度,具有以下特性:
特性 | 描述 |
字段数 | 10字段 |
字段名长度 | 6字节 |
记录总大小 | 100Bytes |
全部字段类型 | 字符串 |
主键长度 | 23字节 |
总记录数 | 1亿条 |
总裸数据量 | 大约100GB |
数据副本份数 | 3 |
其中,SequoiaDB与MongoDB的分片均配置为一主两从;HBase所在的HDFS设置复制份数为3;Cassandra建表时使用参数replication_factor=2。
一致性级别上,我们使用最弱的最终一致性,读写的write concern均设置为1。
3. 测试环境
本测试中,测试环境总共包含4台Dell R520物理机作为数据存储。生成数据的YCSB程序与数据库运行在同一物理环境。
注:如使用独立服务器进行YCSB的数据生成,会导致千兆网瓶颈。
整个集群的拓扑结构如图1所示:
图1:测试集群拓扑
服务器环境。本测试数据库服务器使用4台Dell R520物理机环境,每台物理机配置如下:
类型 | 参数 |
CPU | Intel(R)Xeon®CPUE5-24201.9GHZ(6core) |
内存 | DDR348GB |
磁盘 | 6块内置SATA硬盘,2TB/块 |
网络 | 千兆以太网 |
操作系统 | RedHatEnterpriseLinuxServerrelease6.4 kernel-release:2.6.32-358.e16.x86_64 |
JDK | OracleJDK1.6 |
4. 测试方法
本测试使用YCSB标准,基于四台物理机执行。对于每种不同产品的测试流程如下:
并发性方面则基于以下规则:
一、 场景1:单条记录导入
图2:单条记录导入场景
在单条记录导入场景中,SequoiaDB与MongoDB使用insert方法,writeConcern设置为Normal;HBase则设置客户端缓冲区为2KB。而在错误检验方式上,由于是单条记录插入,所以MongoDB必须在每次操作后检测返回值是否成功,因此不可以使用异步插入方式。
在图2的结果中可以看到,单条记录导入操作SequoiaDB最高,总吞吐量可以达到每秒钟近7万。而HBase与Cassandra则比较接近,在5-6万之间。MongoDB在该场景中表现较差,总吞吐量不到每秒1万。
在该场景中,YCSB在4台服务器上各启动24条线程,总共并发量为96线程。
二、 场景2:批量记录导入
图3:批量记录导入场景
批量记录导入场景的结果见图3。在该场景中,SequoiaDB与MongoDB使用各自提供的bulk insert方法;HBase则设置client buffer为4MB;Cassandra不提供批量数据导入方式。
在该测试中,批量导入数据为每批次3000条记录,每节点启动8条线程,总数32线程。
测试结果显示,SequoiaDB可以达到每秒钟近19万的导入速度,而MongoDB则与单线程导入的性能接近(1万左右),HBase也没有本质提升。
三、 场景3:单纯查询
图4:单纯查询场景
图4显示单纯随机查询的场景。在该场景中MongoDB表现最为突出,整体吞吐量达到每秒钟8万以上。SequoiaDB和Cassandra类似,大约为MongoDB的一半,在4万至5万之间徘徊。而HBase表现最差,未达到每秒1万的指标。
该场景每台物理服务器使用36条客户端线程,总数144条线程。
四、 场景4:查询导入平衡
图5:查询导入平衡场景
该场景主要模拟50%的插入和50%的查询业务(图5)。其中插入业务使用单条记录插入。
最终的结果显示,SequoiaDB的整体表现最优,平均达到每秒钟超过14000TPS,而MongoDB/HBase/Cassandra则比较接近,各自不到10000TPS。
五、 场景5:更新为主
图6:更新为主场景
如图6所示,更新为主场景模拟95%更新与5%查询的场景。该场景中,SequoiaDB表现最优,结果介于5万到6万之间每秒。
而MongoDB表现相对较弱,大约在5千每秒左右的数量级。
六、 场景6:查询为主
图7:查询为主场景
在查询为主的场景中,模拟95%查询+5%更新。在该测试中,SequoiaDB与Cassandra的性能接近单纯查询的场景,而更新操作对MongoDB的损耗相对较大,使其性能仅不到3万每秒。
HBase在随机读为主的场景下相对较慢。
七、 场景7:查询最新
图8:查询最新场景
查询最新场景为95%读+5%插入,并且读取的数据尽可能是刚刚写入的数据。
从图8中可以看出,SequoiaDB对于刚刚写入至内存中便读取的场景性能最佳,达到近4万每秒。
而MongoDB和Cassandra则相比场景6有明显下降,HBase依然性能较低。
从第三部分的各个场景对比中可以看出,SequoiaDB数据库在数据插入场景中表现最为突出,甚至超过本身以插入性能著称的Cassandra,混合读写场景下性能也可圈可点。而业界普及率最高的MongoDB则在单纯读取性能上最为抢眼,远超其他。
HBase与Cassandra虽然在写入性能上远高于MongoDB,但是和SequoiaDB相比仍然逊色一筹;而在主键随机读操作方面,Cassandra的新版本和之前的版本比起来性能大幅度上升,基本做到和MongoDB处于同一水平线,而HBase则远不能和其他产品相比。
当然,这些比较也仅仅局限于YCSB所做的测试,而文档类数据库能够提供的二级索引等机制并非是YCSB所测试的。因此,文档类数据库能够提供比宽表类数据库更多的应用场景。
如此看来,对于宽表类数据库来说,如果在其最有优势的主场都败给了文档类数据库,这是否意味着,HBase和Cassandra最大的优势已经不再,文档类数据库会在各个领域的性能表现超越宽表呢?
1. MongoDB
MongoDB的分片分布如图9,不同颜色代表不同的分片,我们采用的是多个副本的分片
MongoDB的部署脚本如下(deploy.sh):
[xml]view plaincopy
MongoDB的分片添加脚本如下(addshard.js):
[java]view plaincopy
MongoDB的集合创建脚本如下(createcl.sh):
[js]view plaincopy
所有的writeConcern都为normal。
2. SequoiaDB
SequoiaDB的数据组分布情况如图10,其中不同颜色代表不同的分片。
SequoiaDB的部署脚本如下(deploy.js):
[java]view plaincopy
创建分区集合的脚本如下(createcl.js):
[js]view plaincopy
3. HBase
HBase的数据分布情况如图11:
图11:HBase部署架构图
创始表语句使用:
create 'usertable', 'cf', {SPLITS => ['user1', 'user2', 'user3', 'user4', 'user5', 'user6', 'user7', 'user8', 'user9' ]}
5.4Cassandra
图12是一个Cassandra四节点集群。我们采用使用二十四块硬盘同时处理数据和提交日志。
图12:Cassandra部署架构图
与测试的其他数据库不同,Cassandra 在配置中使用环形拓扑,节点需要被明确地视为“种子”节点(这有助于它们加入到环中)。在配置时,必须指定哪些令牌将映射到哪些实例。
我们使用了https://raw.github.com/riptano/ComboAMI/2.2/tokentoolv2.py提供的令牌生成工具来创建节点配置。
[js]view plaincopy
Cassandra 的一致性级别可以调节。每次读取和写入都可以明确地说明该操作需要什么级别的数据库一致性。由于这是一个基准测试项目,因此我们使用了最弱和最快的一致性级别(ONE)来进行读取和写入。
对于所有数据库,我们使用的复制因子都是 2。其他主要设置为:
内容 | 值 |
分区工具 | RandomPartitioner |
初始令牌空间 | 2^127/4 |
内存表空间 | 4GB |
并发读取 | 48 |
并发写入 | 48 |
压缩 | SnappyCompressor |
提交日志同步 | 10000ms |
以下内容为 conf/cassandra.yaml 的设置:
[js]view plaincopy
使用以下命令对数据库进行初始化:
[js]view plaincopy
一、 驱动调整
1. MongoDB
详细调整如下:
[js]view plaincopy
2. HBase
详细如下:
[java]view plaincopy
二、 统计数据收集
从原有的Measurements派生出ExcelMeasurementsExporter用于将生成的统计数据导出到excel文件中,ExcelMeasurementsExporter调用jxl.jar开源库实现。
统计数据由Overalloperresult、Overallresult,Periodresult这几个类存储,为了保存统计数据原来的Measurements,StatusThread都相应作了些调整。
三、 预热
增加如下xml配置文件
[xml]view plaincopy
我们增加了如下python脚本用于连续运行:
[py]view plaincopy
为尽量保证后续的查询、更新操作是基于前续的load操作,以保证缓存的高命中率。
四、 数据类型
本次测试的数据皆为字符串类型:
[java]view plaincopy
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。