探尋關(guān)系數(shù)據(jù)庫和ORM的最佳替代者
原創(chuàng)【51CTO獨(dú)家特稿】一個(gè)數(shù)據(jù)庫的持久性整體規(guī)劃通常都是不成套的。各種ORM（對象關(guān)系映射）工具都能更容易地進(jìn)行對象和數(shù)據(jù)結(jié)構(gòu)之間的轉(zhuǎn)換，但沒有一個(gè)是完美的。這就是通常所說的“ORM Impedance Mismatch（阻抗不匹配）”。雖然抽象數(shù)據(jù)庫是一個(gè)崇高和理想的目標(biāo)，但沒有考慮關(guān)系數(shù)據(jù)庫這一事實(shí)總是會暴露出來。Joel Spolsky稱之為“The Law of Leaky Abstractions（泄露的抽象規(guī)律）”。51CTO編者注：Joel Spolsky是一個(gè)美國的軟件工程師，他的網(wǎng)絡(luò)日志“Joel談軟件”（Joel on Software）非常有名，讀者人數(shù)可以排進(jìn)全世界前100名。
最簡單的分離形式是由“映射層次對象到數(shù)據(jù)庫表”所描述。這件事絕對是可以做到的，對于其實(shí)現(xiàn)毫無質(zhì)疑?；ㄙM(fèi)在設(shè)計(jì)理想映射的大量努力，也許可以更好地用于解決真正的問題，而不是在仔細(xì)檢查問題之前就考慮解決方案。
更多的根據(jù)來自于最近發(fā)表在DZone的一篇文章。作者抱怨開發(fā)人員胡亂編寫代碼，使得數(shù)據(jù)庫的使用效率超級低。雖然如此，但這樣的問題只有在你了解低層實(shí)現(xiàn)的情況下才能暴漏出來。從純粹的面向?qū)ο蟮慕嵌葋砜矗a還算可以。
數(shù)據(jù)庫基礎(chǔ)
筆者認(rèn)為關(guān)于數(shù)據(jù)庫解決方案的最根本問題來自于這樣一個(gè)事實(shí)，即人們總是默認(rèn)地拘泥于某一個(gè)應(yīng)用?！拔覀冃枰３殖志眯??！薄澳呛冒?，讓我們使用一個(gè)數(shù)據(jù)庫吧[和ORM]”。
雖然RDBMS（關(guān)系型數(shù)據(jù)庫管理系統(tǒng)）是一個(gè)很好的、成熟的解決方案，但它并不總是最理想的。在認(rèn)真分析領(lǐng)域問題之前就先選擇一個(gè)解決方案始終是錯(cuò)誤的。
核心問題是，我們希望能夠保存和恢復(fù)應(yīng)用程序中某些數(shù)據(jù)結(jié)構(gòu)的狀態(tài)。需要一些關(guān)鍵點(diǎn)用來在各種機(jī)器之間共享這些狀態(tài)（用于可擴(kuò)展性）。
嘗試刪除RDBMS
所有嘗試都不外乎建立一個(gè)所謂的面向?qū)ο髷?shù)據(jù)庫，這證明，除了RDBMS我們還有別的選擇。我們有了一些很酷的工具，如Apache的CouchDB，它改變了我們考慮數(shù)據(jù)庫的方式。特別是如JCR（針對Java的內(nèi)容知識庫），它提供了存儲數(shù)據(jù)的另一種方法，看起來更像我們真正要涉及的對象。
所有這些方法都有一個(gè)很大的缺點(diǎn)，在某些時(shí)候，你會映射一些其他的數(shù)據(jù)格式到你的對象，是否還要映射屬性/ xml文件、元數(shù)據(jù)（注釋），或只是代碼。各種系統(tǒng)都能簡單完成這個(gè)任務(wù)，但總有某個(gè)地方讓人覺得有問題。
很多都只是RDBMS的再包裝，本質(zhì)并不脫離RDBMS。暴露出來的問題是一些查詢極其緩慢，而其他的速度卻極快。直到你能理解數(shù)據(jù)庫是怎樣被使用的，你才能明白這是為什么。這會導(dǎo)致代碼進(jìn)行修改，以便能以盡可能最快的方式運(yùn)行，抽象就被打破了。
幾年前，筆者曾經(jīng)試圖用Lucene搜索索引取代只讀數(shù)據(jù)庫。它實(shí)際上運(yùn)行得相當(dāng)出色。使用Lucene搜索索引來查詢數(shù)據(jù)比調(diào)用RDBMS要快很多。在特殊情況下，要快2個(gè)數(shù)量級之多，但還存在其他問題……這個(gè)概念從未真正占據(jù)主流。無論有多么不方便，都很難打破人們心理上對于數(shù)據(jù)庫解決方案的傳統(tǒng)認(rèn)識。51CTO編者注：有關(guān)Lucene搜索的使用方法，可參考用Lucene做一個(gè)簡單的Java搜索工具一文。
#p#
理想的解決方案
如果你的應(yīng)用程序只是要維護(hù)它的狀態(tài)，那將會存在理想的解決方案嗎？
◆重啟之間
◆機(jī)群的機(jī)器之間
在這樣一個(gè)世界里，你根本不認(rèn)為會存在一個(gè)持久性機(jī)制。你只是編寫你的應(yīng)用代碼；設(shè)置對象域；機(jī)群中某個(gè)機(jī)器的線程死亡時(shí)的恢復(fù)處理 。
只是一個(gè)夢想？
我們即將迎來2010年。你要知道，現(xiàn)在我們已經(jīng)有了在一組計(jì)算機(jī)之間分享系統(tǒng)狀態(tài)的方法。有辦法在一個(gè)文件系統(tǒng)中保留狀態(tài)備份，允許在系統(tǒng)重啟或崩潰時(shí)進(jìn)行恢復(fù)。
你應(yīng)該能夠編寫你的應(yīng)用程序，假設(shè)它只能夠運(yùn)行在沒有崩潰的單個(gè)機(jī)器上。
具有串行化的解決方案？
使用串行化來簡單地保持應(yīng)用程序的狀態(tài)，這種辦法怎么樣？或者基于圖像的持久性，如Smalltalk ？
在使用C / C++ 的日子里，我們可以獲得對象在內(nèi)存中的地址，然后把字節(jié)地址寫到磁盤。這是一種簡單的保存和恢復(fù)系統(tǒng)狀態(tài)的方法。Java提供了一個(gè)完整的串行化API （地址不能用于安全方面的考慮）。
可以創(chuàng)建一個(gè)線程來不斷保持串行化數(shù)據(jù)文件隨著應(yīng)用程序中對象的更新。然而，這種解決方案在一個(gè)機(jī)群中可能施行得不太好。透明度將會消失。接口被污染（需要實(shí)現(xiàn)串行化的事物）。
雖然簡單，串行化可能不會是最好的解決辦法，但是，這將會是一個(gè)有趣的實(shí)驗(yàn)。
共享內(nèi)存
實(shí)現(xiàn)共享內(nèi)存最明顯的方法是建立一個(gè)后臺進(jìn)程，保持一組機(jī)器內(nèi)存同步，同時(shí)保存一個(gè)文件。這將保持各個(gè)機(jī)器與其他機(jī)器同步操作，如果其中一個(gè)機(jī)器崩潰（如果它不能從鄰居機(jī)器讀取狀態(tài)），利用該文件可以進(jìn)行恢復(fù)。
看起來似乎一個(gè)虛擬機(jī)可能會為實(shí)現(xiàn)一個(gè)解決方案提供最大的成功機(jī)會，通過虛擬機(jī)，它能讓一些不可思議的事情更容易地發(fā)生在內(nèi)存訪問背后，而不是發(fā)生在直接訪問內(nèi)存空間時(shí)。
解決方案
因此，現(xiàn)在都存在哪些解決方案？
Oracle Coherence
Oracle用他們的Coherence產(chǎn)品做出了一個(gè)很好的嘗試。
這個(gè)解決方案的問題在于它的實(shí)現(xiàn)。在網(wǎng)絡(luò)間傳送整個(gè)對象可以迅速讓網(wǎng)絡(luò)達(dá)到飽和（如各種HTTP會話共享模式所表現(xiàn)出來的問題）。Coherence還需要接口，需要對象實(shí)現(xiàn)串行化（但這個(gè)問題比較小） 。
對于這些問題，Oracle解決方案在某些情況下可能是有用的，并會隨著技術(shù)的成熟而逐漸改善。風(fēng)險(xiǎn)是，該解決方案被打斷到Oracle的數(shù)據(jù)庫集群業(yè)務(wù)中。改善該項(xiàng)目的驅(qū)動(dòng)力可能不會很高。
Terracotta
Terracotta似乎會提供以下列表內(nèi)的所有需求：
◆網(wǎng)絡(luò)間同步
◆用磁盤保留狀態(tài)同步
◆透明的
◆快速的
Terracotta解決了筆者想要解決的一切問題，而且用一個(gè)優(yōu)化的透明解決方案進(jìn)行管理。不需要強(qiáng)制對象執(zhí)行串行化、不需要進(jìn)行其他任何類型的實(shí)現(xiàn)改變，它可以透明地工作于虛擬機(jī)之下。它通過發(fā)送不同的對象而不是整個(gè)對象，來設(shè)法優(yōu)化網(wǎng)絡(luò)使用率。它甚至保留狀態(tài)與文件系統(tǒng)的同步?？傊?，是目前最透明的持久性系統(tǒng)。
唯一需要強(qiáng)調(diào)的是，它只支持Java版本，不支持.net。因此，想要使用它，你只能選擇Java, Haskell, Scala, Groovy, jRuby, Jython, JavaScript或其他任何可以運(yùn)行于JVM（Java虛擬機(jī)）的語言。
真實(shí)的魔術(shù)
Terracotta不會進(jìn)行機(jī)器之間不必要的復(fù)制。它只做足以提供故障切換保護(hù)的工作，其余的事情會按需而做。它甚至?xí)巡皇褂玫臄?shù)據(jù)從一臺機(jī)器中剔除。
另外，對于每臺新添加到機(jī)群中的機(jī)器，為每臺機(jī)器增加有效內(nèi)存。
當(dāng)筆者看到類似這樣的事，筆者就想知道，除此之外，筆者還會需要數(shù)據(jù)庫為筆者做什么事。
筆者唯一可以想到的是，為數(shù)據(jù)挖掘和商業(yè)智能軟件包提供可用數(shù)據(jù)（或數(shù)據(jù)倉庫）。多數(shù)這些工具已經(jīng)圍繞數(shù)據(jù)庫進(jìn)行設(shè)計(jì)。
因此，RDBMS有效地成為了一個(gè)日志機(jī)器。
#p#
放棄RDBMS
因此，通過使用由Terracotta所提供的公共收藏（集合/列表/映射），完全可以放棄使用RDBMS。其結(jié)果是整潔的（具有更好的可維護(hù)性）代碼，更有效的內(nèi)存使用，和更快的執(zhí)行時(shí)間。
有什么理由不喜歡Terracotta呢？
是否將概念取消？
是否取消使用共享內(nèi)存的概念，作為擺脫數(shù)據(jù)庫的一種方式。
筆者希望如此。這是一個(gè)人人都想擁抱簡單的時(shí)代。Ruby on Rails, Grails, Spring, Wicket和其他框架的增加已經(jīng)表明，大多數(shù)開發(fā)人員已經(jīng)受夠了過分復(fù)雜的解決方案。
他們可能會愿意完全擺脫一個(gè)復(fù)雜的解決方案。
也許，我只是完全錯(cuò)誤的
或許RDBMS仍是一個(gè)很難移除的角色，可能是由于這個(gè)角色擔(dān)當(dāng)著重要的任務(wù)，有著重要的目的，例如是針對多個(gè)程序的集成點(diǎn)（就像Martin Fowler在他的Database Thaw Post中所說的） 。
Fowler實(shí)際上是建議建立一個(gè)HTTP包圍數(shù)據(jù)庫。這就把它從一個(gè)集成點(diǎn)轉(zhuǎn)換成了一個(gè)應(yīng)用程序。筆者已經(jīng)參與了這種類型的應(yīng)用，它具有一些非常強(qiáng)大的功能。
本文所說的可能不會適用的另一個(gè)領(lǐng)域是數(shù)據(jù)倉庫。但是，把它封裝在REST層，將是一個(gè)極好的應(yīng)用。
作為一個(gè)針對各種應(yīng)用的共有方式，不考慮它的實(shí)現(xiàn)，為了共享數(shù)據(jù)，使用RDBMS似乎很難被擊敗。據(jù)筆者所知，Terracotta解決方案可以工作于基于JVM的應(yīng)用程序之間。但是，對于其他語言（C / C + + / Smalltalk ）可能是有點(diǎn)困難。
原文：Best alternative to RDBMS and ORMs : Terracotta by Taranfx
【編輯推薦】
