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

《内存数据库FastDB和SQLite性能测评》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。

1、一、引言在很多项目中，经常会碰到这样的需求，需要对大量数据进行快速存储、查询、删除等操作，特别是在一些针对诸如运营商、银行等大型企业的应用中，这些需求尤为常见。比如智能网中的大量在线并发用户的数据管理、软交换平台中的在线信息交互、宽带/3G等数据网中在线用户行为记录等等。针对这些情形，我们通常需要选择高性能的数据库产品，而且通常需要使用内存数据库，顾名思义，内存数据库指的是所有的数据访问控制都在内存中进行，这是与磁盘数据库相对而言的，磁盘数据库虽然也有一定的缓存机制，但都不能避免从外设到内存的交换，而这种交换过程对性能的损耗是致命的，

2、目前主流数据库如SYBASE、ORACLE等都有这种缓存机制，如将特定表绑定一定的缓存，从而在一定程度上改善数据吞吐性能。而内存数据库几乎可以完全避免这种内外存数据交换的发生，特别是在物理内存足够大的设备上尤其如此，通常这种数据库也被称为主存数据库(MainMemoryDataBase,MMDB)。二、主存数据库比较目前比较知名的商业内存数据库有，ORACLE的TimesTen，MCObject的eXtremeDB、韩国的Altibase等，这些数据库产品性能都非常的强劲，当然价格也相当的强劲，在非特大型系统建设时，通常让人望而却步。

3、于是退而求其次，免费开源内存数据库给了我们第二种选择。BerkeleyDB，SQLite，MonetDB，FastDB，H2等，不一而足。本文主要针对SQLite和FastDB进行性能测评。2.1测试准备首先，笔者通过对评测数据的调研发现，通常认为，BDB性能不如SQLite。上文中还提到，“据说FastDB很快，但数据库大小不能大于物理内存...;，于是笔者对FastDB产生了兴趣，从FastDB作者的网站看到关于这点的介绍，并不是说数据库大小不能大于物理内存，而是说数据库大小超过物理内存时，性能与不超过时相比会有一定的

4、降低(降低幅度未作说明，估计是不推荐使用)。幸运地是，目前物理内存实在说不上贵，服务器内存在10G之上都是很正常的事情了。因此可以根据具体项目数据量需求来确定是否能使用FastDB，比如并不是所有的表都需要放在内存中。下面即将描述的测试表明，一旦使用FastDB，其性能在免费MMDB产品中绝对可执牛耳。由于已经有人对BDB和SQLite进行过比较，因此下面仅将FastDB与其中的优胜者SQLite进行性能测评。SQLite采用内存模式，即打开数据库使使用":memory:"参数，此时SQLite不产生数据库文件，所有操作都在内存中，这

5、一点需要特殊说明，与之不同的是，FastDB有两种模式，磁盘模式和无盘模式，前者会产生磁盘文件，后者则与SQLite的内存模式相同。说是测评，其实过程也很简单，无非是设计测试CASE，编写测试CODE，输出测试RESULT，最后做出结论。通常我们认为带索引的插入耗时相对于查询和删除来说比较长，因此首先来看插入性能。采用一个简单的表来完成接下来的所有测试，表中仅包含两个字段，INTEGERintKey，和VARCHARstrKey。测试平台为Window732bit系统(EvaluationCopy7127)，编译器VC6SP6。在DE

6、LLINSPIRON640m上运行，CPU为IntelCore2CPUT5500@1.66GHZ，内存2.5G。对FastDB（采用磁盘模式），表结构的定义如下：class_TestTable{public:db_int8intKey;charconst*strKey;TYPE_DESCRIPTOR((KEY(intKey,INDEXED),KEY(strKey,INDEXED)));};REGISTER(_TestTable);对SQLite，建表SQL如下：CREATETABLE[_TestTable]([intKey]INTEG

7、ERNOTNULLPRIMARYKEY,[strKey]VARCHAR(50)NULL)2.2不同事务模式下的插入性能比较2.2.1FastDB磁盘模式我们首先按照批量事务处理的模式将intKey从1到nRecords(记录条数)，并指定相应的strKey，分别调用相应的接口(均为原始API)插入到两张表中，这里的批量事务处理模式指的是，比如插入10000条记录，插第一条之前开始事务，最后一条之后结束事务。此时在插入不同数目记录时的表现分别如下(一万条、十万条、72万条、一百万条)：批量事务提交：E:intrestFastDBP

8、erfTestDebug>PerfTest.exe[FASTDB]Elapsedtimeforinserting10000record:63ms[SQLITE]Elapsedtimeforinserting10000r