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

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

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

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

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

5、輸出測試RESULT， 最后做出結論。通常我們認為帶索引的插入耗時相對于查詢和刪除來說比較長，因此首先來 看插入性能。采用一個簡單的表來完成接下來的所有測試，表中僅包含兩個字段，INTEGER intKey，和 VARCHAR strKey。測試平臺為 Window? 32bit 系統(tǒng)(Evaluation Copy 7127)，編譯器 VC6 SP6。在 DELL INSPIRON 640m 上運行，CPU 為 Intel Core 2 CPU T5500 1.66GHZ，內存 2.5G。對FastDB(采用磁盤模式)，表結構的定義如下：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不同事務模式下的插入性能比較2.2.1 FastDB磁盤模式我們首先按照批量事務處理的模式將intKey從1到nRecords（記錄條數(shù)），并指定相應的strKey，

7、分別調用相應的接口（均為原始API）插入到兩張表中，這里的批量事務處理模式指的是，比 如插入10000條記錄，插第一條之前開始事務，最后一條之后結束事務。此時在插入不同數(shù) 目記錄時的表現(xiàn)分別如下（一萬條、十萬條、72萬條、一百萬條）：批量事務提交：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從上我們可以看出，在批量事務模式下，F(xiàn)astDB比SQLite的插入性能提高了 3-10倍。但是 在很多情況下，我們可能會需要逐條逐條的事務

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

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

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

13、stDB的表現(xiàn)： E:intrestFastDBPerfTestDebugPerfTest(使用 precommit 逐條提交事務)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從上可以看出，在逐條事務模式下，通過使用precommit技術，F(xiàn)astDB性能比SQLite提高 了 10倍左右。當然也許有讀者懷疑加了備份機制之后的性能，確實筆者沒有進行這項測試， 但是，需要注意的是，F(xiàn)astDB在數(shù)據(jù)庫關閉時會強制sync到磁

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

16、s 批量事務提交)SQLITE Elapsed time for inserting 100000 record: 11544 msE:intrestFastDBPerfTestDebugPerfTest.exeFASTDB Elapsed time for inserting 100000 record: 7410 ms 逐條事務提交)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相近，這一點不是很好理解， 需要研究DISKLESS的設計模式，

18、理論上應該與precommit模式性能相近。但是實踐是檢驗 真理的唯一標準。我們可以看出，磁盤模式的precommit方式性能表現(xiàn)卓越，不管從橫向還 是縱向來看。2.3查詢性能比較下面的比較都使用磁盤模式的precommit方式，再來看索引查詢的性能表現(xiàn)，測試時都是先 插入十萬條數(shù)據(jù)后，再分別對該十萬條數(shù)據(jù)進行查詢，需要注意的是我們同時對FastDB是 否增加HASH索引的性能進行了橫向測評，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從測試結果可以看出，查詢十萬條索引記錄的效率，F(xiàn)a

21、stDB要比SQLite快20倍左右，并且 在增加HASH索引后能夠得到進一步的改善。2.4刪除性能比較及綜合表現(xiàn)最后，我們在測試刪除效率時，同時綜合來看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