如何進行Hibernate的效能優化?

2022-07-11 00:09:16 字數 3705 閱讀 4211

l 資料庫設計調整

l hql優化

l api的正確使用

(如根據不同的業務型別選用不同的集合及查詢

api)

l 主配置引數(日誌,查詢快取,

fetch_size, batch_size等)

l 對映檔案優化(id生成策略,二級快取,延遲載入,關聯優化

)l 一級快取的管理

l 針對二級快取,還有許多特有的策略

l 事務控制策略。

(下面是說明不需要回答)1、

資料庫設計

a) 降低關聯的複雜性

b) 盡量不使用聯合主鍵

c) id的生成機制,不同的資料庫所提供的機制並不完全一樣

d) 適當的冗餘資料,不過分追求高正規化

2、 hql優化

hql如果拋開它同hibernate本身一些快取機制的關聯,hql的優化技巧同普通的sql優化技巧一樣,可以很容易在網上找到一些經驗之談。

3、主配置

a) 查詢快取,同下面講的快取不太一樣,它是針對hql語句的快取,即完全一樣的語句再次執行時可以利用快取資料。但是,查詢快取在乙個交易系統(資料變更頻繁,查詢條件相同的機率並不大)中可能會起反作用:它會白白耗費大量的系統資源但卻難以派上用場。

b) fetch_size,同jdbc的相關引數作用類似,引數並不是越大越好,而應根據業務特徵去設定

c) batch_size同上。

d) 生產系統中,切記要關掉sql語句列印。

4、快取

a) 資料庫級快取:這級快取是最高效和安全的,但不同的資料庫可管理的層次並不一樣,比如,在oracle中,可以在建表時指定將整個表置於快取當中。

b) session快取:在乙個hibernate session有效,這級快取的可干預性不強,大多於hibernate自動管理,但它提供清除快取的方法,這在大批量增加/更新操作是有效的。比如,同時增加十萬條記錄,按常規方式進行,很可能會發現outofmemeroy的異常,這時可能需要手動清除這一級快取:session.evict以及 session.clear

c) 應用快取:在乙個sessionfactory中有效,因此也是優化的重中之重,因此,各類策略也考慮的較多,在將資料放入這一級快取之前,需要考慮一些前提條件:

i. 資料不會被第三方修改(比如,是否有另乙個應用也在修改這些資料?)

ii. 資料不會太大

iii. 資料不會頻繁更新(否則使用cache可能適得其反)

iv. 資料會被頻繁查詢

v. 資料不是關鍵資料(如涉及錢,安全等方面的問題)。

快取有幾種形式,可以在對映檔案中配置:read-only(唯讀,適用於很少變更的靜態資料/歷史資料),nonstrict-read- write,read-write(比較普遍的形式,效率一般),transactional(jta中,且支援的快取產品較少)

d) 分布式快取:同c)的配置一樣,只是快取產品的選用不同,在目前的hibernate中可供選擇的不多,oscache, jboss cache,目前的大多數專案,對它們的用於集群的使用(特別是關鍵交易系統)都持保守態度。在集群環境中,只利用資料庫級的快取是最安全的。

5、延遲載入

a) 實體延遲載入:通過使用動態**實現

b) 集合延遲載入:通過實現自有的set/list,hibernate提供了這方面的支援

c) 屬性延遲載入:

6、方法選用

