2011-05-16 38 views
2

這個問題是相當假設的,但我會問。假設你使用Play開始一個項目,並使用mysql數據庫。稍後,您決定要將應用程序移至Google App Engine或Amazon EC2之類的應用程序。或者甚至可以切換到像MongoDB或Cassandra這樣的NoSQL數據庫。更改Java項目的數據庫類型?

有沒有這方面的工具?或者你基本上需要重寫你的模型?特別是因爲mysql是一個關係數據庫,與Monogo之類的東西沒有任何關係,我猜這很難嗎?我在問,因爲當你開始一個項目時,很明顯,你可能希望在某一時刻擴展你的應用程序,也許你會需要像Mongo這樣的東西,但你永遠不知道結果如何。很長一段時間,MySQL最終可能會滿足您的需求。那麼爲什麼要學習與Mongo一起工作的麻煩,當你用MySQL更高效時,如果有必要,你可以稍後切換?

我更具體地要求結合使用Play!框架。

你的想法是什麼?

回答

3

我們有這方面的經驗(從GAE到DB)。我不會推薦切換。永遠。原因是多方面的:

  • 錫耶納,雖然這是一個非常酷的想法,它有一個很大的問題:它試圖合併兩個完全不同的世界。 GAE的工作方式與關係數據庫非常不同。這意味着要在兩個世界中工作,圖書館必須做一些假設並隱藏一些功能。曾聽說過leaky abstractions?是的,錫耶納作爲一個創意非常酷,但不,它不是你想要的一箇中大項目。

  • NoSQL和關係數據庫的目標非常不同。每種方法都有使用情況,您可能希望使用SQL方法,而在其他方面,NoSQL方法會更好。試圖做任何事情都可能是錯誤的方法/設計

  • 通過使用NoSQL,以防萬一您可能會啓動root of all evil。說實話:銀行已經將SQL機器用於非常繁重的事務性負載並且沒有問題。而且我沒有將Memcache添加到方程中。也沒有SQL優化,也沒有代碼分析。

    如果您的網站會達到這個級別的流量,非常適合您!但最有可能的是,您將獲得資金按需擴展數據庫(或者您的網絡將會破產)。如果它達到了需要擴展更多的點,那麼你總是可以添加一個MongoDb/Cassandra/etc圖層來存儲你可能想要在那裏存儲的信息(關係圖和其他類似的東西)。但是在那之前你不需要它,現在你可能會在RAM中擁有完整的分貝。不要擔心可擴展性,它會很快:)

+0

很好的答案,謝謝! – networkprofile 2011-05-16 14:32:33

+0

不客氣 – 2011-05-16 14:44:43

+0

這是一個很好的答案。它表明關係意味着ACID和NoSQL以特定的原因付出代價。理解這些很重要。 – duffymo 2011-05-16 14:59:56

2

雖然沒有保證,但您可以採取的一項保護措施是在設計良好的界面後面隱藏持久性實施細節。它不會阻止您在切換時重寫實現,但它會將客戶端與變更隔離開來。如果您使用依賴注入引擎,您將能夠分別測試實現並以聲明方式將它們交換進出。

4

已經有一個針對這個用例的解決方案:爲Mysql/Postgres/H2編碼,並在GAE(以及其他NoSQL DB,如Hbase,sdb,mongo)中使用相同的代碼並返回。這是一個名爲Siena的項目,已經與Play整合。這是一個輕量級的對象映射框架,基於活動記錄設計橋接(至少嘗試)SQL/NoSQL。
網站是http://www.sienaproject.com(目前的doc與中繼代碼相比有點過時和不完整,因爲我們處於重構和增強的深度階段 - 代碼非常穩定,它在github上,但真正的中繼線不是主要項目,但叉http://github.com/mandubian/siena)。
Play中有2個模塊叫做play-siena和crudsiena,你可以在http://www.playframework.org/modules找到。目前的版本只提供GAE支持,但支持MySQL/Postgres/H2 + GAE的版本即將推出(我正在測試它)!

我是錫耶納的首席開發人員,所以不要猶豫,問我關於它的問題。
不要猶豫,加入谷歌組與我們討論:http://groups.google.com/group/siena-discuss

問候
帕斯卡爾

+0

我會看看,謝謝!所以基本上錫耶納是用於數據庫抽象? – networkprofile 2011-05-16 13:52:49

+0

是的,人們可以將它看作是一個數據庫抽象,但它並不是爲數據庫抽象而設計的。它被設計成一個實用的對象持久化框架,當你開發一個應用程序,特別是一個Web應用程序時,它提供了有用的API來存儲你的結構化數據。所以我們試圖從用戶需求到數據庫而不是其他方式。 – mandubian 2011-05-16 14:03:34

+0

當您針對SQL或NoSQL運行代碼時,我們嘗試提供相同的行爲。當然,對於非常特殊的情況,有一些限制,因爲這兩種類型的數據存儲在不同情況下都有優點和缺點(甚至在SQL DB之間也有差異)。無論如何,看起來差異不是那麼大,在絕大多數情況下,SQL和NoSQL都可以做到這一點,對於其他情況,我們試圖提供最好的折衷方案(如果可能的話)仔細研究每個數據庫特徵。基本上,這是一個非常實用且面向用戶的方法。 – mandubian 2011-05-16 14:06:56

2

雖然有可能轉化應用爲MySQL編寫一些NoSQL的工具工作,你用的方法關係數據庫的效率與您使用NoSQL的方式沒有任何相同之處。轉換後的應用程序效率非常低,並且數據量足以證明NoSQL解決方案的合理性 - 可能根本無法使用。

+0

因此,重寫模型(假設您使用的是MVC模式)是最好的方法嗎? – networkprofile 2011-05-16 13:51:51

+1

如果我遇到這種情況,首先要學習使用特定NoSQL解決方案的最佳實踐,並考慮將差異封裝在DAO層中的方法。在過去的12-18個月中,我一直在與Hadoop/HBase數據倉庫和Oracle數據倉庫合作。現在我可以看到這些方法是如何不同以及它們可以有什麼共同之處。我的下一個項目將從甲骨文開始,同時關注30倍以上的其他客戶可能的Hadoop/HBase轉換。我希望我會有機會證明/反駁我迄今爲止的理論思考;-) – Olaf 2011-05-16 14:01:34