前言
業界對持久存儲領域的追求從未停止過，為了更方便、更容易地用對象表達我們的思維，開源領域和商業領域都涌現了許多新技術， ORM 的出現恰恰說明了這點。最近一年，業界也在反思，到底 ORM 給我們帶來的是便利還是麻煩。矛頭指向大名鼎鼎的 Hibernate ，紛紛議論其性能問題，大家似乎要達成這樣的共識：“在業務邏輯復雜的地方用 SP ，而一般的 CRUD 還是 Hibernate ”，就連全球知名的 BearingPoint 也有類似看法。下面一個簡單的例子，說明了傳統 ORM 工具的弊端。讓我們考慮一個簡單的 Student 對象如清單1：
清單1. Student 類
public class Student {
private String name;
private int age;
public String getName(){
return name;
}
public int getAge(){
return age;
}
}
考慮下面這個場景:找到“年齡小于 20 歲的所有學生”？
使用 ORL 實現如清單2：
清單2. ORL 實現
String oql = "select * from student in AllStudents where student.age <20"; OQLQuery query = new OQLQuery(oql); Object students = query.execute();
使用 JDOQL 實現如清單3：
清單3. JDOQL 實現
Query query = persistenceManager.newQuery(Student.class, "age <20"); Collection students = (Collection)query.execute();
上面的方法都存在一些普遍問題：
- 現代集成開發環境不會檢查內嵌字符串的語義和語法錯誤。在上面所有查詢語句中， age 字段和數值 20 都被認為是數字類型，但是沒有一個 IDE 或編譯器能檢查其實際正確性。如果開發者混淆了查詢代碼－―比如，改變了 age 字段的名字或類型，將導致――上面所有的查詢語句在運行時報錯，而不會在編譯時提示。
- 現代敏捷開發技術鼓勵不斷進行重構來維持清晰和與時俱進的類模型，以便準確重現不斷演進的域模型。如果查詢代碼難于維護，它會延遲決定重構的時間并不可避免的引入低質量代碼。
- 所有列出的查詢都直接用 Student 類的私有成員 age，而不是使用它的公共接口 student.getAge()，因此他們都破壞了面向對象封裝規則，違反接口和實現應該分離的面向對象法則。
- 所有的查詢都非 100% 的原生。
既然存在如此多的問題, 為什么不直接使用純面向對象數據庫呢？有些開發者可能會說：“它缺乏數學模型的支持， 還不夠成熟”。的確， RDBMS 發展了幾十年才有今天的成就，已經非常完善了。而技術的革新是無止境的, 故步自封的永遠都跟不上變化的腳步。
讓我們來簡單回顧一下對象數據庫的發展史（資料來源于 Wiki 百科全書）：“面向對象數據庫系統”這一術語第一次出現于 1985 年。著名的研究項目包括：Encore-Ob/Server ( 布朗大學）， EXODUS（Wisconsin 大學）， IRIS （惠普）， ODE （ Bell 實驗室）， ORION （MCC ） ，Vodak （GMD-IPSI）和 Zeitgeist （Texas Instruments）。其中以 ORION 項目發表的論文數為最多。 MCC 的 Won Kim 將這些論文中最有價值的一部分匯編成書并由 MIT 出版社出版。對象數據庫管理系統為面向對象編程語言增加了持久的概念。最早的商品化 ODBMS 出現在 1986 年，是 Servio 公司（現在的 GemStone 公司）和 Ontos 公司推出的。后來（九十年代） Object Design （ ODI ）、 Versant 、 Objectivity 、 O2 Technology 、 Poet 、 Ibex 、 UniSQL 和 ADB MATISSE 等公司也加入了這個開拓行列。
而今天，一家來自加州硅谷的開源面向對象數據庫公司 db4objects 為我們帶來了db4o， 一款性能卓越的純面向對象數據庫，也是我們這篇和后續文章將會介紹的主角。
db4o 為我們帶來的是這樣一種面向對象的查詢方式:
- 100% 的原生 查詢語言應能用實現語言（ Java 或 C# ）完全表達，并完全遵循實現語言的語義。
- 100% 的面向對象 查詢語言應可運行在自己的實現語言中，允許未經優化執行普通集合而不用自定義預處理。
- 100% 的類型安全 查詢語言應能完全獲取現代 IDE 的特性，比如語法檢測、類型檢測、重構，等等。
什么是 db4o
“利用表格存儲對象，就像是將汽車開回家，然后拆成零件放進車庫里，早晨可以再把汽車裝配起來。但是人們不禁要問，這是不是泊車的最有效的方法呢。” – Esther Dyson
db4o 是一個開源的純面向對象數據庫引擎，對于 Java 與 .NET 開發者來說都是一個簡單易用的對象持久化工具，使用簡單。同時，db4o 已經被第三方驗證為具有優秀性能的面向對象數據庫， 下面的基準測試圖對 db4o 和一些傳統的持久方案進行了比較。db4o 在這次比較中排名第二，僅僅落后于JDBC。通過圖 1 的基準測試結果，值得我們細細品味的是采用 Hibernate/HSQLDB 的方案和 JDBC/HSQLDB 的方案在性能方面有著顯著差距，這也證實了業界對 Hibernate 的擔憂。而 db4o 的優異性能，讓我們相信： 更 OO 并不一定會犧牲性能。
圖1. HSQLDB 基準測試
同時，db4o 的一個特點就是無需 DBA 的管理，占用資源很小，這很適合嵌入式應用以及 Cache 應用， 所以自從 db4o 發布以來，迅速吸引了大批用戶將 db4o 用于各種各樣的嵌入式系統，包括流動軟件、醫療設備和實時控制系統。
db4o 由來自加州硅谷的開源數據庫公司 db4objects 開發并負責商業運營和支持。db4o 是基于 GPL 協議。db4objects 于 2004 年在 CEO Christof Wittig 的領導下組成，資金背景包括 Mark Leslie 、 Veritas 軟件公司 CEO 、 Vinod Khosla （ Sun 公司創始人之一）、 Sun 公司 CEO 在內的硅谷高層投資人組成。毫無疑問，今天 db4objects 公司是硅谷炙手可熱的技術創新者之一。
db4o 特性
db4o 的目標是提供一個功能強大的，適合嵌入的數據庫引擎，可以工作在設備，移動產品，桌面以及服務器等各種平臺。主要特性如下：
- 開源模式。與其他 ODBMS 不同，db4o 為開源軟件，通過開源社區的力量驅動開發 db4o 產品。
- 原生數據庫。db4o 是 100% 原生的面向對象數據庫，直接使用編程語言來操作數據庫。程序員無需進行 OR 映射來存儲對象，大大節省了程序員在存儲數據的開發時間。
- 高性能。圖2為 db4o 官方公布的基準測試數據，db4o 比采用 Hibernate/MySQL 方案在某些測試線路上速度高出 44 倍之多！并且安裝簡單，僅僅需要 400Kb 左右的 .jar 或 .dll 庫文件。在接下來的系列文章中，我們將只關注在 Java 平臺的應用，但是實際上 db4o 毫無疑問會很好地在 .NET 平臺工作。
圖2. db4o 官方基準測試數據
- 易嵌入。使用 db4o 僅需引入 400 多 k 的 jar 文件或是 dll 文件，內存消耗極小。
- 零管理。使用 db4o 無需 DBA，實現零管理。
- 支持多種平臺。db4o 支持從 Java 1.1 到 Java 5.0，此外還支持 .NET 、 CompactFramework 、 Mono 等 .NET 平臺，也可以運行在 CDC 、 PersonalProfile 、 Symbian 、 Savaje 以及 Zaurus 這種支持反射的 J2ME 方言環境中，還可以運行在 CLDC 、 MIDP 、 RIM/Blackberry 、 Palm OS 這種不支持反射的 J2ME 環境中。
或許開發者會問，如果現有的應用環境已經有了關系型數據庫怎么辦？沒關系，db4o 的 dRS（db4o Replication System）可實現 db4o 與關系型數據庫的雙向同步（復制），如圖 3 。 dRS 是基于 Hibernate 開發，目前的版本是 1.0 ，并運行在 Java 1.2 或更高版本平臺上，基于 dRS 可實現 db4o 到 Hibernate/RDBMS 、 db4o 到 db4o 以及 Hibernate/RDBMS 到 Hibernate/RDBMS 的雙向復制。dRS 模型如圖3
圖3. dRS 模型
結論
db4o 因為其開源的理念，以及創新的實現，獲得了 Java Pro 2006 讀者選擇獎。無論從成功案例還是 db4o 本身來看，這款純面向對象數據庫都值得我們關注，從官方論壇反饋情況看，有相當的用戶準備把關系型數據庫遷移到 db4o 。而最新發布的 5.5 版本，更是把性能再次提升很多。在接下來的文章中，我會繼續和大家分享 db4o 給我們帶來的這場面向對象數據庫風暴。
文章列表
留言列表
