fastdb_fastdb快_fastdb redis(3)

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，得到的测试结果如下：

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-22882-3.html