登录 注册

内存数据库FastDB和SQLite性能测评

本贴最后更新于 3900 天前，其中的信息可能已经水流花落

一、引言

在很多项目中，经常会碰到这样的需求，需要对大量数据进行快速存储、查询、删除等操作，特别是在一些针对诸如运营商、银行等大型企业的应用中，这些 需求尤为常见。比如智能网中的大量在线并发用户的数据管理、软交换平台中的在线信息交互、宽带/3G等数据网中在线用户行为记录等等。

针对这些情形，我们通常需要选择高性能的数据库产品，而且通常需要使用内存数据库，顾名思义，内存数据库指的是所有的数据访问控制都在内存中进行， 这是与磁盘数据库相对而言的，磁盘数据库虽然也有一定的缓存机制，但都不能避免从外设到内存的交换，而这种交换过程对性能的损耗是致命的，目前主流数据库 如SYBASE、ORACLE等都有这种缓存机制，如将特定表绑定一定的缓存，从而在一定程度上改善数据吞吐性能。而内存数据库几乎可以完全避免这种内外 存数据交换的发生，特别是在物理内存足够大的设备上尤其如此，通常这种数据库也被称为主存数据库(Main Memory DataBase, MMDB)。

二、主存数据库比较

目前比较知名的商业内存数据库有，ORACLE的TimesTen，MCObject的eXtremeDB、韩国的Altibase等，这些数据库 产品性能都非常的强劲，当然价格也相当的强劲，在非特大型系统建设时，通常让人望而却步。于是退而求其次，免费开源内存数据库给了我们第二种选择。 Berkeley DB，SQLite，MonetDB，FastDB，H2等，不一而足。本文主要针对SQLite和FastDB进行性能测评。

2.1 测试准备

首先，笔者通过对评测数据的调研发现，通常认为，BDB性能不如SQLite，参考"免费的实时数据库，我们该选谁？---BerkeleyDB与SQLite评测对比 "。

上文中还提到，"据说FastDB很快，但数据库大小不能大于物理内存..."，于是笔者对FastDB产生了兴趣，从FastDB作者的网站看到关于 这点的介绍，并不是说数据库大小不能大于物理内存，而是说数据库大小超过物理内存时，性能与不超过时相比会有一定的降低(降低幅度未作说明，估计是不推荐 使用)。幸运地是，目前物理内存实在说不上贵，服务器内存在10G之上都是很正常的事情了。因此可以根据具体项目数据量需求来确定是否能使用 FastDB，比如并不是所有的表都需要放在内存中。下面即将描述的测试表明，一旦使用FastDB，其性能在免费MMDB产品中绝对可执牛耳。由于已经 有人对BDB和SQLite进行过比较，因此下面仅将FastDB与其中的优胜者SQLite进行性能测评。SQLite采用内存模式，即打开数据库使使 用":memory:"参数，此时SQLite不产生数据库文件，所有操作都在内存中，这一点需要特殊说明，与之不同的是，FastDB有两种模式，磁盘 模式和无盘模式，前者会产生磁盘文件，后者则与SQLite的内存模式相同。

说是测评，其实过程也很简单，无非是设计测试CASE，编写测试CODE，输出测试RESULT，最后做出结论。通常我们认为带索引的插入耗时相对 于查询和删除来说比较长，因此首先来看插入性能。采用一个简单的表来完成接下来的所有测试，表中仅包含两个字段，INTEGER intKey，和VARCHAR strKey。测试平台为Window7 32bit系统(Evaluation Copy 7127)，编译器VC6 SP6。在DELL INSPIRON 640m上运行，CPU为Intel Core 2 CPU T5500 @ 1.66GHZ，内存2.5G。

对FastDB（采用磁盘模式），表结构的定义如下：

class _TestTable 
{ 
public: 
    db_int8 intKey; 
    char const* strKey; 
    TYPE_DESCRIPTOR((KEY(intKey, INDEXED), KEY(strKey, INDEXED))); 
};

REGISTER(_TestTable);

对SQLite，建表SQL如下：

CREATE TABLE [_TestTable] ( [intKey] INTEGER  NOT NULL PRIMARY KEY, [strKey] VARCHAR(50)  NULL)

2.2 不同事务模式下的插入性能比较

2.2.1 FastDB磁盘模式

我们首先按照批量事务处理的模式将intKey从1到nRecords(记录条数)，并指定相应的strKey，分别调用相应的接口(均为原始 API)插入到两张表中，这里的批量事务处理模式指的是，比如插入10000条记录，插第一条之前开始事务，最后一条之后结束事务。此时在插入不同数目记 录时的表现分别如下(一万条、十万条、72万条、一百万条)：

