記憶體資料庫fastdb的效能測試報告
【從我原來blog搬來的】
IBM AIX 伺服器上
<一>利用SUBSQL介面手工進行測試
----------<Some test Data>-----------------------------------------
1.Record(int4,char const*)
dbDatabase db(dbDatabase::dbAllAccess, 16*1024); // 96Mb page pool
Insert 50000 records,elapsed time: 1 seconds
Insert 100000 records,elapsed time: 2 seconds
insert 1000000 records,elapsed time: 9 seconds
Insert 10000000 records,elapsed time: 120 seconds
dbDatabase db(dbDatabase::dbAllAccess, 160*1024); // 960Mb page pool
Insert 50000 records,elapsed time: 1 seconds
Insert 100000 records,elapsed time: 1 seconds
Insert 1000000 records,elapsed time: 8 seconds
Insert 10000000 records,elapsed time: 124 seconds
dbDatabase db(dbDatabase::dbAllAccess, 160*1024); // 960Mb page pool
db.setConcurrency(10);
Insert 10000000 records,elapsed time: 116 seconds
然後匯入資料（INFO_GSM, BILL_DATA，USER_SPECIAL_NUMBER）【來源於172.18.1.30資料庫】
Update 100000 records,elapsed time: 1 seconds
Update 1000000 records,elapsed time: 9 seconds
Query 1000000 records,elapsed time: 2 seconds
Query 10000000 records,elapsed time: 1 seconds（唯一值查詢條件）
以上初略的資料可以看出來（伺服器響應慢），其速度比普通磁碟資料庫是高出至少一個數量級的。
<二>程式碼測試（效率上基本不存在問題，主要是安全效能測試）
自編程式碼測試：FTP::172.18.34.168//data0/ibas/jianguoh/fastdb/examples/FastdbTest.cpp
原始碼如右：
資料庫檔案：FTP::172.18.34.168//data0/ibas/jianguoh/fastdb/ FastdbTest.fdb
1、Complex and Large transaction processing
多次對於大規模的資料進行增，刪，查，改後進行事務處理，沒有發現異常。（跑的測試程式碼）(先查詢，然後更改，然後插入部分記錄，最後再有選擇地刪除部分資料)
2、Concurrent transaction’s Safe
Concurrent Threads can run safely in my lots of tests!(一Update模式程序和大量ReadOnly模式執行緒（同一個程序）併發操作)
<三>因為對於開原始碼測試我們沒有任何規範和流程，測試只能夠依靠測試者自己當時的想法和定義來測
附：
本來就很好的記憶體機制，再加上多種高效能的查詢優化技術，其效率應該是沒什麼問題了。
以下是一國外文獻上更翔實直觀的深度效率測試報告圖：（其中MS-SQL指的是磁碟資料庫）
