LevelDB、TreeDB、SQLite3性能对比测试

转载 2015年07月09日 18:12:10

from : http://blog.nosqlfan.com/html/2819.html

下面性能测试对比来自LevelDB官方,由 NoSQLFan 进行翻译整理。从结果上看,这不像某些田忌赛马式的性能对比,总体来说还是比较客观全面。通过多种场景下的不同性能测试结果的对比,我们也能对这三个数据库分别擅长和适用的场合有所了解。同时对其性能调优的方法理解也有一定的帮助。

原文链接:leveldb.googlecode.com

下面是对LevelDB、TreeDBSQLite3 这几个数据库的性能对比测试,分别使用了LevelDB (revision 39) SQLite3 (version 3.7.6.3) 及 Kyoto Cabinet’s (version 1.2.67)这三个版本的数据库。

测试机器配置:six-core Intel(R) Xeon(R) CPU X5650 @ 2.67GHz, with 12288 KB of total L3 cache and 12 GB of DDR3 RAM at 1333 MHz

文件系统:测试脚本分别跑在两台机器上,其文件系统一台为ext3(磁盘为 SATA Hitachi HDS721050CLA362),一台为ext4(配备磁盘 SATA Samsung HD502HJ)

性能测试源码:

基本测试

基本测试的条件如下:

  • 每个数据库使用4GB内存
  • 数据库都处于异步写模式(LevelDB’s sync option, TreeDB’s OAUTOSYNC option, SQLite3’s synchronous options 都关闭),也就是说写操作不用等数据真正写到磁盘上才返回。
  • Key 的长度为16字节
  • Value 的长度为100字节 (这个长度才能让数据库的压缩算法能够起作用,将数据压缩至50%大小左右)
  • 顺序读写时Key值递增变化
  • 随机读时生成随机的Key值

测试结果:



结果显示,在顺序读写和随机写上,LevelDB 在性能上都遥遥领先,在随机读上面 Kyoto Cabinet 引擎稍快一些。

在几种不同策略下进行写操作测试

A. Values 为长数据(数据长度为100,000字节)

LevelDB在Value较长时性能比较低,这是由于LevelDB对每一次写操作都会至少进行两次写动作,一次是写数据文件,另一次是写日志文件。这里慢的主要原因是LevelDB在进行这些操作时对值进行了过多的Copy。

B. 批量写操作

一次写操作写1000条100字节的数据,由于TreeDB不支持批量写入,故未对其进行对比测试

上面结果是由于LevelDB数据的组织方式,导致顺序写和随机写在性能上都变化不大。

C. 同步进行写操作

  • 对 LevelDB, 设置 WriteOptions.sync = true.
  • 对 TreeDB, 将 TreeDB’s OAUTOSYNC 选项开启.
  • 对 SQLite3, 设置 “PRAGMA synchronous = FULL”.

如果你看一下ext4文件系统下的测试数据,你会发现ext3和ext4在表现上非常不同。

D. 无压缩的写操作

LevelDB 和 TreeDB 都支持相应的数据压缩算法(LevelDB 使用的是 Snappy , TreeDB 使用的是 LZO),由于SQLite不支持压缩,所以这里的测试数据只是从上面的基本测试结果copy过来的。

LevelDB开启压缩比不开启压缩效率更高,而TreeDB则相反,这可能是由于TreeDB采用的压缩算法(LZO)与LevelDB采用的压缩算法(Snappy)相比计算代价更高。

E. 使用更大内存

将每个独立库的内存增大到128MB,对LevelDB来说,其中120MB用来做 write buffer,另外8MB用来做 cache(原来是2MB的 write buffer 和2MB的cache),对SQLite来说,我们不改变其page size,还是保持为1kb,但是我们增大其page数量从4k增加到128k,对TreeDB来说,我们同样不改变其page大小,也只是增大其cache,从4MB增大到128MB。

SQLite 在采用了大内存后性能变化并不大,而 LevelDB 和 TreeDB 的随机写性能却有显著提高。LevelDB 在增大内存后性能提升的原因是其write buffer 更大,从而减少了创建的sorted file的次数。减少了磁盘IO。而 TreeDB 的性能提升原因是由于其数据库的更大部分被映射到内存中了。

在几种不同策略下进行读操作测试

A. 大的Cache空间

我们分配128MB给每个数据库,对LevelDB来说,我们分配8MB给 write buffer,120MB给cache,对另外两个数据库,由于它们不支持区分 write buffer 和cache,所以统一将 cache size设置成128MB。

从结果可以看到,增大Cache在数据库读性能上都有所提升,其中最为显著的是TreeDB,其随机读性能大幅提升。主要是由于有足够的内存使得其所有读操作都几乎是在内存中进行。

B. 无压缩的读操作

下面结果是我们对预先无压缩状态写入的100万条key为16字节、value为100字节的数据后进行的读性能测试。同样的 SQLite 由于不支持压缩,所以下面数据是直接从其基本测试上copy过来的。

结果可以看到,取消压缩对读取性能提升不是特别大,当然,如果你的数据都在内存中的话,执行解压操作也不会对性能造成太大影响。

相关文章推荐

Linux查看系统开机时间

有时候需要查看Linux系统运行了多久时间,此时需要知道上次开机启动时间; 有时候由于断电或供电故障突然停机,需要查看Linux开机时间/重启时间; 下面总结一些查看Linux开机关机时间的方法(非...
  • jwq2011
  • jwq2011
  • 2017年03月31日 08:59
  • 566

C++的iostream标准库介绍+使用详解(转)

0 为什么需要iostream 我们从一开始就一直在利用C++的输入输出在做着各种练习,输入输出是由iostream库提供的,所以讨论此标准库是有必要的,它与C语言的 stdio库不同,它从一开始就是...

SQLite3在swift3.0性能测试

https://github.com/targetcloud/SQLite3DemoSwift3 结论:用BATCH性能最好(事务+预处理),swift3.0的写法有许多地方需要注意,本文也包括了S...
  • callzjy
  • callzjy
  • 2016年12月07日 04:25
  • 1244

SQLite3开启事务和关闭事务模式下,性能测试对比

最近学习了下SQLite数据库基本知识,想了解下这款小巧的数据库,性能到底怎样,于是写个性能测试程序,对 SQLite3 最新发布版(3.7.13)在Linux平台进行了测试。最后发现在开启事务模式和...

core-data和sqlite3性能对比demo

  • 2013年06月18日 14:10
  • 1.56MB
  • 下载

SQLite3的性能优化

  • 2014年11月11日 15:01
  • 21KB
  • 下载

关于sqlite3的性能(转自:http://hi.baidu.com/snailzone/blog/item/da9368662bc94f25aa184c2b.html)

我想对于80%的网站来说,它们的数据量采用access数据库已经足够了。使用mysql或者sqlserver这些中型数据库,往往需要增加额外的使用费,而且数据量不大的时候,它们所反映的性能跟acces...
  • lslxdx
  • lslxdx
  • 2011年11月06日 16:38
  • 1458

sqlite3_test 测试程序

  • 2014年09月03日 15:33
  • 4KB
  • 下载

sqlite3 c API 测试程序

  • 2015年05月22日 10:10
  • 806KB
  • 下载

SQLite3性能优化

SQLite3性能调整主要通过pragma指令来实现。 比如调整:空间释放、磁盘同步、Cache大小等。 一.空间释放 1.如何查询: PRAGMA auto_vacuum; 含义:查询数据...
  • tietao
  • tietao
  • 2011年10月20日 13:22
  • 9441
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:LevelDB、TreeDB、SQLite3性能对比测试
举报原因:
原因补充:

(最多只允许输入30个字)