批量事务提交：

E:\intrest\FastDB\PerfTest\Debug>PerfTest.exe 
[FASTDB] Elapsed time for inserting 10000 record: 63 ms 
[SQLITE] Elapsed time for inserting 10000 record: 639 ms

E:\intrest\FastDB\PerfTest\Debug>del *.fdb (清除测试生成数据，重新测试，下同。)

E:\intrest\FastDB\PerfTest\Debug>PerfTest.exe 
[FASTDB] Elapsed time for inserting 100000 record: 1186 ms 
[SQLITE] Elapsed time for inserting 100000 record: 6318 ms

E:\intrest\FastDB\PerfTest\Debug>del *.fdb

E:\intrest\FastDB\PerfTest\Debug>PerfTest.exe 
[FASTDB] Elapsed time for inserting 7200000 record: 152460 ms 
[SQLITE] Elapsed time for inserting 7200000 record: 560121 ms

E:\intrest\FastDB\PerfTest\Debug>PerfTest.exe 
[FASTDB] Elapsed time for inserting 1000000 record: 15522 ms 
[SQLITE] Elapsed time for inserting 1000000 record: 67423 ms

从上我们可以看出，在批量事务模式下，FastDB比SQLite的插入性能提高了3-10倍。但是在很多情况下，我们可能会需要逐条逐条的事务提交，下面给出了逐条事务模式的测试结果：

E:\intrest\FastDB\PerfTest\Debug>PerfTest.exe 
[FASTDB] Elapsed time for inserting 10000 record: 57315 ms（这个太恐怖了，不调整的话没法使用） 
[SQLITE] Elapsed time for inserting 10000 record: 780 ms

E:\intrest\FastDB\PerfTest\Debug>PerfTest.exe （SQLITE显式分条事务） 
[FASTDB] Elapsed time for inserting 10000 record: 59967 ms 
[SQLITE] Elapsed time for inserting 10000 record: 1154 ms

从上我们可以看出，FastDB在这种情形下的性能急遽降低，降到一个几乎不能接收的水平。经过对FastDB的源代码分析(开源的好处体现出来 了)，发现FastDB在每次事务提交时，都会将变更的数据内容同步到磁盘文件中（这是因为我们采用了磁盘模式），因此造成性能的显著降低。

直观上看，解决FastDB的这个问题有两种办法，一是避免每次事务提交时同步到磁盘，因为在这种应用中，这种同步操作并不需要实时进行，通常每隔 一段时间同步一次就可以了(比如1S、1Min、等根据具体项目的可靠性需要)；二是使用前面提到的FastDB无盘(DISKLESS)模式。

我们首先来看第一种方案，通过SEARCH FastDB文档(文档和社区是FastDB的一个软肋)，我们发现作者已经考虑到了这个问题，FastDB为数据库提供了precommit的接口，用 于完成除sync到磁盘文件外的所有事物操作，如释放mutex资源等。同时提供了backup接口，用来完成内存数据到磁盘文件的备份，甚至支持打开数 据库时同时指定定时备份到磁盘文件的间隔。这样一来，每次事务提交的效率理论上会得到大大提高，并且通过定时备份机制可以保证数据的可靠性。我们来看使用 precommit进行逐条事务提交时FastDB的表现：

E:\intrest\FastDB\PerfTest\Debug>PerfTest（使用precommit逐条提交事务） 
[FASTDB] Elapsed time for inserting 10000 record: 62 ms 
[SQLITE] Elapsed time for inserting 10000 record: 1170 ms

E:\intrest\FastDB\PerfTest\Debug>PerfTest 
[FASTDB] Elapsed time for inserting 100000 record: 1170 ms 
[SQLITE] Elapsed time for inserting 100000 record: 11747 ms

E:\intrest\FastDB\PerfTest\Debug>PerfTest 
[FASTDB] Elapsed time for inserting 1000000 record: 8081 ms 
[SQLITE] Elapsed time for inserting 1000000 record: 125768 ms

从上可以看出，在逐条事务模式下，通过使用precommit技术，FastDB性能比SQLite提高了10倍左右。当然也许有读者怀疑加了备份 机制之后的性能，确实笔者没有进行这项测试，但是，需要注意的是，FastDB在数据库关闭时会强制sync到磁盘文件，但SQLite没有这种功能，同 时，在进行这项测试时，两种数据库都没有定时备份机制，因此该比较是公平的。

