Java Persistence API (JPA)是存取Java關系數據的企業級標准JPA為Java對象映射到數據庫圖解提供支持包括一個簡單的API設計和查詢語言的表達查詢語言的表達是為了檢索來自數據庫映射的結果並且因為這個結果改變回執 JPA通過書寫以及維護他們自己的映射代碼允許存在單一的API而不管平台應用服務器或者提供持久執行為開發者提高生產率這些高速緩存解決方案允許經常的存取實體到存儲器可以減少到數據庫查詢的次數和大量花費在轉換數據庫查詢結果到對象上的處理時間高速緩存可以深入的積極的對應用性能產生影響
JPA和數據網格
數據網格是運行在有代表性的低耗硬件群集上面的軟件支持數據存貯和處理服務數據網格產品聚集了處理能源和存儲群集服務的能力使得客戶端通過API可以使用它API是為防護設計的避免分布式計算的復雜數據網格作為可伸縮的分布式存儲被普遍運用;無論如何分布式數據處理也是常見的特性作為存儲器數據網格提供一種方法來超越單一服務器因為堆棧大小的限制這個解決辦法就是通過分布式數據存取所有的集群服務器
盡管他們在專業技術領域內的應用被限制但是在當今企業應用中與數據網格相關的話題仍然層出不窮數據網格已經成為一種主流當開發應用程序的時候開發者需要考慮網格架構並且意識到在未來網格在應用程序中的應用比例會被提高
考慮一個銀行系統通過在寫入數據庫前確認所有項目來處理存款和撤銷請求確認的內容也許包括帳目是否有效提出請求的是否是戶主賬戶上是否有戶主要求提取的存款數額等等你可以想象在這樣一個系統中還有很多需要確認的地方你需要從數據庫中讀取數據總和數據總和執行一個確認的單一請求是有重要意義的並且會引起很多查詢幸運的是在JPA中創建這樣一個以數據庫為中心的應用程序是非常簡單的繪制領域內的每一個classe到數據庫並且書寫必要的JP QL查詢來檢索確認的對象系統也許不得不從數據庫讀取大量的數據來處理每一個請求但是它運作的很好
現在如果我們需要顯著的提高這個系統的生產力我們不得不解決它唯一但是最大的瓶頸通過查詢數據庫得出確認數據大多數JPA執行不是提供一個L存儲功能就是支持第三方L存儲功能的整合但是如果我們不得不處理大量隨機到達的請求在存儲器中擁有必須的參考數據是不太可能的事情存儲器在你重復的存取一些數據是非常的有效如果你存取的是隨機數據存儲器不太可能儲存你當即所需要的數據當然你可以不停的增加存儲器的容量來滿足你的需求但是每一個服務器只能擁有這麼多的堆棧
數據網格提供一種方法來超越單一服務器因為堆棧大小而產生的限制以及在集群服務器上分布存儲對象現在要面臨的挑戰是將數據網格技術與JPA融合從而能夠提高生產力而不需要完全改寫應用程序當然作為軟件系統的代表性案例有很多案例是接近一體化的每一個都伴有各自的優勢劣勢讓我們來看看整合的體系架構以及我們應該如何使用
數據網格作為中間級別的對象存儲
像我們前面所提到的數據網格產品可以擴展存儲存取一個集群並且可以作為一個共享的中間存儲使用他們提供一個單一的邏輯堆棧可以從物理層面進行擴展這種擴展是伴隨著全部的存儲容量在多重服務器上實現的全部的存儲容量是包括所有的群集服務器的堆棧在例子當中這意味著通過增加更多的服務器到網格它的存儲容量可以增加要點是所有的確認數據必須預先加載(通常是加熱存儲器)自從確認數據的存取成為我們的瓶頸存取所有的必須數據在實際上消除了這個問題
舉例來說在我們的銀行系統中考慮一個簡單的可以確定的方法
public boolean isValidAccount(Request request) {
Account account = entityManagerfind(
Accountclass requestgetAccountId());
if (account == null) {
return false;
} else {
return accountisValid();
}
}
伴隨著數據網格整合成為L存儲器查詢功能將會檢查網格所需要的賬戶如果不查詢它可以轉而查詢基礎數據庫無論如何如果網格中包含了所有的帳號信息這就沒必要查詢數據庫預熱應用存儲器可以從確認隊列中完整的清除數據庫存取過程
主鍵查詢可以很容易的運用到數據網格中但是JP QL查詢如何那?考慮這種方法使用非主鍵查詢的請求
public Customer getTxCustomer(Request request)
throws NoResultException {
Customer customer = entityManager
createQuery(select c from Customer c
where cmasterAccountId = :id)
setParameter(id requestgetMasterAccountId())
getSingleResult();
return customer;
}
查詢數據網格
得出一個匹配隨意准則的對象仍然是一件困難的事情
首先
它依賴於數據網格是否提供某種查詢框架
第二
JPA/data網格一體化可以將JP QL轉化為此框架
如果滿足這兩個必要條件
我們例子中的查詢就可以被應用在網格中
而不是數據庫中
這種方式的另一個很有價值的特性是執行並行查詢的可能性顯而易見的是我們例子中的查詢可以在網格中所有的服務器上並行執行查找需要的對象無論如何一個查詢執行後返回很多的對象是件有趣的事情每一個網格服務器都可以執行並行查詢來識別這些對象使其與被給予的標准相匹配在個對象上並行執行這種查詢十次比在個對象上查詢一次的速度快得多服務器越多每個服務器上分配的對象數量就越少查詢速度也就越快!
遺憾的是關於查詢問題還是有一個麻煩就是返回多重結果與主鍵查詢不同主鍵查詢中如果存儲器失誤會自動的引起數據庫查詢而現在是否從網格中得到足夠的結果是不明確的也許你只能查詢網格中的一部分對象所以一個網格查詢是無法返回數據庫中其他部分的查詢結果通過確保所有的對象都在網格中預熱存儲器解決了這個問題 但這並不總是可行無論如何對於一個特定的使用案例也許你知道一個特有的查詢是否需要網格或者數據庫再JPA中通過查詢節點實現查詢功能的也許就像下面的演示
Customer customer = entityManager
createQuery(select c from Customer c
where cmasterAccountId = :id)
setParameter(id requestgetMasterAccountId())
setHint(myjpaimplementationdontquerygrid true)
getSingleResult();
當然
現在沒有JPA標准來說明是否把查詢用於數據網格
這意味著你不得不在你編譯的代碼中采用特殊執行的節點
幸運的是
JPA規范依賴於執行
忽略那些不明白的的節點
所以你編譯的代碼並沒有因為節點而與任何一個特定對象結合
更新對象
當你看到網格上面的JPA很自然的你會首先想到查詢但是我們也不得不考慮更新輸入新對象修改現有對象以及刪除對象當網格在L存儲器中時確定網格的更新僅僅在數據庫執行過程成功交付之後產生是非常重要的輸入新對象會引起數據庫INSERT並且新對象會被放置到網格中修改對象會引起數據庫UPDATE並且被更新的對象會被放置到網格中最後刪除一個對象會引起數據庫DELETE並且這個對象會從網格中被移除關鍵點是更新數據網格一次數據庫執行過程可以成功交付
數據網格作為系統備份
當JPA使用數據網格作為一個分布式存儲器數據庫就成為了系統備份這是系統本來面目的最終來源並且保持實時更新但是數據網格實現備份的意義是什麼?這個案例經常使用在金融應用軟件上用以處理快速的變化以及過度過程數據如果沒有數據庫或者數據庫僅僅被用來存放數據或者是只是一個貨艙而不是聯機系統網格上面的JPA看起來會怎麼樣?
From:http://tw.wingwit.com/Article/program/Java/hx/201311/25852.html
