前言

由于編程思想與數(shù)據(jù)庫的設計模式不同，生出了一些ORM框架。

核心都是將關系型數(shù)據(jù)庫和數(shù)據(jù)轉成對象型。當前流行的方案有Hibernate與myBatis。

兩者各有優(yōu)劣。競爭激烈，其中一個比較重要的考慮的地方就是性能。

因此筆者通過各種實驗，測出兩個在相同情景下的性能相關的指數(shù)，供大家參考。

友情提示：如果你嫌棄文章太長，可以拉到文末看結論即可。

測試目標

以下測試需要確定幾點內容：

性能差異的場景；

性能不在同場景下差異比；

找出各架框優(yōu)劣，各種情況下的表現(xiàn)，適用場景。

測試思路

測試總體分成：單表插入，關聯(lián)插入，單表查詢，多表查詢。

測試分兩輪，同場景下默認參數(shù)做一輪，調優(yōu)做強一輪，橫縱對比分析了。

測試中盡保證輸入輸出的一致性。

樣本量盡可能大,達到10萬級別以上，減少統(tǒng)計誤差。

測試提綱

具體的場景情況下

插入測試1：10萬條記錄插入。

查詢測試1：100萬數(shù)據(jù)中單表通過id查詢100000次,無關聯(lián)字段。

查詢測試2：100萬數(shù)據(jù)中單表通過id查詢100000次,輸出關聯(lián)對象字段。

查詢測試3：100萬*50萬關聯(lián)數(shù)據(jù)中查詢100000次,兩者輸出相同字段。

?

準備

數(shù)據(jù)庫:mysql 5.6

表格設計：

twitter:推特

CREATE?TABLE?`twitter`?(`id`?bigint(20)?NOT?NULL?AUTO_INCREMENT,`add_date`?datetime?DEFAULT?NULL,`modify_date`?datetime?DEFAULT?NULL,`ctx`?varchar(255)?NOT?NULL,`add_user_id`?bigint(20)?DEFAULT?NULL,`modify_user_id`?bigint(20)?DEFAULT?NULL,PRIMARY?KEY?(`id`),KEY?`UPDATE_USER_FORI`?(`modify_user_id`),KEY?`ADD_USER_FORI`?(`add_user_id`),CONSTRAINT?`ADD_USER_FORI`?FOREIGN?KEY?(`add_user_id`)?REFERENCES?`user`?(`id`)?ON?DELETE?SET?NULL,CONSTRAINT?`UPDATE_USER_FORI`?FOREIGN?KEY?(`modify_user_id`)?REFERENCES?`user`?(`id`)?ON?DELETE?SET?NULL )?ENGINE=InnoDB?AUTO_INCREMENT=1048561?DEFAULT?CHARSET=utf8

user: 用戶

CREATE?TABLE?`user`?(`id`?bigint(20)?NOT?NULL?AUTO_INCREMENT,`name`?varchar(255)?DEFAULT?NULL,PRIMARY?KEY?(`id`) )?ENGINE=InnoDB?AUTO_INCREMENT=524281?DEFAULT?CHARSET=utf8

測試數(shù)據(jù)準備：

表一：twitter

無數(shù)據(jù)。

表二：user

50萬個隨機的用戶名。

隨機內容推特表(material_twitter)

無id，僅有隨機字符串內容，共10萬條。

用于插入控推特表。

生成數(shù)據(jù)代碼,關聯(lián)100個用戶:

insert?into?twitter(ctx,add_user_id,modify_user_id,add_date,modify_date) SELECT?name,ROUND(RAND()*100)+1,ROUND(RAND()*100)+1,'2016-12-31','2016-12-31' from?MATERIAL

生成數(shù)據(jù)代碼,關聯(lián)500000個用戶:

insert?into?twitter(ctx,add_user_id,modify_user_id,add_date,modify_date) SELECT?name,ROUND(RAND()*500000)+1,ROUND(RAND()*500000)+1,'2016-12-31','2016-12-31' from?MATERIAL

實體代碼

@Entity @Table(name?=?"twitter") public?class?Twitter?implements?java.io.Serializable{private?Long?id;private?Date?add_date;private?Date?modify_date;private?String?ctx;private?User?add_user;private?User?modify_user;private?String?createUserName;@Id@GeneratedValue(strategy?=?IDENTITY)@Column(name?=?"id",?unique?=?true,?nullable?=?false)public?Long?getId()?{return?id;}public?void?setId(Long?id)?{this.id?=?id;}@Temporal(TemporalType.DATE)@Column(name?=?"add_date")public?Date?getAddDate()?{return?add_date;}public?void?setAddDate(Date?add_date)?{this.add_date?=?add_date;}@Temporal(TemporalType.DATE)@Column(name?=?"modify_date")public?Date?getModifyDate()?{return?modify_date;}public?void?setModifyDate(Date?modify_date)?{this.modify_date?=?modify_date;}@Column(name?=?"ctx")public?String?getCtx()?{return?ctx;}public?void?setCtx(String?ctx)?{this.ctx?=?ctx;}@ManyToOne(fetch?=?FetchType.LAZY)@JoinColumn(name?=?"add_user_id")public?User?getAddUser()?{return?add_user;}public?void?setAddUser(User?add_user)?{this.add_user?=?add_user;}@ManyToOne(fetch?=?FetchType.LAZY)@JoinColumn(name?=?"modify_user_id")public?User?getModifyUser()?{return?modify_user;}public?void?setModifyUser(User?modify_user)?{this.modify_user?=?modify_user;}@Transientpublic?String?getCreateUserName()?{return?createUserName;}public?void?setCreateUserName(String?createUserName)?{this.createUserName?=?createUserName;}}

