Hibernate二級緩存攻略 | |||||||||||
我的經驗主要來自hibernate2.1版本,基本原理和3.0、3.1是一樣的,請原諒我的頑固不化。 hibernate的session提供了一級緩存,每個session,對同一個id進行兩次load,不會發送兩條sql給數據庫,但是session關閉的時候,一級緩存就失效了。 二級緩存是SessionFactory級別的全局緩存,它底下可以使用不同的緩存類庫,比如ehcache、oscache等,需要設置hibernate.cache.provider_class,我們這裏用ehcache,在2.1中就是hibernate.cache.provider_class=net.sf.hibernate.cache.EhCacheProvider如果使用查詢緩存,加上hibernate.cache.use_query_cache=true。 緩存可以簡單的看成一個Map,通過key在緩存裏面找value。 Class的緩存 對於一條記錄,也就是一個PO來說,是根據ID來找的,緩存的key就是ID,value是POJO。無論list,load還是iterate,只要讀出一個對象,都會填充緩存。但是list不會使用緩存,而iterate會先取數據庫select id出來,然後一個id一個id的load,如果在緩存裏面有,就從緩存取,沒有的話就去數據庫load。假設是讀寫緩存,需要設置:
如果你使用的二級緩存實現是ehcache的話,需要配置ehcache.xml:
其中eternal表示緩存是不是永遠不超時,timeToLiveSeconds是緩存中每個元素(這裏也就是一個POJO)的超時時間,如果eternal="false",超過指定的時間,這個元素就被移走了。timeToIdleSeconds是發呆時間,是可選的。當往緩存裏面put的元素超過500個時,如果overflowToDisk="true",就會把緩存中的部分數據保存在硬盤上的臨時文件裏面。 每個需要緩存的class都要這樣配置。如果你沒有配置,hibernate會在啓動的時候警告你,然後使用defaultCache的配置,這樣多個class會共享一個配置。 當某個ID通過hibernate修改時,hibernate會知道,於是移除緩存。 這樣大家可能會想,同樣的查詢條件,第一次先list,第二次再iterate,就可以使用到緩存了。實際上這是很難的,因爲你無法判斷什麼時候是第一次,而且每次查詢的條件通常是不一樣的,假如數據庫裏面有100條記錄,id從1到100,第一次list的時候出了前50個id,第二次iterate的時候卻查詢到30至70號id,那麼30-50是從緩存裏面取的,51到70是從數據庫取的,共發送1+20條sql。所以我一直認爲iterate沒有什麼用,總是會有1+N的問題。 (題外話:有說法說大型查詢用list會把整個結果集裝入內存,很慢,而iterate只select id比較好,但是大型查詢總是要分頁查的,誰也不會真的把整個結果集裝進來,假如一頁20條的話,iterate共需要執行21條語句,list雖然選擇若干字段,比iterate第一條select id語句慢一些,但只有一條語句,不裝入整個結果集hibernate還會根據數據庫方言做優化,比如使用mysql的limit,整體看來應該還是list快。) 如果想要對list或者iterate查詢的結果緩存,就要用到查詢緩存了。 查詢緩存 首先需要配置hibernate.cache.use_query_cache=true。 如果用ehcache,配置ehcache.xml,注意hibernate3.0以後不是net.sf的包名了:
然後
第二行指定要使用的cacheRegion是myCacheRegion,即你可以給每個查詢緩存做一個單獨的配置,使用setCacheRegion來做這個指定,需要在ehcache.xml裏面配置它:
如果省略第二行,不設置cacheRegion的話,那麼會使用上面提到的標準查詢緩存的配置,也就是:net.sf.hibernate.cache.StandardQueryCache 對於查詢緩存來說,緩存的key是根據hql生成的sql,再加上參數,分頁等信息(可以通過日誌輸出看到,不過它的輸出不是很可讀,最好改一下它的代碼)。 比如hql:
生成大致如下的sql:
參數是"tiger%",那麼查詢緩存的key*大約*是這樣的字符串(我是憑記憶寫的,並不精確,不過看了也該明白了):
這樣,保證了同樣的查詢、同樣的參數等條件下具有一樣的key。 現在說說緩存的value,如果是list方式的話,value在這裏並不是整個結果集,而是查詢出來的這一串ID。也就是說,不管是list方法還是iterate方法,第一次查詢的時候,它們的查詢方式很它們平時的方式是一樣的,list執行一條sql,iterate執行1+N條,多出來的行爲是它們填充了緩存。但是到同樣條件第二次查詢的時候,就都和iterate的行爲一樣了,根據緩存的key去緩存裏面查到了value,value是一串id,然後在到class的緩存裏面去一個一個的load出來。這樣做是爲了節約內存。 可以看出來,查詢緩存需要打開相關類的class緩存。list和iterate方法第一次執行的時候,都是既填充查詢緩存又填充class緩存的。 這裏還有一個很容易被忽視的重要問題,即打開查詢緩存以後,即使是list方法也可能遇到1+N的問題!相同條件第一次list的時候,因爲查詢緩存中找不到,不管class緩存是否存在數據,總是發送一條sql語句到數據庫獲取全部數據,然後填充查詢緩存和class緩存。但是第二次執行的時候,問題就來了,如果你的class緩存的超時時間比較短,現在class緩存都超時了,但是查詢緩存還在,那麼list方法在獲取id串以後,將會一個一個去數據庫load!因此,class緩存的超時時間一定不能短於查詢緩存設置的超時時間!如果還設置了發呆時間的話,保證class緩存的發呆時間也大於查詢的緩存的生存時間。這裏還有其他情況,比如class緩存被程序強制evict了,這種情況就請自己注意了。 另外,如果hql查詢包含select字句,那麼查詢緩存裏面的value就是整個結果集了。 #p# 當hibernate更新數據庫的時候,它怎麼知道更新哪些查詢緩存呢? hibernate在一個地方維護每個表的最後更新時間,其實也就是放在上面net.sf.hibernate.cache.UpdateTimestampsCache所指定的緩存配置裏面。 當通過hibernate更新的時候,hibernate會知道這次更新影響了哪些表。然後它更新這些表的最後更新時間。每個緩存都有一個生成時間和這個緩存所查詢的表,當hibernate查詢一個緩存是否存在的時候,如果緩存存在,它還要取出緩存的生成時間和這個緩存所查詢的表,然後去查找這些表的最後更新時間,如果有一個表在生成時間後更新過了,那麼這個緩存是無效的。 可以看出,只要更新過一個表,那麼凡是涉及到這個表的查詢緩存就失效了,因此查詢緩存的命中率可能會比較低。 Collection緩存 需要在hbm的collection裏面設置:
假如class是Cat,collection叫children,那麼ehcache裏面配置
Collection的緩存和前面查詢緩存的list一樣,也是隻保持一串id,但它不會因爲這個表更新過就失效,一個collection緩存僅在這個collection裏面的元素有增刪時才失效。 這樣有一個問題,如果你的collection是根據某個字段排序的,當其中一個元素更新了該字段時,導致順序改變時,collection緩存裏面的順序沒有做更新。 緩存策略 ◆只讀緩存(read-only):沒有什麼好說的。 讀寫緩存和不嚴格讀寫緩存在實現上的區別在於,讀寫緩存更新緩存的時候會把緩存裏面的數據換成一個鎖,其他事務如果去取相應的緩存數據,發現被鎖住了,然後就直接取數據庫查詢。 在hibernate2.1的ehcache實現中,如果鎖住部分緩存的事務發生了異常,那麼緩存會一直被鎖住,直到60秒後超時。 不嚴格讀寫緩存不鎖定緩存中的數據。 使用二級緩存的前置條件。 你的hibernate程序對數據庫有獨佔的寫訪問權,其他的進程更新了數據庫,hibernate是不可能知道的。 你操作數據庫必需直接通過hibernate,如果你調用存儲過程,或者自己使用jdbc更新數據庫,hibernate也是不知道的。hibernate3.0的大批量更新和刪除是不更新二級緩存的,但是據說3.1已經解決了這個問題。 這個限制相當的棘手,有時候hibernate做批量更新、刪除很慢,但是你卻不能自己寫jdbc來優化,很鬱悶吧! SessionFactory也提供了移除緩存的方法,你一定要自己寫一些JDBC的話,可以調用這些方法移除緩存,這些方法是:
不過我不建議這樣做,因爲這樣很難維護。比如你現在用JDBC批量更新了某個表,有3個查詢緩存會用到這個表,用evictQueries(String cacheRegion)移除了3個查詢緩存,然後用evict(Class persistentClass)移除了class緩存,看上去好像完整了。不過哪天你添加了一個相關查詢緩存,可能會忘記更新這裏的移除代碼。如果你的jdbc代碼到處都是,在你添加一個查詢緩存的時候,還知道其他什麼地方也要做相應的改動嗎? 總結 不要想當然的以爲緩存一定能提高性能,僅僅在你能夠駕馭它並且條件合適的情況下才是這樣的。hibernate的二級緩存限制還是比較多的,不方便用jdbc可能會大大的降低更新性能。在不瞭解原理的情況下亂用,可能會有1+N的問題。不當的使用還可能導致讀出髒數據。 如果受不了hibernate的諸多限制,那麼還是自己在應用程序的層面上做緩存吧! 在越高的層面上做緩存,效果就會越好。就好像儘管磁盤有緩存,數據庫還是要實現自己的緩存,儘管數據庫有緩存,咱們的應用程序還是要做緩存。因爲底層的緩存它並不知道高層要用這些數據幹什麼,只能做的比較通用,而高層可以有針對性的實現緩存,所以在更高的級別上做緩存,效果也要好些吧! |
Hibernate二級緩存攻略
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.