2.2.2 FastDB无盘模式

再来看第二种方案，FastDB采用无盘(通过编译选项控制生成DISKLESS版本)模式，此时FastDB初始化一段共享内存(shmat or mmap)，这个初始大小通常很大，并且运行期不能扩展（无盘模式的劣势）。我们将初始共享内存设置为1G，得到的测试结果如下：

E:\intrest\FastDB\PerfTest\Debug>PerfTest.exe 
[FASTDB] Elapsed time for inserting 100000 record: 624 ms (批量事务提交) 
[SQLITE] Elapsed time for inserting 100000 record: 11544 ms

E:\intrest\FastDB\PerfTest\Debug>PerfTest.exe 
[FASTDB] Elapsed time for inserting 100000 record: 7410 ms (逐条事务提交) 
[SQLITE] Elapsed time for inserting 100000 record: 11560 ms

E:\intrest\FastDB\PerfTest\Debug>PerfTest.exe 
[FASTDB] Elapsed time for inserting 1000000 record: 134660 ms 
[SQLITE] Elapsed time for inserting 1000000 record: 120167 ms

E:\intrest\FastDB\PerfTest\Debug>PerfTest.exe 
[FASTDB] Elapsed time for inserting 250000 record: 23666 ms 
[SQLITE] Elapsed time for inserting 250000 record: 29110 ms

从上我们可以看出，无盘模式在大数据量下的表现与SQLite相近，这一点不是很好理解，需要研究DISKLESS的设计模式，理论上应该与 precommit模式性能相近。但是实践是检验真理的唯一标准。我们可以看出，磁盘模式的precommit方式性能表现卓越，不管从横向还是纵向来 看。

2.3 查询性能比较

下面的比较都使用磁盘模式的precommit方式，再来看索引查询的性能表现，测试时都是先插入十万条数据后，再分别对该十万条数据进行查询，需 要注意的是我们同时对FastDB是否增加HASH索引的性能进行了横向测评，FastDB增加HASH索引很简单，通过修改TYPE- DESCRIPTOR来完成，上面的class中改为TYPE_DESCRIPTOR((KEY(intKey, INDEXED), KEY(strKey, INDEXED)));即为intKey增加了Hash索引。

E:\intrest\FastDB\PerfTest\Debug>perftest (FASTDB哈希索引) 
[FASTDB] Elapsed time for inserting 100000 record: 624 ms 
[FASTDB] Elapsed time for 100000 index searches: 328 ms 
[SQLITE] Elapsed time for inserting 100000 record: 10312 ms 
[SQLITE] Elapsed time for 100000 index searches: 10935 ms

E:\intrest\FastDB\PerfTest\Debug>perftest(FASTDB非哈希索引) 
[FASTDB] Elapsed time for inserting 100000 record: 577 ms 
[FASTDB] Elapsed time for 100000 index searches: 515 ms 
[SQLITE] Elapsed time for inserting 100000 record: 10343 ms 
[SQLITE] Elapsed time for 100000 index searches: 9532 ms

从测试结果可以看出，查询十万条索引记录的效率，FastDB要比SQLite快20倍左右，并且在增加HASH索引后能够得到进一步的改善。

2.4 删除性能比较及综合表现

最后，我们在测试删除效率时，同时综合来看FastDB与SQLite之间插入、查询、删除的性能表现：

插入、查询、删除综合比较：

E:\intrest\FastDB\PerfTest\Debug>perftest（批量删除，FASTDB.removeall()，SQLITE.delete*） 
[FASTDB] Elapsed time for inserting 100000 record: 608 ms 
[FASTDB] Elapsed time for 100000 index searches: 687 ms 
[FASTDB] Elapsed time for deleting all 100000 records: 16 ms 
[SQLITE] Elapsed time for inserting 100000 record: 11107 ms 
[SQLITE] Elapsed time for 100000 index searches: 10062 ms 
[SQLITE] Elapsed time for deleting all 100000 records: 16 ms

E:\intrest\FastDB\PerfTest\Debug>perftest（逐条删除） 
[FASTDB] Elapsed time for inserting 100000 record: 593 ms 
[FASTDB] Elapsed time for 100000 index searches: 562 ms 
[FASTDB] Elapsed time for deleting all 100000 records one by one: 905 ms 
[SQLITE] Elapsed time for inserting 100000 record: 10406 ms 
[SQLITE] Elapsed time for 100000 index searches: 10249 ms 
[SQLITE] Elapsed time for deleting all 100000 records one by one: 8923 ms

