內(nèi)存數(shù)據(jù)庫FastDB和SQLite性能測評

1、在很多項(xiàng)目中，經(jīng)常會(huì)碰到這樣的需求，需要對大量數(shù)據(jù)進(jìn)行快速存儲(chǔ)、查詢、刪除等操作， 特別是在一些針對諸如運(yùn)營商、銀行等大型企業(yè)的應(yīng)用中，這些需求尤為常見。比如智能網(wǎng) 中的大量在線并發(fā)用戶的數(shù)據(jù)管理、軟交換平臺中的在線信息交互、寬帶/3G等數(shù)據(jù)網(wǎng)中在 線用戶行為記錄等等。針對這些情形，我們通常需要選擇高性能的數(shù)據(jù)庫產(chǎn)品，而且通常需要使用內(nèi)存數(shù)據(jù)庫，顧 名思義，內(nèi)存數(shù)據(jù)庫指的是所有的數(shù)據(jù)訪問控制都在內(nèi)存中進(jìn)行，這是與磁盤數(shù)據(jù)庫相對而 言的，磁盤數(shù)據(jù)庫雖然也有一定的緩存機(jī)制，但都不能避免從外設(shè)到內(nèi)存的交換，而這種交 換過程對性能的損耗是致命的，目前主流數(shù)據(jù)庫如SYBASE、ORACLE等都有這種緩存

2、機(jī)制， 如將特定表綁定一定的緩存，從而在一定程度上改善數(shù)據(jù)吞吐性能。而內(nèi)存數(shù)據(jù)庫幾乎可以 完全避免這種內(nèi)外存數(shù)據(jù)交換的發(fā)生，特別是在物理內(nèi)存足夠大的設(shè)備上尤其如此，通常這 種數(shù)據(jù)庫也被稱為主存數(shù)據(jù)庫(Main Memory DataBase, MMDB)。二、主存數(shù)據(jù)庫比較目前比較知名的商業(yè)內(nèi)存數(shù)據(jù)庫有，ORACLE的TimesTen，MCObject的eXtremeDB、韓國的 Altibase等，這些數(shù)據(jù)庫產(chǎn)品性能都非常的強(qiáng)勁，當(dāng)然價(jià)格也相當(dāng)?shù)膹?qiáng)勁，在非特大型系統(tǒng) 建設(shè)時(shí)，通常讓人望而卻步。于是退而求其次，免費(fèi)開源內(nèi)存數(shù)據(jù)庫給了我們第二種選擇。 Berkeley DB，SQLite，Mon

3、etDB， FastDB， H2 等，不一而足。本文主要針對 SQLite 和 FastDB 進(jìn)行性能測評。2.1測試準(zhǔn)備首先，筆者通過對評測數(shù)據(jù)的調(diào)研發(fā)現(xiàn)，通常認(rèn)為，BDB性能不如SQLite。上文中還提到，“據(jù)說FastDB很快，但數(shù)據(jù)庫大小不能大于物理內(nèi)存.;，于是筆者對 FastDB產(chǎn)生了興趣，從FastDB作者的網(wǎng)站看到關(guān)于這點(diǎn)的介紹，并不是說數(shù)據(jù)庫大小不能 大于物理內(nèi)存，而是說數(shù)據(jù)庫大小超過物理內(nèi)存時(shí)，性能與不超過時(shí)相比會(huì)有一定的降低(降 低幅度未作說明，估計(jì)是不推薦使用)。幸運(yùn)地是，目前物理內(nèi)存實(shí)在說不上貴，服務(wù)器內(nèi) 存在10G之上都是很正常的事情了。因此可以根據(jù)具體項(xiàng)目數(shù)據(jù)量需

