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