从上可以看出，就删除效率而言，批量删除的速度二者相近，而逐条删除时，十万条记录的删除累积，FastDB比SQLite快了10倍左右。

 

2.5 总结

优点：FastDB磁盘模式下，采用precommit方式，性能远远优于SQLite，并且FastDB提供了完善的备份恢复机制，能够保证数据 安全。FastDB的无盘模式在小数据量时表现优越，并且不会产生磁盘数据文件，也不能加载已经保存的数据库文件，看起来更像是针对嵌入式设备(如智能手 机、PDA等)开发的，对于这种场景可以考虑使用无盘模式。

缺点：FastDB目前能够SEARCH到的比较著名的应用是PingTel公司的开源统一通信产品SIPX，该产品采用的是FastDB的磁盘模 式。这可能多少与FastDB的完全授权模式有关，而SQLite采用的是GPL的不允许闭源的商业发布。当然主要还是社区的不成熟，这从Google Trends的搜索结果也能看出。社区的不成熟会带来学习成本的增加，这一点在选型时也需要考虑。

  • FastDB
    1 引用
  • SQLite

    SQLite 是一个进程内的库，实现了自给自足的、无服务器的、零配置的、事务性的 SQL 数据库引擎。SQLite 是全世界使用最为广泛的数据库引擎。

    4 引用 • 7 回帖 • 1 关注
  • 数据库

    据说 99% 的性能瓶颈都在数据库。

    331 引用 • 615 回帖
1 赞同
3.4k 28 760 265 281 163 18 130 1.7k

相关帖子

回帖
内存数据库FastDB和SQLite性能测评

欢迎来到这里！

我们正在构建一个小众社区，大家在这里相互信任，以平等 • 自由 • 奔放的价值观进行分享交流。最终，希望大家能够找到与自己志同道合的伙伴，共同成长。

注册 关于
请输入回帖内容 ...
jetlan
回帖
5
 帖子
16
 积分
2080

近期热议