4、求來確定是否能使用 FastDB，比如并不是所有的表都需要放在內(nèi)存中。下面即將描述的測試表明，一旦使用FastDB， 其性能在免費(fèi)MMDB產(chǎn)品中絕對可執(zhí)牛耳。由于已經(jīng)有人對BDB和SQLite進(jìn)行過比較，因 此下面僅將FastDB與其中的優(yōu)勝者SQLite進(jìn)行性能測評。SQLite采用內(nèi)存模式，即打開數(shù) 據(jù)庫使使用:memory:參數(shù)，此時(shí)SQLite不產(chǎn)生數(shù)據(jù)庫文件，所有操作都在內(nèi)存中，這一點(diǎn) 需要特殊說明，與之不同的是，F(xiàn)astDB有兩種模式，磁盤模式和無盤模式，前者會(huì)產(chǎn)生磁盤 文件，后者則與SQLite的內(nèi)存模式相同。說是測評，其實(shí)過程也很簡單，無非是設(shè)計(jì)測試CASE，編寫測試CODE，

5、輸出測試RESULT， 最后做出結(jié)論。通常我們認(rèn)為帶索引的插入耗時(shí)相對于查詢和刪除來說比較長，因此首先來 看插入性能。采用一個(gè)簡單的表來完成接下來的所有測試，表中僅包含兩個(gè)字段，INTEGER intKey，和 VARCHAR strKey。測試平臺為 Window? 32bit 系統(tǒng)(Evaluation Copy 7127)，編譯器 VC6 SP6。在 DELL INSPIRON 640m 上運(yùn)行，CPU 為 Intel Core 2 CPU T5500 1.66GHZ，內(nèi)存 2.5G。對FastDB(采用磁盤模式)，表結(jié)構(gòu)的定義如下：class _TestTablepublic:db_i

6、nt8 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不同事務(wù)模式下的插入性能比較2.2.1 FastDB磁盤模式我們首先按照批量事務(wù)處理的模式將intKey從1到nRecords（記錄條數(shù)），并指定相應(yīng)的strKey，

7、分別調(diào)用相應(yīng)的接口（均為原始API）插入到兩張表中，這里的批量事務(wù)處理模式指的是，比 如插入10000條記錄，插第一條之前開始事務(wù)，最后一條之后結(jié)束事務(wù)。此時(shí)在插入不同數(shù) 目記錄時(shí)的表現(xiàn)分別如下（一萬條、十萬條、72萬條、一百萬條）：批量事務(wù)提交：E:intrestFastDBPerfTestDebugWerfTest.exeFASTDB Elapsed time for inserting 10000 record: 63 msSQLITE Elapsed time for inserting 10000 record: 639 msE:intrestFastDBPerfTestDebugd

8、el *.fdb 清除測試生成數(shù)據(jù)，重新測試，下同。）E:intrestFastDBPerfTestDebugWerfTest.exeFASTDB Elapsed time for inserting 100000 record: 1186 msSQLITE Elapsed time for inserting 100000 record: 6318 msE:intrestFastDBPerfTestDebugdel *.fdbE:intrestFastDBPerfTestDebugWerfTest.exeFASTDB Elapsed time for inserting 7200000 re

9、cord: 152460 msSQLITE Elapsed time for inserting 7200000 record: 560121 msE:intrestFastDBPerfTestDebugWerfTest.exeFASTDB Elapsed time for inserting 1000000 record: 15522 msSQLITE Elapsed time for inserting 1000000 record: 67423 ms從上我們可以看出，在批量事務(wù)模式下，F(xiàn)astDB比SQLite的插入性能提高了 3-10倍。但是 在很多情況下，我們可能會(huì)需要逐條逐條的事務(wù)

10、提交，下面給出了逐條事務(wù)模式的測試結(jié)果： E:intrestFastDBPerfTestDebugPerfTest.exeFASTDB Elapsed time for inserting 10000 record: 57315 ms （這個(gè)太恐怖了，不調(diào)整的話沒法 使用）SQLITE Elapsed time for inserting 10000 record: 780 msE:intrestFastDBPerfTestDebugWerfTest.exe （SQLITE 顯式分條事務(wù)）FASTDB Elapsed time for inserting 10000 record: 59967

