rocksdb和leveldb性能比较——写性能
前面学习了一下rocksdb,这个db是对leveldb的一个改进,是基于leveldb1.5的版本上的改进,而且leveldb1.5以后也在不断的优化,下面从写入性能对两者进行对比。
前言
比较的leveldb的版本是1.18,rocksdb的版本是3.10.1.
在比较的时候需要将leveldb和rocksdb的参数调成一样的,本文的参数为,
memtable 4M,最多2个memtable
level0_slowdown_writes_trigger=8,level0_stop_writes_trigger=12,level0_file_num_compaction_trigger=4,
flush和compaction共用一个进程
leveldb和rocksdb在后台进程管理的默认配置也是不一样的,leveldb默认只能有一个后台进程用于flush和compaction,而rocksdb flush和compaction都会有一个进程,本文特殊没有说明的rocksdb就是和leveldb一样的,flush和compaction共用一个进程
场景1
每个key 8byte,没有value
这个场景在关系链系统里面非常常见,因为关系链系统是key-list,使用leveldb类似系统实现的时候,需要将list中的id提到key里面
得到的测试结果如下:
leveldb | rocksdb | |
请求数 | 10000000 | 10000000 |
数据量 | 80M | 80M |
耗时s | 56 | 73 |
吞吐量(Mps) | 1.428571429 | 1.095890411 |
qps | 178571.4286 | 136986.3014 |
是否发生stall | 否 | 否 |
结论是leveldb比rocksdb要略胜一筹,由于value为空,整个的吞吐量和磁盘的吞吐量(100Mps到150Mps)还相差比较远,所以并没有发生写stall的情况。因为没有发生stall,所以性能对比完全是内存操作的性能的对比。
这个场景比的主要是内存的写操作速度,可以看出leveldb要好一些。
因为主要是内存操作,内存操作没有log,(加上log会严重影响性能),猜测的原因可能是:
- leveldb的skiplist的原子指针用的是memory barrier实现的,而rocksdb使用的atomic实现的。
- rocksdb采用了很多虚函数的地方,性能有可能比leveldb要差一些。
场景2
每个key 8byte,value 1000byte。
leveldb | rocksdb(flush和compaction共用线程) | rocksdb(flush和compaction分开线程) | |
请求数 | 1000000 | 1000000 | 1000000 |
数据量 | 1G | 1G | 1G |
耗时s | 70 | 138 | 125 |
吞吐量(Mps) | 14.62857143 | 7.420289855 | 8.192 |
qps | 14285.71429 | 7246.376812 | 8000 |
是否发生stall | 是 | 是 | 是 |
结论仍然是leveldb要更好一些,具体查看LOG文件,可以看出端倪,rocksdb的最后的level分布是:[6 359 148 0 0 0 0],level1文件严重超出范围,这样level0的文件并到level1上的时候就需要读入非常多的文件。咋
其中一次8个level0的319个level1的文件进行一次compaction,花费的时间可想而知。
那么为什么会这样呢?因为rocksdb在挑选compaction的时候,如果level0的文件数目超出level0_slowdown_writes_trigger的时候得分异常高,所以会一直发生level0向level1转移的情况,没有机会level1向level2转移。在这种情况下rocksdb就走向了深渊。。。。leveldb挑选compaction的时候,level0的分值是文件数目除以kL0_CompactionTrigger,其他level的分值是该level的总文件大小除以这个level的最大byte
当rocksdb的flush和compaction分为两个进程的时候时间稍有减少,可以看出效果很不明显。这个原因是磁盘是瓶颈,分为两个进程并不能提高磁盘的吞吐量。
结论
从这个比较中可以看出,在写量非常大的时候,leveldb的性能还是要优于rocksdb的
转载于:https://www.cnblogs.com/jfwang/p/4460191.html
rocksdb和leveldb性能比较——写性能相关推荐
- Rocksdb 与 TitanDb 原理分析 及 性能对比测试
文章目录 前言 Rocksdb的compaction机制 compaction作用 compaction分类 level style compaction(rocksdb 默认进行的compactio ...
- cassandra mongodb选择——cassandra:分布式扩展好,写性能强,以及可以预料的查询;mongodb:非事务,支持复杂查询,但是不适合报表...
Of course, like any technology MongoDB has its strengths and weaknesses. MongoDB is designed for OLT ...
- Elasticsearch-32.生产环境常用配置与上线清单 he 集群写性能优化 he 集群读性能优化
Elasticsearch 生产环境常用配置和上线清单 Development vs.Production Mode 从ES 5开始,支持Development 和Production 两种运行模式 ...
- mysql 写 性能,MySQL在大型,只写表上的性能
在此先感谢您的回答,对不起我的英语不好,我不是母语人士. 我们实际上正在开发一个带有后端的手机游戏.在这款手机游戏中,我们有一个货币系统,我们会跟踪每笔交易以进行验证. 为了读取用户余额,我们有一个中 ...
- mysql配置性能_MySQL配置性能优化
下面配置的优化,可能影响比较大,可能可以显著提高读写性能. 1.mysql一些主要配置项介绍: innodb_buffer_pool_size 这是你安装完InnoDB后第一个应该设置的选项.缓冲池是 ...
- 【Linux 性能优化系列】Linux 性能优化 -- CPU 性能篇(一) 平均负载、上下文切换、CPU 使用率
[Linux 性能优化系列]Linux 性能优化 -- CPU 性能篇(一) 平均负载.上下文切换.CPU 使用率 [1]相关概念 [1.1]平均负载 平均负载是指单位时间内,系统处于可运行状态和不可 ...
- 《vSphere性能设计:性能密集场景下CPU、内存、存储及网络的最佳设计实践》一3.3.3 供应实验室...
本节书摘来华章计算机<vSphere性能设计:性能密集场景下CPU.内存.存储及网络的最佳设计实践>一书中的第3章 ,第3.3.3节,[美] 克里斯托弗·库塞克(Christopher K ...
- 《vSphere性能设计:性能密集场景下CPU、内存、存储及网络的最佳设计实践》一1.2.2 内存...
本节书摘来华章计算机<vSphere性能设计:性能密集场景下CPU.内存.存储及网络的最佳设计实践>一书中的第1章 ,第1.2.2节,[美] 克里斯托弗·库塞克(Christopher K ...
- 《vSphere性能设计:性能密集场景下CPU、内存、存储及网络的最佳设计实践》一1.1.1 确定参数...
本节书摘来华章计算机<vSphere性能设计:性能密集场景下CPU.内存.存储及网络的最佳设计实践>一书中的第1章 ,第1.1节,[美] 克里斯托弗·库塞克(Christopher Kus ...
最新文章
- 新浪微博开放平台API中page参数的使用方法
- (转载)详解Hive配置Kerberos认证
- Beyond Compare启动出错解决方案
- 挂起某线程命令 Linux,linux 线程挂起恢复的简单示例
- repeater使用1
- java中throws和throw的区别和用法
- Linux内核之数据双链表
- php mysqli分页,PHP使用Mysqli类库实现完美分页效果的方法_PHP
- MS SQL SERVER中的临时表
- 【网络是怎样连接的】—— TCP/IP 传输数据
- 【Unity3D基础2-2】认识Unity3D引擎
- 数据库实验一——数据库定义与操作语言实验
- python+django+mysql校园失物招领系统毕业设计毕设开题报告
- RuntimeError: Cannot re-initialize CUDA in forked subprocess. To use CUDA with multiprocessing, you
- 数据分析师-SQL笔试题-做透这道题就够了
- mysql数据库的备份和恢复
- Linux测试工具httpd-tools
- 服务器接收协议,协议分析-服务器接收
- html5设置春联,英文版春节对联
- e3哪种型号做服务器好些,至强E3处理器 不可小觑_服务器产业-中关村在线