推荐标签 标签

  • 强迫症

    强迫症（OCD）属于焦虑障碍的一种类型，是一组以强迫思维和强迫行为为主要临床表现的神经精神疾病，其特点为有意识的强迫和反强迫并存，一些毫无意义、甚至违背自己意愿的想法或冲动反反复复侵入患者的日常生活。

    15 引用 • 161 回帖 • 1 关注
  • Caddy

    Caddy 是一款默认自动启用 HTTPS 的 HTTP/2 Web 服务器。

    10 引用 • 54 回帖 • 130 关注
  • MyBatis

    MyBatis 本是 Apache 软件基金会 的一个开源项目 iBatis，2010 年这个项目由 Apache 软件基金会迁移到了 google code，并且改名为 MyBatis ，2013 年 11 月再次迁移到了 GitHub。

    170 引用 • 414 回帖 • 432 关注
  • 锤子科技

    锤子科技（Smartisan）成立于 2012 年 5 月，是一家制造移动互联网终端设备的公司，公司的使命是用完美主义的工匠精神，打造用户体验一流的数码消费类产品（智能手机为主），改善人们的生活质量。

    4 引用 • 31 回帖 • 10 关注
  • golang

    Go 语言是 Google 推出的一种全新的编程语言，可以在不损失应用程序性能的情况下降低代码的复杂性。谷歌首席软件工程师罗布派克（Rob Pike）说：我们之所以开发 Go，是因为过去 10 多年间软件开发的难度令人沮丧。Go 是谷歌 2009 发布的第二款编程语言。

    491 引用 • 1383 回帖 • 369 关注
  • CSDN

    CSDN (Chinese Software Developer Network) 创立于 1999 年，是中国的 IT 社区和服务平台，为中国的软件开发者和 IT 从业者提供知识传播、职业发展、软件开发等全生命周期服务，满足他们在职业发展中学习及共享知识和信息、建立职业发展社交圈、通过软件开发实现技术商业化等刚性需求。

    14 引用 • 155 回帖
  • OAuth

    OAuth 协议为用户资源的授权提供了一个安全的、开放而又简易的标准。与以往的授权方式不同之处是 oAuth 的授权不会使第三方触及到用户的帐号信息（如用户名与密码），即第三方无需使用用户的用户名与密码就可以申请获得该用户资源的授权，因此 oAuth 是安全的。oAuth 是 Open Authorization 的简写。

    36 引用 • 103 回帖 • 4 关注
  • Scala

    Scala 是一门多范式的编程语言，集成面向对象编程和函数式编程的各种特性。

    13 引用 • 11 回帖 • 103 关注
  • Mobi.css

    Mobi.css is a lightweight, flexible CSS framework that focus on mobile.

    1 引用 • 6 回帖 • 693 关注
  • Git

    Git 是 Linux Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。

    205 引用 • 357 回帖
  • Kotlin

    Kotlin 是一种在 Java 虚拟机上运行的静态类型编程语言，由 JetBrains 设计开发并开源。Kotlin 可以编译成 Java 字节码，也可以编译成 JavaScript，方便在没有 JVM 的设备上运行。在 Google I/O 2017 中，Google 宣布 Kotlin 成为 Android 官方开发语言。

    19 引用 • 33 回帖 • 22 关注
  • Rust

    Rust 是一门赋予每个人构建可靠且高效软件能力的语言。Rust 由 Mozilla 开发，最早发布于 2014 年 9 月。

    57 引用 • 22 回帖
  • 钉钉

    钉钉，专为中国企业打造的免费沟通协同多端平台， 阿里巴巴出品。

    15 引用 • 67 回帖 • 373 关注
  • wolai

    我来 wolai：不仅仅是未来的云端笔记！

    1 引用 • 11 回帖 • 1 关注
  • frp

    frp 是一个可用于内网穿透的高性能的反向代理应用，支持 TCP、UDP、 HTTP 和 HTTPS 协议。

    15 引用 • 7 回帖 • 5 关注
  • Eclipse

    Eclipse 是一个开放源代码的、基于 Java 的可扩展开发平台。就其本身而言，它只是一个框架和一组服务，用于通过插件组件构建开发环境。

    75 引用 • 258 回帖 • 631 关注
  • OkHttp

    OkHttp 是一款 HTTP & HTTP/2 客户端库，专为 Android 和 Java 应用打造。

    16 引用 • 6 回帖 • 53 关注
  • 面试

    面试造航母，上班拧螺丝。多面试，少加班。

    324 引用 • 1395 回帖
  • V2Ray
    1 引用 • 15 回帖
  • Ubuntu

    Ubuntu（友帮拓、优般图、乌班图）是一个以桌面应用为主的 Linux 操作系统，其名称来自非洲南部祖鲁语或豪萨语的“ubuntu”一词，意思是“人性”、“我的存在是因为大家的存在”，是非洲传统的一种价值观，类似华人社会的“仁爱”思想。Ubuntu 的目标在于为一般用户提供一个最新的、同时又相当稳定的主要由自由软件构建而成的操作系统。

    123 引用 • 168 回帖 • 1 关注
  • InfluxDB

    InfluxDB 是一个开源的没有外部依赖的时间序列数据库。适用于记录度量，事件及实时分析。

    2 引用 • 54 关注
  • 微信

    腾讯公司 2011 年 1 月 21 日推出的一款手机通讯软件。用户可以通过摇一摇、搜索号码、扫描二维码等添加好友和关注公众平台，同时可以将自己看到的精彩内容分享到微信朋友圈。

    129 引用 • 793 回帖
  • 国际化

    i18n（其来源是英文单词 internationalization 的首末字符 i 和 n，18 为中间的字符数）是“国际化”的简称。对程序来说，国际化是指在不修改代码的情况下，能根据不同语言及地区显示相应的界面。

    7 引用 • 26 回帖 • 2 关注
  • Gzip

    gzip （GNU zip）是 GNU 自由软件的文件压缩程序。我们在 Linux 中经常会用到后缀为 .gz 的文件，它们就是 Gzip 格式的。现今已经成为互联网上使用非常普遍的一种数据压缩格式，或者说一种文件格式。

    9 引用 • 12 回帖 • 110 关注
  • Flume

    Flume 是一套分布式的、可靠的，可用于有效地收集、聚合和搬运大量日志数据的服务架构。

    9 引用 • 6 回帖 • 591 关注
  • jsoup

    jsoup 是一款 Java 的 HTML 解析器，可直接解析某个 URL 地址、HTML 文本内容。它提供了一套非常省力的 API，可通过 DOM，CSS 以及类似于 jQuery 的操作方法来取出和操作数据。

    6 引用 • 1 回帖 • 459 关注
  • 持续集成

    持续集成（Continuous Integration）是一种软件开发实践，即团队开发成员经常集成他们的工作，通过每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。

    14 引用 • 7 回帖

最新标签