摘要：當時，還飽受微軟和太陽間的訴訟的影響，該訴訟涉及到和間的兼容性。開發者們都在討論哪個平臺或者框架能夠勝出還是微軟新發布的。能為您提供端到端的應用性能解決方案，我們支持所有常見的框架及應用服務器，助您快速發現系統瓶頸，定位異常根本原因。

【編者按】關注 NoSQL 的動態發展很重要。NoSQL 的好處并不僅限于新的應用開發。在某些案例中，你可以見識到重新訪問現有的、傳統的框架帶來的積極效果，比如說你的 JPA 的實現。本文系國內 ITOM 管理平臺 OneAPM 編譯呈現。

多年以前，筆者在為一家世界頂級汽車公司做電子商務網站項目時，曾經碰到過一個聽起來像科幻故事的概念：通過實體類別來自動實現數據持久存儲。

是的，筆者說的就是現在大家都知道的分布式組件標準（Enterprise JavaBeans）。發布于1998年，后來被并入 Java EE 的技術規范，它引入了實體（Entity Beans）的概念。當時的想法是提供一個開發框架，讓開發者可以將他們的對象自動映射到相關表格，這樣該框架就可以在數據庫中持續自動將應用程序數據持久存儲。這被稱為 ORM：對象關系映射。

當時是21世紀初，大家還習慣于等待當時最牛的太陽微系統公司（Sun Microsystem）——跟現在蘋果公司的地位差不多——帶來各種重大發明，不過那可真的是模式的變更。它是緊跟面向對象編程（Object Oriented programming）出現的概念，不過它本身對主流應用開發世界來說就是一個重大的模式轉變。當時，在一個集中的數據庫中持久存儲數據的概念已經得到廣泛接受，關系數據庫也有很多。服務器端 web 應用開始成為主流，當然，你還得選擇存儲數據的數據庫，雖然關系數據庫并不是唯一的選擇，但它們是當時所謂的“桌面應用”的首選。這些都表明，應用存儲和檢索數據的唯一方式是通過執行 SQL 查詢。在很多情況下，這種操作是非常復雜的。

與之相反，Java 完全是面向對象的，不會被理解為表格和關系。關系數據庫很容易就能被其他過程式語言借助 SQL 來采用。當時，Java 還飽受微軟和太陽間的訴訟的影響，該訴訟涉及到 Java 和 IE 間的兼容性。開發者們都在討論哪個平臺或者框架能夠勝出：Java 還是微軟新發布的 .NET。

在這種背景下，EJB 提出的自動持久存儲是個令人欣喜，同時又極富創新的概念。不過，當時的硬件現實條件擺出了一個挑戰：雖然這個概念不錯，但是當時的處理硬件尚未準備好。Java 的問題已經足夠證明，被認為是“老派做法”的運行解釋代碼并不會降低所有進程的速度。在 EJB 要求的多層額外管理中執行這樣的代碼，更是超出想象。還有別忘了，我們說的是32位單核處理器時代，高端服務器的內存也不過 256 MB 到512 MB!（參考 topdesignmag.com）

時間快進到2016年，Hibernate 已經發布了第5版，根據最新調查，超過73%的 Java 開發是在某個 Java EE 框架下進行的。

自2009年起，隨著 JPA 2.0 的規范出臺，越來越多的應用從這種抽象概念中受益。Gavin King 于2001年開發的 Hibernate ORM 得到廣泛使用，更是起到了推動作用，這是由前 EJB2 式實體類別提供的更簡單的持久化能力實現方法。由于被認證為2010 JPA 2.0 規范的一種實施方法，Hibernate 成為應用開發者們廣泛推崇和使用的技術。

然而，發布15年以來，開發者論壇關于最初主題的討論依然有很多：如何改善 JPA 的性能表現。雖然硬件速度有了很大提升，同樣的問題依然存在。如今 JPA 成了主流技術，影響著世界上數以萬計的系統，這個問題就變得更加重要。ORM 架構內在的問題并沒有改變：將面向對象的世界映射到關系世界并不是個小任務，需要付出大量的額外努力才能實現無縫對接。

很多年前，Ted Neward 把 ORM 稱為“計算機世界的越南”，把它跟收益遞減規律聯系在一起：一開始看起來很好，但是你用得越多，要獲得額外收益就越難。在某些時候，因為前期已經付出了資金和時間，你很難“放棄誘餌，轉身跑掉”。他甚至還建議同時使用 ORM 方案和直接的 SQL 方案（或者 JDBC），這樣“就可以繞過那些 ORM 會帶來麻煩的地方”。這跟性能表現有很大關系。

jhades.org 的成員在他們的博客中提出了一個很好的觀點，他們說，ORM 給自己帶來的主要問題是挑戰（實時）同步兩個完全不同的數據結構。表格、關系和面向對象這幾個數據結構之間并沒有什么相似性。結果就是，傳統的關系數據庫管理系統在所有的 ORM 實施過程中的表現都有所降低，就是因為 SQL 與這些受益于 ORM 的應用之間沒有相似性，也就是所謂的領域驅動設計（Domain Driven Design）。

但是如今，整個數據庫產業都在經歷變革。過去15年來，你得很有勇氣，才敢避開關系數據庫管理系統，使用其他備選方案來持久存儲數據——如果你能找到的話，更不要說你還要費盡力氣解釋自己為什么要這么做。如今，大量 NoSQL 數據庫增加了計算機科學出現更多新模式的可能性。說 JPA 不能從中受益簡直是大錯特錯，而且筆者認為它絕對能從中受益。從數據結構的觀點來看，要在 JPA 實現方法中持久存儲數據，很多 NoSQL 方法都更合理，效果也比表格或關系數據管理系統更好。

筆者的研究似乎表明這是真的。我們最近基于自己的鍵值存儲（key-value store，縮寫為 KVS）數據庫引擎 c-treeACE V11 發布了一個新的 JPA 實現方法。最初的測試結果表明，在使用 c-treeACE 替代 SQL 數據庫后，性能提升了30%。

實現這種效果是通過有效利用一種智能映射方法，能夠識別出那些可以在低層級 KVS 中執行的檢索，從而避免繁冗、不必要的 SQL。由于 c-treeACE 是一種多模式數據庫，與數據庫互動的層（Java 持久存儲層，縮寫為 JPL）能夠在 SQL 和 NoSQL 之間自如轉換，從而優化每次 query.z 的執行。

總之，關注 NoSQL 的各種動態發展很重要。NoSQL 的好處并不僅限于新的應用開發。在某些案例中，你可以見識到重新訪問現有的、傳統的框架帶來的積極效果，比如說你的 JPA 的實現。無論你是用 Hibernate，或者其他 ORM 框架，數據庫替換都會是一個低風險、小投入的項目。你可能會發現，你很快就能節省幾千美元。

OneAPM 能為您提供端到端的 Java 應用性能解決方案，我們支持所有常見的 Java 框架及應用服務器，助您快速發現系統瓶頸，定位異常根本原因。分鐘級部署，即刻體驗，Java 監控從來沒有如此簡單。想閱讀更多技術文章，請訪問 OneAPM 官方技術博客。

本文轉自 OneAPM 官方博客

原文地址：https://dzone.com/articles/how-to-improve-performance-of-your-jpa-application