原始發表時間：2009-09-10
經過幾天的折騰終於還是心碎了，前前後後爲了這個數據庫共計花費了約2周的時間……
系統採用的是經典技術框架 Spring 2.0.5 +
Hibernate 3.2 + iBatis 2.2.0
用於連接文件型數據庫的jdbc連接工具是ExecuteQuery 3.1.5（以下簡稱爲EQ）
數據庫目前採用的是 hsqldb
測試環境下準備了一個大小爲33Mb的數據庫命名爲 test.script ，核心的是存放主要數據的資料表，主要結構如下：
create table
Member_info(
id char(32), employee_id char(32), employee_name
varchar(50), company_id char(32), company_name varchar(50), ... ,
user_def_txt0 varchar(50), user_def_txt1 varchar(50), ... , user_def_txt9
varchar(50),
user_def_num0 number(8,2), user_def_num1 number(8,2), ... ,
user_def_num99 number(8,2)
)
好了，一切準備就緒，開始說明一下爲什麼hsqldb和h2這麼折騰我了吧！！
1.在這個應用裏，hsqldb的內存模式和cached模式都不能用
使用hsqldb的內存模式來讀入數據，會發現連接數據庫的時候奇慢無比，讀了一下hsqldb的源代碼，發現它在創建數據庫連接的時候，會檢查log文件、script文件的修改時間是否一致，而後查詢網上hsqldb的開發者Thomas的話是說，也會檢查properties文件中modified屬性是否爲yes，如果在退出應用的時候，沒有執行shutdown，那麼modified值肯定爲yes，這樣的話，下次連接數據庫的時候，hsqldb會認爲上次的退出是非法退出，需要根據log文件的內容從中斷處進行恢復，並將這些未寫入的數據繼續寫入到script數據文件中。
具體執行過程時，先創建一個與script文件同名的後綴爲.new的文件，比如數據文件爲test.script，那麼臨時文件的名稱爲test.script.new，等數據寫入完成後，刪除原有的script文件，重命名.new的文件爲test.script。
目測這個轉換的時間就很長……所以這裏就不再給出具體的時間長度……
使用 EQ
連接內存模式下的hsqldb，會發現連接速度也是挺慢……猜測是內存模式下，會將33Mb的數據全部都載入到內存，這個加載過程或許也在耽誤着我們寶貴的時間……
cached模式，使用EQ和應用連接數據庫都是奇怪無比，而後進行應用中最常用的一個業務功能測試性能，這個業務功能根據幾十個公式對庫表中的某些數值字段進行計算，例如以下這些語句：
update
member_info
set user_def_num0 = user_def_num1 + user_def_num2 +
user_def_num3
where company_id = '123456'
update member_info
set
user_def_num10 = user_def_num11 * 1.3 + user_def_num12
where company_id =
'123456'
……
測試的時候，涉及到的數據行數大約在800行左右，company_id
上有單獨的索引，執行的速度上，內存模式非常的快，cached模式大約慢30%左右，還算可以接受……
不過仔細觀察cached模式下，hsqldb產生的後綴爲.data的文件，會發現一個很可怕的事情——
內存模式下，script大小爲33Mb，轉換爲cached模式後，存放數據的文件是.data文件，大約爲68Mb。使用上述的十多個sql語句執行計算之後，會發現.data文件大小變成了200Mb。
觀察應用程序佔用的內存空間（還有虛擬內存空間），發現內存模式和cached模式不相上下……這和hsqldb中宣稱的cached模式很省資源的說法大相徑庭……
因爲糾結於這麼大的data文件會不會有什麼其他性能問題，所以想在計算完成後，執行“checkpoint
defrag”來對數據庫進行壓縮，結果卻讓人無法接受——執行步驟基本與之前的重新連接內存模式的數據庫一樣，會先創建.new的文件，再刪除原有data文件，而後重命名——這個過程耗時實在是太久了，大約需要1分鐘多，基本上是無法接受的時間長度。
2.H2的性能堪憂
還是挺感謝Thomas的熱情回覆，之前在google新聞組上發帖求助，許多朋友幫助，最熱情的莫過於H2作者的Thomas，他同時也是hsqldb的作者。
懷着對hsqldb的無比敬意，試用了H2，但是在上面的計算過程中遇到了無法逾越的性能問題，根據我的測試結果來看，上述計算過程在hsqldb中每條update語句耗時0.2秒，在H2中則需要大約2秒；於是我發帖求助是否存在設置問題，後來Thomas也做了測試，比我測試的結果性能要好一些，但是仍然有5倍以上的耗時差距，因此該應用也無法使用H2，因爲我們不能讓用戶在計算過程上等待得太久！！
3.Derby
現在時間是2009年9月11日0:29:52，剛剛將數據移植到Derby，在壓縮穩定後，數據文件夾大小約爲66Mb。
使用 EQ
的連接速度也還不錯，使用上述的update語句，單條執行的時間約爲 0.2
秒跟hsqldb相仿……這一步步似乎激動人心哦……但是沒有通過應用的實地考察，暫時無法下定論。
通關本文沒有給出一個確切的結論，甚至沒有具體的測試結果數據，因爲這些太依賴於環境，基本沒有參考價值。這裏只是想通過本文傳達一個觀點，任何新技術都得經過多種不同的角度來考察後，得出一個在一定環境中是否適用的結論。