11、 msSQLITE Elapsed time for inserting 10000 record: 1154 ms從上我們可以看出，F(xiàn)astDB在這種情形下的性能急遽降低，降到一個(gè)幾乎不能接收的水平。 經(jīng)過對FastDB的源代碼分析（開源的好處體現(xiàn)出來了），發(fā)現(xiàn)FastDB在每次事務(wù)提交時(shí)，都 會(huì)將變更的數(shù)據(jù)內(nèi)容同步到磁盤文件中（這是因?yàn)槲覀儾捎昧舜疟P模式），因此造成性能的 顯著降低。直觀上看，解決FastDB的這個(gè)問題有兩種辦法，一是避免每次事務(wù)提交時(shí)同步到磁盤，因 為在這種應(yīng)用中，這種同步操作并不需要實(shí)時(shí)進(jìn)行，通常每隔一段時(shí)間同步一次就可以了 （比 如1S、1Min、等根據(jù)具體項(xiàng)目的可靠

12、性需要）；二是使用前面提到的FastDB無盤（DISKLESS） 模式。我們首先來看第一種方案，通過SEARCH FastDB文檔（文檔和社區(qū)是FastDB的一個(gè)軟肋），我 們發(fā)現(xiàn)作者已經(jīng)考慮到了這個(gè)問題，F(xiàn)astDB為數(shù)據(jù)庫提供了 precommit的接口，用于完成除 sync到磁盤文件外的所有事物操作，如釋放mutex資源等。同時(shí)提供了 backup接口，用來 完成內(nèi)存數(shù)據(jù)到磁盤文件的備份，甚至支持打開數(shù)據(jù)庫時(shí)同時(shí)指定定時(shí)備份到磁盤文件的間 隔。這樣一來，每次事務(wù)提交的效率理論上會(huì)得到大大提高，并且通過定時(shí)備份機(jī)制可以保 證數(shù)據(jù)的可靠性。我們來看使用precommit進(jìn)行逐條事務(wù)提交時(shí)Fa

13、stDB的表現(xiàn)： E:intrestFastDBPerfTestDebugPerfTest(使用 precommit 逐條提交事務(wù))FASTDB Elapsed time for inserting 10000 record: 62 msSQLITE Elapsed time for inserting 10000 record: 1170 msE:intrestFastDBPerfTestDebugPerfTestFASTDB Elapsed time for inserting 100000 record: 1170 msSQLITE Elapsed time for inserting

14、100000 record: 11747 msE:intrestFastDBPerfTestDebugPerfTestFASTDB Elapsed time for inserting 1000000 record: 8081 msSQLITE Elapsed time for inserting 1000000 record: 125768 ms從上可以看出，在逐條事務(wù)模式下，通過使用precommit技術(shù)，F(xiàn)astDB性能比SQLite提高 了 10倍左右。當(dāng)然也許有讀者懷疑加了備份機(jī)制之后的性能，確實(shí)筆者沒有進(jìn)行這項(xiàng)測試， 但是，需要注意的是，F(xiàn)astDB在數(shù)據(jù)庫關(guān)閉時(shí)會(huì)強(qiáng)制sync到磁

15、盤文件，但SQLite沒有這種 功能，同時(shí)，在進(jìn)行這項(xiàng)測試時(shí)，兩種數(shù)據(jù)庫都沒有定時(shí)備份機(jī)制，因此該比較是公平的。2.2.2 FastDB無盤模式再來看第二種方案，F(xiàn)astDB采用無盤(通過編譯選項(xiàng)控制生成DISKLESS版本)模式，此時(shí)FastDB 初始化一段共享內(nèi)存(shmat or mmap)，這個(gè)初始大小通常很大，并且運(yùn)行期不能擴(kuò)展(無 盤模式的劣勢)。我們將初始共享內(nèi)存設(shè)置為1G，得到的測試結(jié)果如下：E:intrestFastDBPerfTestDebugPerfTest.exeFASTDB Elapsed time for inserting 100000 record: 624 m

