2011-01-07 77 views
3

我期待構建一個網站/應用程序。類模型大約有100個對象,並不是特別複雜。可擴展,低開銷,高性能的Java持久性框架

該網站需要建立處理大約30 000個併發用戶,但它應該能夠處理更多。

我想使用現成的持久性框架,而不是寫我自己的jdbc來訪問數據庫。

我沒有選擇,只能使用關係數據庫。

我寧願它有一些形式的緩存烘烤,也寧願能夠自定義的SQL,因爲這往往是性能調優的必要條件。

什麼持久化框架,我應該使用什麼建議?

更新:謝謝大家。我認爲在這種情況下手動編寫sql的能力勝過。你可以做一些併發調整,如果你有權訪問它。雖然我同意,但您也可以在hibernate/jpa中訪問它,但這不是規則的例外。 myBatis也是一個輕量級,不太「魔術」的持久性框架。此外,出於性能和擴展的原因,我認爲使用過多的外鍵(這些外鍵由持久性框架管理)並不明智,因此我可能不會在休眠狀態中使用該功能。這將允許我在必要時分割分貝。我也認爲myBatis可能是第一次掌握更容易的持久性框架。 AFAIK,它沒有例如透明的持久性。你的答案已經證實,沒有另外的持久性框架可以滿足這些要求。

+0

「類模型是圍繞100個對象」 ......這是什麼意思?你的意思是100班嗎? – skaffman 2011-01-07 11:37:52

+0

是的,100類:-) – 2011-01-07 12:05:47

回答

3

如果手動優化的SQL是你想要的東西,那麼我建議myBatis(以前稱爲iBatis)。它使用您提供的手寫SQL爲您處理JDBC機制,以及對象列映射。

它是什麼不會爲你做的是對象關係映射(即自動處理關聯和集合)。如果這對你更重要,那麼像EclipseLink或Hibernate這樣的JPA實現是明顯的選擇。這些也可以處理自定義SQL,但比myBatis更爲複雜。

兩者都應該能夠處理您的負載要求沒有問題 - 問題是您的數據庫可以處理它。

+0

是的。我喜歡通過JPA實現MyBatis,因爲我完全知道正在運行的查詢。 – Nishant 2011-01-07 11:43:42

+1

我同意數據庫問題。最好不要使用關係數據庫。 – 2011-01-07 11:50:23

0

第一個明顯的選擇是JPAHibernate,它是從中派生出來的。

+0

這取決於如何「低開銷」和「高性能」是...... – 2011-08-01 09:27:55

2

擔心自己的基礎設施,並避免瓶頸的設計,而不是框架。

如果要處理大量併發用戶的再設計與硬件規模。不要過分擔心緩存數據在您的應用程序,最體面的數據庫做它的一個好工作給你,只要你把足夠的內存在那裏。

0

在不需要rdbms的情況下,持久性如何?一個位於Collections類模型上的專用高速,高可靠性和高併發持久性存儲?甲骨文公司(的Sleepycat)的Berkeley DB是一個非常接近契合但遺憾的是跑入表明,塞鎖定高併發問題。

2

我可能有點晚了你的決定,但我認爲這可能是將來考慮的選項。我同意Qwerky的觀點,數據抽象層(即ORM或其他框架)的緩存被高估了。大多數現代的RDBMS都有自己的內部緩存,速度非常快,所以通常情況下,性能調優更像是一個DBA工作,而不是開發人員。此外,配置不當的緩存很快就會變成性能噩夢。

我已經創建了jOOQ作爲一個數據庫抽象框架,試圖保持非常接近SQL本身,除了從流利的API構建的面向對象的類型安全查詢之外,沒有在JDBC之上放置更多的抽象。 jOOQ不會隱藏Java代碼中的任何關係事實,因此您可以完全控制所使用的SQL。

http://www.jooq.org

0

如果你讀這Hibernate tutorial(140篇),你會發現,Hibernate可以被用作以下原因,這在this sample chapter of High-Performance Java Persistence還解釋了一個高性能的數據訪問庫:

  • 擴展標識符發生器(高/低,彙集,彙集-LO)
  • 透明準備語句配料
  • 實體級高速緩存高度consitent併發策略
  • 無版本樂觀鎖定(例如, OptimisticLockType.ALL,OptimisticLockType.DIRTY)爲多租戶
  • 支持