FCon7折倒计时最后一周:日程已上线70%!查看详情>>> 了解详情
写点什么

NoSQL 性能测试白皮书

  • 2014-12-13
  • 本文字数:5479 字

    阅读完需:约 18 分钟

编者按

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

正文

作为一项快速发展的极具创新性的 IT 技术,NoSQL 技术在大数据和实时网页应用中的运用在最近几年呈现了大量的增长。因为 NoSQL 数据库的存储允许更灵活的开发方式和执行方式,这些 NoSQL 数据库能够在许多的工商业应用领域很好地替代传统关系型数据库(RDBMS)。因为弱化了 RDBMS 的一些特征,如一致性和关系型数据模型,NoSQL 技术大大提高了数据库的可扩展能力和可用性。

在这份报告中,bankmark 针对一系列的基准测试实验做了报告,这些测试是为了对比 SequoiaDB 和现在市面上的其他一些 NoSQL 产品在不同的负载情境下的性能表现。因此,bankmark 的测试团队使用了 Yahoo Cloud Serving Benchmark(YCSB)方案作为测试的工具。bankmark 团队针对所有的系统使用了可能出现的所有配置方案,最终选择了哪些造成了较大的性能瓶颈的配置方案,在此过程中,我们参考了所有这些数据库的官方文档,和其他所有公开的技术资料。所有的主要方案我们都会在报告中详细记录,一份完全详细的报告还会包括所有的配置细节。

现在的这一份报告,bankmark 着重于每款数据库在不同的用例下的性能表现,同时也保证了不同结果间的最大可比性。这些大量测试的一个目的之一就是得到这些产品最真实的性能表现。另一方面,分布式的测试环境需要一定的优化来满足数据库集群环境运行的需要。所有的被测试系统都按照集群的需求来进行配置,其中还有一些针对分区操作进行的优化,以满足结果的可比较性。

所有的测试都由 bankmark 团队完成,所有重要的细节包括物理环境、测试配置信息等都在测试报告中有详细的记录,我们还将一份详细版本的报告,这份报告将能确保我们进行的实验都是可重复的。

在我们的测试中,对三款数据库产品进行了比较,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 则几乎在所有的测试情境下都垫底。

这一个部分,我们将介绍这次测试中我们所使用的软件和硬件环境。这次的测试是在 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)

三款数据库系统使用 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 驱动
  • 针对多节点安装配置以及批量加载选项的一些改动

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

  • 十台服务器(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 和 十个域 Field 组成。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 3rd 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.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% 插入

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 等基准测试标准。

测试报告原文:

  1. http://msrg.utoronto.ca/papers/NoSQLBenchmark
  2. http://www.bankmark.de/wp-content/uploads/2014/12/bankmark-20141201-WP-NoSQLBenchmark.pdf
2014-12-13 07:428424
用户头像

发布了 501 篇内容, 共 243.4 次阅读, 收获喜欢 57 次。

关注

评论

发布
暂无评论
发现更多内容

什么是基于安全标记的访问控制机制?有什么特性?

行云管家

网络安全 等级保护 安全标志 访问控制机制

数据湖基本架构

五分钟学大数据

数据湖 6月月更

NFT链游系统开发|DeFi+NFT技术搭建

薇電13242772558

NFT 链游

《云原生的本手、妙手和俗手》——2022全国新高考I卷作文

步尔斯特

云原生

〖Docker指南⑥〗快速入门Docker的五种网络模式

步尔斯特

Docker

Substrate技术及生态5月大事记 | Square One计划启动,波卡上线XCM!

One Block Community

区块链 技术 波卡生态

去中心化NFT交易平台开发

开发微hkkf5566

〖Docker指南⑦〗docker-compose快速入门

步尔斯特

Docker

哈尔滨等保测评公司有哪几家?叫什么名字?

行云管家

网络安全 等保 等保测评 等级测评 哈尔滨

〖Docker指南⑨〗本地一键部署微服务项目到阿里云服务器

步尔斯特

Docker

〖Docker指南⑩〗轻量级监控及管理工具Portainer

步尔斯特

Docker

波场TRX链DAPP智能合约系统开发技术搭建

开发微hkkf5566

InfoQ 极客传媒 15 周年庆征文|实战 MySQL 高可用架构

悟空聊架构

架构 运维 悟空聊架构 热门活动 InfoQ极客传媒15周年庆

集成底座流程测试总结

agileai

测试流程 集成底座 企业服务总线 主数据平台 统一身份管理平台

〖Docker指南②〗Docker常用命令汇总

步尔斯特

Docker

〖Docker指南④〗docker容器卷

步尔斯特

Docker

〖Docker指南⑤〗学习Dockerfile,看这一篇就够了

步尔斯特

Docker

去中心化DEFI质押流动性挖矿项目开发案例(逻辑分析)

开发微hkkf5566

C++ Workflow异步调度框架 - 架构设计篇

1412

c++ 开源 workflow 异步调度 网络框架

InfoQ 极客传媒 15 周年庆征文|PassJava网站生产级事故复盘

悟空聊架构

运维 前端 passjava 悟空聊架构 InfoQ极客传媒15周年庆

BI 如何让SaaS产品具有 “安全感”和“敏锐感”(上)

葡萄城技术团队

SaaS BI 数据可视化

融云 IMKit Web 端上线,带你感受开发效率的参差

融云 RongCloud

物联网低代码平台权限管理,保障平台安全!

AIRIOT

物联网 低代码开发 低代码开发平台 快速开发平台

Linux命令汇总 | vim | shell | 进阶【2022版】

步尔斯特

云原生

〖Docker指南①〗快速入门|安装|加速|hello-world

步尔斯特

Docker

〖Docker指南③〗Docker镜像的深度解析

步尔斯特

印尼Widya Robotics携手华为云,让建筑工地安全看得见

华为云开发者联盟

人工智能 安全 华为云 modelarts 机器视觉

C++ Workflow异步调度框架 - 基本介绍篇

1412

c++ 开源 workflow 异步调度 网络框架

〖Docker指南⑧〗Docker私有镜像仓库|阿里云|Registry|Harbor

步尔斯特

Docker

从云服务器 SSRF 漏洞到接管你的阿里云控制台

火线安全

云安全

【高阶知识】用户态协议栈之Epoll实现原理

C++后台开发

后端开发 epoll Linux服务器开发 C++后台开发 户态协议栈

  • 扫码添加小助手
    领取最新资料包
NoSQL性能测试白皮书_语言 & 开发_崔康_InfoQ精选文章