16、s 批量事務(wù)提交)SQLITE Elapsed time for inserting 100000 record: 11544 msE:intrestFastDBPerfTestDebugPerfTest.exeFASTDB Elapsed time for inserting 100000 record: 7410 ms 逐條事務(wù)提交)SQLITE Elapsed time for inserting 100000 record: 11560 msE:intrestFastDBPerfTestDebugWerfTest.exeFASTDB Elapsed time for inserting

17、 1000000 record: 134660 msSQLITE Elapsed time for inserting 1000000 record: 120167 msE:intrestFastDBPerfTestDebugWerfTest.exeFASTDB Elapsed time for inserting 250000 record: 23666 msSQLITE Elapsed time for inserting 250000 record: 29110 ms從上我們可以看出，無盤模式在大數(shù)據(jù)量下的表現(xiàn)與SQLite相近，這一點(diǎn)不是很好理解， 需要研究DISKLESS的設(shè)計(jì)模式，

18、理論上應(yīng)該與precommit模式性能相近。但是實(shí)踐是檢驗(yàn) 真理的唯一標(biāo)準(zhǔn)。我們可以看出，磁盤模式的precommit方式性能表現(xiàn)卓越，不管從橫向還 是縱向來看。2.3查詢性能比較下面的比較都使用磁盤模式的precommit方式，再來看索引查詢的性能表現(xiàn)，測試時(shí)都是先 插入十萬條數(shù)據(jù)后，再分別對該十萬條數(shù)據(jù)進(jìn)行查詢，需要注意的是我們同時(shí)對FastDB是 否增加HASH索引的性能進(jìn)行了橫向測評，F(xiàn)astDB增加HASH索引很簡單，通過修改TYPEDESCRIPTOR 來完成，上面的 class 中改為 TYPE_DESCRIPTOR(KEY(intKey, INDEXED), KEY(strKe

19、y, INDEXED);即為 intKey 增加了 Hash 索引。E:intrestFastDBPerfTestDebugperftest （FASTDB哈 希索弓 I）FASTDB Elapsed time for inserting 100000 record: 624 msFASTDB Elapsed time for 100000 index searches: 328 msSQLITE Elapsed time for inserting 100000 record: 10312 msSQLITE Elapsed time for 100000 index searches: 10

20、935 msE:intrestFastDBPerfTestDebugperftest（FASTDB非 哈希索引）FASTDB Elapsed time for inserting 100000 record: 577 msFASTDB Elapsed time for 100000 index searches: 515 msSQLITE Elapsed time for inserting 100000 record: 10343 msSQLITE Elapsed time for 100000 index searches: 9532 ms從測試結(jié)果可以看出，查詢十萬條索引記錄的效率，F(xiàn)a

21、stDB要比SQLite快20倍左右，并且 在增加HASH索引后能夠得到進(jìn)一步的改善。2.4刪除性能比較及綜合表現(xiàn)最后，我們在測試刪除效率時(shí)，同時(shí)綜合來看FastDB與SQLite之間插入、查詢、刪除的性 能表現(xiàn)：插入、查詢、刪除綜合比較：E:intrestFastDBPerfTestDebugperftest （批量刪除，F(xiàn)ASTDB.removeall（）, SQLITE.delete*）FASTDB Elapsed time for inserting 100000 record: 608 msFASTDB Elapsed time for 100000 index searches:

22、687 msFASTDB Elapsed time for deleting all 100000 records: 16 msSQLITE Elapsed time for inserting 100000 record: 11107 msSQLITE Elapsed time for 100000 index searches: 10062 msSQLITE Elapsed time for deleting all 100000 records: 16 msE:intrestFastDBPerfTestDebugperftest （逐條刪除）FASTDB Elapsed time for inserting 100000 record: 593 msFAST