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

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

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

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

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

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

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

時間快進到2016年，Hibernate 已經(jīng)發(fā)布了第5版，根據(jù)最新調(diào)查，超過73%的 Java 開發(fā)是在某個 Java EE 框架下進行的。

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

然而，發(fā)布15年以來，開發(fā)者論壇關(guān)于最初主題的討論依然有很多：如何改善 JPA 的性能表現(xiàn)。雖然硬件速度有了很大提升，同樣的問題依然存在。如今 JPA 成了主流技術(shù)，影響著世界上數(shù)以萬計的系統(tǒng)，這個問題就變得更加重要。ORM 架構(gòu)內(nèi)在的問題并沒有改變：將面向?qū)ο蟮氖澜缬成涞疥P(guān)系世界并不是個小任務(wù)，需要付出大量的額外努力才能實現(xiàn)無縫對接。

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

jhades.org 的成員在他們的博客中提出了一個很好的觀點，他們說，ORM 給自己帶來的主要問題是挑戰(zhàn)（實時）同步兩個完全不同的數(shù)據(jù)結(jié)構(gòu)。表格、關(guān)系和面向?qū)ο筮@幾個數(shù)據(jù)結(jié)構(gòu)之間并沒有什么相似性。結(jié)果就是，傳統(tǒng)的關(guān)系數(shù)據(jù)庫管理系統(tǒng)在所有的 ORM 實施過程中的表現(xiàn)都有所降低，就是因為 SQL 與這些受益于 ORM 的應(yīng)用之間沒有相似性，也就是所謂的領(lǐng)域驅(qū)動設(shè)計（Domain Driven Design）。

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

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

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

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

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

本文轉(zhuǎn)自 OneAPM 官方博客

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