a) 完成同樣一件事,hibernate提供了可供選擇的一些方式,但具體使用什麼方式,可能用效能/**都會有影響。顯示,一次返回十萬條記錄(list /set/bag/map等)進行處理,很可能導致記憶體不夠的問題,而如果用基於游標(scrollableresults)或iterator的結果集,則不存在這樣的問題。

b) session的load/get方法,前者會使用二級快取,而後者則不使用。

c) query和list/iterator,如果去仔細研究一下它們,你可能會發現很多有意思的情況,二者主要區別(如果使用了spring,在 hibernatetemplate中對應find,iterator方法):

i. list只能利用查詢快取(但在交易系統中查詢快取作用不大),無法利用二級快取中的單個實體,但list查出的物件會寫入二級快取,但它一般只生成較少的執行sql語句,很多情況就是一條(無關聯)。

ii. iterator則可以利用二級快取,對於一條查詢語句,它會先從資料庫中找出所有符合條件的記錄的id,再通過id去快取找,對於快取中沒有的記錄,再構造語句從資料庫中查出,因此很容易知道,如果快取中沒有任何符合條件的記錄,使用iterator會產生n+1條sql語句(n為符合條件的記錄數)

iii. 通過iterator,配合快取管理api,在海量資料查詢中可以很好的解決記憶體問題,如:

while(it.hasnext())

如果用list方法,很可能就出outofmemory錯誤了。

iv. 通過上面的說明,我想你應該知道如何去使用這兩個方法了。

7、集合的選用

在hibernate 3.1文件的「19.5. understanding collection performance」中有詳細的說明。

8、事務控制

事務方面對效能有影響的主要包括:事務方式的選用,事務隔離級別以及鎖的選用

a) 事務方式選用

:如果不涉及多個事務管理器事務的話,不需要使用

jta,只有

jdbc

的事務控制就可以。

b) 事務隔離級別

:參見標準的

sql事務隔離級別

c) 鎖的選用

:悲觀鎖

(一般由具體的事務管理器實現

),對於長事務效率低,但安全。樂觀鎖

(一般在應用級別實現

),如在

hibernate

中可以定義

version

字段,顯然,如果有多個應用運算元據,且這些應用不是用同一種樂觀鎖機制,則樂觀鎖會失效。因此,針對不同的資料應有不同的策略,同前面許多情況一樣,很多時候我們是在效率與安全

/準確性上找乙個平衡點,無論如何,優化都不是乙個純技術的問題,你應該對你的應用和業務特徵有足夠的了解。

9、 批量操作

即使是使用jdbc,在進行大批資料更新時,

batch

與不使用

batch

有效率上也有很大的差別。我們可以通過設定

batch_size

來讓其支援批量操作。

舉個例子,要批量刪除某錶中的物件,如「delete account」,打出來的語句,會發現

hibernate

找出了所有

account的id

,再進行刪除,這主要是為了維護二級快取,這樣效率肯定高不了,在後續的版本中增加了

bulk delete/update

,但這也無法解決快取的維護問題。也就是說,由於有了二級快取的維護問題,

hibernate

的批量操作效率並不盡如人意

!從前面許多要點可以看出,很多時候我們是在效率與安全/準確性上找乙個平衡點,無論如何,優化都不是乙個純技術的問題,你應該對你的應用和業務特徵有足夠的了解,一般的,優化方案應在架構設計期就基本確定,否則可能導致沒必要的返工,致使專案延期,而作為架構師和專案經理,還要面對開發人員可能的抱怨,必竟,我們對使用者需求更改的控制力不大,但技術

/架構風險是應該在初期意識到並制定好相關的對策。

還有一點要注意,應用層的快取只是錦上添花,永遠不要把它當救命稻草,應用的根基(資料庫設計,演算法,高效的操作語句,恰當

api的選擇等

)才是最重要的。

如何進行HIBERNATE效能調優

大體上,對於hibernate效能調優的主要考慮點如下 資料庫設計調整 hql優化 api的正確使用 如根據不同的業務型別選用不同的集合及查詢api 主配置引數 日誌,查詢快取,fetch size,batch size等 對映檔案優化 id生成策略,二級快取,延遲載入,關聯優化 一級快取的管理 針...

如何進行Monkey Test

一 簡介 monkey是android中的乙個命令列工具,可以執行在模擬器裡或實際裝置中。它向系統傳送偽隨機的使用者事件流 如按鍵輸入 觸控螢幕輸入 手勢輸入等 實現對正在開發的應用程式進行壓力測試。monkey包括許多選項,它們大致分為四大類 基本配置選項,如設定嘗試的事件數量 執行約束選項,如設...

如何進行Code Review

code review應該怎麼做 如何高效迅速的進行codereview 下面推薦一些 code review 工具 crucible atlassian 內部 審查工具 gerrit google 開源的 git 審查工具 github 程式設計師應該很熟悉了,上面的 pull request 在...