主要測試記憶體和資料庫

主要測試記憶體和資料庫

還要感謝好多位沒給出姓名的 ThoughtWork 員工在內部郵件列表上發了有幫助的評論。 感謝 Peter Becker Zane Rockenbaugh 還有 Steve Spark 給我評論。

 

 

更新見文末。

嵌入到這個程式中執行，執行時完全在記憶體裡無需訪問硬碟的資料庫叫做 “ 記憶體資料庫 ” 記憶體資料庫常作為嵌入式資料庫：當一個程式啟動時被建立。當程式終止時被銷燬。

實際上還存在一個狹小而熱鬧的記憶體資料庫世界。有些應用系統要求資料訪問速度要快，儘管大家一般都認為資料庫應該是個以硬碟為中心的龐大部件。這些資料被管理但無需被持久化，因為它不會改變，或者因為這些資料可被重新生成（聯想一下路由器的路由表，還有 事件張貼板

也會發現記憶體資料庫的妙用，即便開發保守的資料庫應用系統。尤其是做測試的時候。開發一個企業應用系統時，測試套件（ test suit 每跑一遍，需要訪問資料庫的那些測試都會花費大量的時間。把這些測試切換到記憶體資料庫，效果就大不一樣了執行耗時將大大縮短。要是最近一會沒看見那個綠色進度條，幾乎 ThoughtWork 公司的任何一位員工都會心神不寧，所以記憶體資料庫與我真是休慼相關。

一種是把它用作一個支援 SQL 記憶體資料庫順序包，人們用記憶體資料庫做測試有兩種方式。 Java 世界裡最流行的要數 HSQLDB 其他領域則有 SQLite 和 Firebird 這類工具最誘人的一點是允許你用常規的 SQL 做查詢，但有一點需注意：支援的 SQL 方言可能與目標資料庫並不完全相同，也可能不提供目標資料庫的全部特性。也可以在 ram 磁碟上跑一個基於檔案的資料庫達到類似的效果，可以讓測試與實際產品佈置環境之間儘可能接近。

這樣就能以常規的駐於記憶體的資料結構替換掉資料庫了要保管一個物件關聯圖的節點通常用幾個雜湊表就夠了採用 Repositori 模式有一個好 處，另外一種方式是把所有資料庫訪問操作都抽取進去放到一個 Repository 後邊。就是無論是不是 SQL 資料來源，其訪問方式是統一的可以拿非 SQL 資料來源作為測試樁把資料庫替換掉。這意味著我用的 O-R 對映工具也隱藏於 Repositori 後面。

有少數一些人對記憶體資料庫這種東西著實反感，然而。因為他認為記憶體資料庫誘使人們把 SQL 或 O-R 對映程式碼在領域模型（ domain model 中散得到處都是雖然在記憶體裡執行 SQL 可以免除訪問耗時之苦，但它卻扮演了文過飾非的除臭劑 ” 角色，讓缺失 Repositori 層的臭味不那麼明顯了

儘管測試是採用記憶體資料庫的主要動機，目前為止。但我覺得它還能帶來其他好處。今天記憶體大小對於很多應用都不再是個限制因素了可以把全部資料裝 記憶體中執行。例如，一個系統的狀態變化記錄在一個事件日誌裡，想著用什麼方法來監控這份日誌，這時記憶體資料庫可被用作日誌資訊的一個快取，就能隨需 重新載入日誌或給某狀態 “ 拍個快照 ” 這種方式能使資料讀取很多但寫入很少的系統獲得很高的可伸縮性以及效能上的提升。見到過好幾個系統，用記憶體資料庫 獲得了非常高的效能。與用於測試不同的這些場所，人們更願意選用合適的商業資料庫，而做測試時人們更青睞開源系統。

另外，Prevayler 對採用這種方法非常關注。還了解到有人嘗試後發現它與記憶體中的 object 緊密耦合在一起。遷移工具的缺乏也導致很嚴重的問題。但我認為這種系統變化日誌的耐久化方式今後會是個成果豐碩的探索領域。

 

後續討論

 

想我應該拿進去與大家分享這些觀點。 寫完上邊的文字後我收到幾封有意思的郵件。

喜歡把記憶體資料庫用在那些用 SQL 勝任有餘但用 object 卻蹩手蹩腳的任務上。確實存在一些情況，有人回信說。用 SQL 比用 object 或過程化程式碼更能漂亮地解決問題，儘管我通常認為喜歡以 SQL 方式思考問題的開發人員只佔少數。

系統啟動時把資料從線上資料庫中取出來，同事 Steve Spark 告訴我一個近期專案的測試中。再把它保管到一個檔案裡來初始化一個記憶體裡的 Repositori 之後的查詢就不需要再碰資料庫了第一次見到這種做法是 C3 專案中，把資料儲存在一個雜湊表中，而把 SQL 查詢字串用作哈 希表的鍵，如果某鍵沒有對應的值，再轉向 DB2 查詢，同時把結果儲存在雜湊表中。

因此，Steven Grave 指出我原來寫的那篇 “ 記憶體資料庫 ” 沒能真正把記憶體資料庫的主要用途講透。重寫了一下，並把標題改名為 “ 記憶體測試資料庫 ”