記憶體測試資料庫

記憶體中資料庫是完全在主記憶體中執行的資料庫，不會接觸到磁碟。它們通常以嵌入式資料庫的形式執行：在程序啟動時建立，嵌入在該程序中執行，並在程序結束時銷毀。

雖然大多數人認為資料庫是大型、以磁碟為中心的生物，但其實存在一個規模不大但十分忙碌的記憶體中資料庫世界。有些應用程式需要快速存取某種受管理的資料，而這些資料不需要持續存在，原因可能是資料不會變更，或可以重建（想像路由器中的路由表，或 EventPoster）。

然而，即使是傳統資料庫系統的開發人員也會發現記憶體中資料庫很有用，特別是在測試方面。在開發企業應用程式時，在執行測試套件時，會存取資料庫的測試可能會耗費大量時間。切換到記憶體中資料庫可以產生數量級的效果，大幅縮短建置時間。由於大多數 ThoughtWorkers 如果最近沒有看到綠色進度條就會開始發抖，因此這對我們來說有很大的影響。

人們似乎會採取兩種途徑來建立用於測試的記憶體中資料庫。第一種方法是使用 SQL 記憶體中資料庫函式庫。在 Java 領域，最受歡迎的似乎是 HSQLDB。其他地方則有 SQLite 和 Firebird。這些工具的好處是它們允許您使用正規 SQL 來查詢它們。其中一個問題是它們可能不支援完全相同的方言，或不具備目標資料庫的所有功能。您可以透過在 ram 磁碟上執行基於檔案的資料庫來執行類似的操作，這使您可以讓測試和生產部署更接近彼此。

另一種途徑是在 儲存庫 後面抽象化所有資料庫存取。然後，您可以使用正規記憶體中資料結構替換資料庫。通常，只要為物件圖形輸入點提供一組雜湊表就足夠了。儲存庫方法的優點之一是它為您提供了一種一致的方式來存取（並存根）非 SQL 資料來源。這表示您的物件關係對應系統也隱藏在儲存庫中。

的確，少數人積極不喜歡使用 SQL 內存資料庫，認為它們會鼓勵在網域模型中散佈 SQL 或物件關係對應程式碼。在內存中執行 SQL 可能消除了大部分緩慢存取的痛苦，但就像除臭劑一樣，掩蓋了缺少儲存庫的氣味。

到目前為止，測試是主要驅動力，但我認為內存資料庫還有更多發展空間。現在記憶體大小已足夠將許多應用程式資料庫載入記憶體中。如果您使用一種方法，記錄應用程式狀態的所有變更事件記錄，則可以將內存資料庫視為套用記錄結果的快取，在需要時重建並建立快照。此類樣式可以非常具有擴充性，並且在讀取器很多而寫入器很少的情況下具有高性能。我遇到過一些案例，人們在非常高性能的應用程式中使用內存資料庫。這裡的區別在於，這些經驗往往與利基商業資料庫有關，而對於測試，人們似乎更喜歡開源。

Prevayler 因採用這種方法而備受關注。我認識的人嘗試過它，發現它與內存物件的緊密耦合以及缺乏遷移工具會造成嚴重問題。但我認為將持續變更記錄作為記錄系統的方法是未來值得探索的沃土。

後續

在撰寫此頁面後，我收到了一些有趣的郵件，因此我想分享其中一些觀點。

一位通訊員表示，他喜歡將內存資料庫用於 SQL 擅長但物件不擅長的任務。在某些情況下，SQL 確實可以比物件或程序碼更優雅地解決問題，儘管我通常發現只有少數開發人員喜歡用 SQL 思考。

我的同事史蒂夫·斯帕克斯告訴我一個最近的專案，在測試中，他們會在第一次呼叫時從即時資料庫中提取資料，然後將該資料儲存在檔案中，以初始化內存儲存庫，以便後續查詢不會影響資料庫。我第一次在 C3 專案中看到這樣做，它將資料保存在以 SQL 查詢字串為鍵的雜湊表中。如果沒有值，它會轉到 DB2 並快取結果。

史蒂芬·格雷夫斯指出，我最初的條目並沒有真正討論內存資料庫的普遍用途，因此我進行了一些改寫並重新命名了該項目。

（感謝 Peter Becker、Zane Rockenbaugh 和 Steve Sparks 對我的評論。我也應該感謝各種未指明的 ThoughtWorkers 在我們的內部郵件清單上提供的有益評論。