開始

插入測試1

代碼操作：

將隨機內容推特表的數(shù)據(jù)加載到內存中,然后一條條加入到推特表中,共10萬條。

關鍵代碼:

hibernate:

Session?session?=?factory.openSession(); session.beginTransaction(); Twitter?t?=?null; Date?now?=?new?Date(); for(String?materialTwitter?:?materialTwitters){ //????????????System.out.println("materialTwitter="+materialTwitter);t?=?new?Twitter();t.setCtx(materialTwitter);t.setAddDate(now);t.setModifyDate(now);t.setAddUser(null);t.setModifyUser(null);session.save(t); }session.getTransaction().commit();

mybatis:

Twitter?t?=?null; Date?now?=?new?Date(); for(String?materialTwitter?:?materialTwitters){ //????????????System.out.println("materialTwitter="+materialTwitter);t?=?new?Twitter();t.setCtx(materialTwitter);t.setAddDate(now);t.setModifyDate(now);t.setAddUser(null);t.setModifyUser(null);msession.insert("insertTwitter",?t); } msession.commit();

TwitterMapper.xml,插入代碼片段:

<insert?id="insertTwitter"?keyProperty="id"?parameterType="org.pushio.test.show1.entity.Twitter"?useGeneratedKeys="true">??insert?into?twitter(ctx,?add_date,modify_date)?values?(#{ctx},#{add_date},#{modify_date}) </insert>

?

查詢測試1

通過id從1遞增到10萬依次進行查詢推特內容，僅輸出微博內容。

關鍵代碼:

hibernate:

long?cnt?=?100000; for(long?i?=?1;?i?<=?cnt;?++i){Twitter?t?=?(Twitter)session.get(Twitter.class,?i);//System.out.println("t.getCtx="+?t.getCtx()?+?"?t.getUser.getName="?+?t.getAddUser().getName()); }

mybatis:

long?cnt?=?100000; for(long?i?=?1;?i?<=?cnt;?++i){Twitter?t?=?(Twitter)msession.selectOne("getTwitter",?i);//System.out.println("t.getCtx="+?t.getCtx()?+?"?t.getUser.getName="?+?t.getAddUser().getName()); }

查詢測試2

與查詢測試1總體一樣，增加微博的創(chuàng)建人名稱字段,此處需要關聯(lián)。

其中微博對應有10萬個用戶。可能一部份用戶重復。這里對應的用戶數(shù)可能與hibernate配懶加載的情況有影響。

此處體現(xiàn)了hibernate的一個方便處，可以直接通過getAddUser()可以取得user相關的字段。

然而myBatis則需要編寫新的vo，因此在測試batis時則直接在Twitter實體中增加創(chuàng)建人員名字成員(createUserName)。

此處hibernate則會分別測試有懶加載，無懶加載。

mybatis會測有默認與有緩存兩者情況。

其中mybatis的緩存機制比較難有效配置，不適用于真實業(yè)務(可能會有臟數(shù)據(jù))，在此僅供參考。

測試時，對推特關聯(lián)的用戶數(shù)做了兩種情況，一種是推特共關聯(lián)了100個用戶，也就是不同的推特也就是在100個用戶內，這里的關聯(lián)關系隨機生成。

另外一種是推特共關聯(lián)了50萬個用戶，基本上50個用戶的信息都會被查詢出來。

在上文“準備”中可以看到關聯(lián)數(shù)據(jù)生成方式。

關鍵代碼:

hibernate:

long?cnt?=?100000; for(long?i?=?1;?i?<=?cnt;?++i){Twitter?t?=?(Twitter)session.get(Twitter.class,?i);t.getAddUser().getName();//加載相應字段//System.out.println("t.getCtx="+?t.getCtx()?+?"?t.getUser.getName="?+?t.getAddUser().getName()); }

急懶加載配置更改處,Twitter.java:

@ManyToOne(fetch?=?FetchType.EAGER)//急加載//@ManyToOne(fetch?=?FetchType.LAZY)//懶加載 @JoinColumn(name?=?"add_user_id") public?User?getAddUser()?{return?add_user; }

mybatis:

for(long?i?=?1;?i?<=?cnt;?++i){Twitter?t?=?(Twitter)msession.selectOne("getTwitterHasUser",?i);//?System.out.println("t.getCtx="+?t.getCtx()?+?"?t.getUser.getName="?+?t.getCreateUserName()); }

TwitterMapper.xml配置：

<select?id="getTwitterHasUser"?parameterType="long"?resultType="org.pushio.test.show1.entity.Twitter">select?twitter.*,user.name?as?creteUserName?from?twitter,userwhere?twitter.id=#{id}AND?twitter.add_user_id=user.id</select>

?

測試結果

測試分析

測試分成了插入，單表查詢，關聯(lián)查詢。關聯(lián)查詢中hibernate分成三種情況進行配置。

其中在關聯(lián)字段查詢中，hibernate在兩種情況下，性能差異比較大。 都是在懶加載的情況下，如果推特對應的用戶比較多時，則性能會比僅映射100個用戶的情況要差很多。

換而言之，如果用戶數(shù)量少(關聯(lián)的總用戶數(shù))時，也就是會重復查詢同一個用戶的情況下，則不需要對用戶表做太多的查詢。

其中通過查詢文檔后，證明使用懶加載時，對象會以id為key做緩存，也就是查詢了100個用戶后，后續(xù)的用戶信息使用了緩存，使性能有根本性的提高。甚至要比myBatis更高。

如果是關聯(lián)50萬用戶的情況下,則hibernate需要去查詢50萬次用戶信息,并組裝這50萬個用戶，此時性能要比myBatis性能要差，不過差異不算大，小于1ms，表示可以接受。

其中hibernate非懶加載情況下與myBatis性能差異也是相對其他測試較大，平均值小于1ms。

這個差異的原因主要在于，myBatis加載的字段很干凈，沒有太多多余的字段，直接映身入關聯(lián)中。反觀hibernate則將整個表的字都會加載到對象中，其中還包括關聯(lián)的user字段。

hibernate這種情況下有好有壞，要看具體的場景，對于管理平臺，需要展現(xiàn)的信息較多，并發(fā)要求不高時，hibernate比較有優(yōu)勢。

然而在一些小活動，互聯(lián)網(wǎng)網(wǎng)站，高并發(fā)情況下，hibernate的方案太不太適合,myBatis+VO則是首選。

測試總結

總體初觀，myBatis在所有情況下，特別是插入與單表查詢，都會微微優(yōu)于hibernate。不過差異情況并不明顯，可以基本忽略差異。

差異比較大的是關聯(lián)查詢時，hibernate為了保證POJO的數(shù)據(jù)完整性，需要將關聯(lián)的數(shù)據(jù)加載，需要額外地查詢更多的數(shù)據(jù)。這里hibernate并沒有提供相應的靈活性。

關聯(lián)時一個差異比較大的地方則是懶加載特性。其中hibernate可以特別地利用POJO完整性來進行緩存，可以在一級與二級緩存上保存對象，如果對單一個對象查詢比較多的話，會有很明顯的性能效益。

以后關于單對象關聯(lián)時，可以通過懶加載加二級緩存的方式來提升性能。

最后，數(shù)據(jù)查詢的性能與orm框架關無太大的關系，因為orm主要幫助開發(fā)人員將關系數(shù)據(jù)轉化成對象型數(shù)據(jù)模型，對代碼的深析上來看，hibernate設計得比較重量級，對開發(fā)來說可以算是重新開發(fā)了一個數(shù)據(jù)庫，不讓開發(fā)去過多關心數(shù)據(jù)庫的特性，直接在hibernate基礎上進行開發(fā)，執(zhí)行上分為了sql生成，數(shù)據(jù)封裝等過程，這里花了大量的時間。然而myBatis則比直接，主要是做關聯(lián)與輸出字段之間的一個映射。其中sql基本是已經(jīng)寫好，直接做替換則可，不需要像hibernate那樣去動態(tài)生成整條sql語句。

好在hibernate在這階段已經(jīng)優(yōu)化得比較好，沒有比myBatis在性能上差異太多，但是在開發(fā)效率上，可擴展性上相對myBatis來說好太多。

最后的最后，關于myBatis緩存，hibernate查詢緩等，后續(xù)會再專門做一篇測試。

關于緩存配置

myBatis相對Hibernate 等封裝較為嚴密的ORM 實現(xiàn)而言,因為hibernate對數(shù)據(jù)對象的操作實現(xiàn)了較為嚴密的封裝，可以保證其作用范圍內的緩存同步，而ibatis 提供的是半封閉的封裝實現(xiàn)，因此對緩存的操作難以做到完全的自動化同步。

以上的緩存配置測試僅為性能上的分析，沒有加入可用性上的情況，因為myBatis直接配置緩存的話，可能會出現(xiàn)臟數(shù)據(jù),。

在關聯(lián)查詢數(shù)據(jù)的情況下，hiberntae的懶加載配二級緩存是個比較好的方案(無臟數(shù)據(jù))，也是與myBatis相比有比較明顯的優(yōu)勢。此情景下，性能與myBatis持平。

在真實情況下，myBatis可能不會在這個地方上配置緩存,會出現(xiàn)臟數(shù)據(jù)的情況，因而很有可能在此hibernate性能會更好。

來源：https://zhuanlan.zhihu.com/p/21966051

總結

以上是生活随笔為你收集整理的MyBatis 与 Hibernate 到底哪个更快？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。