Hibernate 和 MyBatis 究竟哪個(gè)更好用？

JAVA公眾號(hào)

共 4652字，需瀏覽 10分鐘

2020-08-31 00:22

作者：SylvanasSun鄭沐興
來(lái)源：https://zhuanlan.zhihu.com/p/21966051

前言

由于編程思想與數(shù)據(jù)庫(kù)的設(shè)計(jì)模式不同，生出了一些ORM框架。核心都是將關(guān)系型數(shù)據(jù)庫(kù)和數(shù)據(jù)轉(zhuǎn)成對(duì)象型。當(dāng)前流行的方案有Hibernate與myBatis。兩者各有優(yōu)劣。競(jìng)爭(zhēng)激烈，其中一個(gè)比較重要的考慮的地方就是性能。因此筆者通過(guò)各種實(shí)驗(yàn)，測(cè)出兩個(gè)在相同情景下的性能相關(guān)的指數(shù)，供大家參考。

測(cè)試目標(biāo)

以下測(cè)試需要確定幾點(diǎn)內(nèi)容：
性能差異的場(chǎng)景；
性能不在同場(chǎng)景下差異比；
找出各架框優(yōu)劣，各種情況下的表現(xiàn)，適用場(chǎng)景。

測(cè)試思路

測(cè)試總體分成：?jiǎn)伪聿迦耄P(guān)聯(lián)插入，單表查詢，多表查詢。
測(cè)試分兩輪，同場(chǎng)景下默認(rèn)參數(shù)做一輪，調(diào)優(yōu)做強(qiáng)一輪，橫縱對(duì)比分析了。
測(cè)試中盡保證輸入輸出的一致性。
樣本量盡可能大,達(dá)到10萬(wàn)級(jí)別以上，減少統(tǒng)計(jì)誤差。

測(cè)試提綱

具體的場(chǎng)景情況下
插入測(cè)試1：10萬(wàn)條記錄插入。
查詢測(cè)試1：100萬(wàn)數(shù)據(jù)中單表通過(guò)id查詢100000次,無(wú)關(guān)聯(lián)字段。
查詢測(cè)試2：100萬(wàn)數(shù)據(jù)中單表通過(guò)id查詢100000次,輸出關(guān)聯(lián)對(duì)象字段。
查詢測(cè)試3：100萬(wàn)*50萬(wàn)關(guān)聯(lián)數(shù)據(jù)中查詢100000次,兩者輸出相同字段。

準(zhǔn)備

數(shù)據(jù)庫(kù):mysql 5.6
表格設(shè)計(jì)：
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

測(cè)試數(shù)據(jù)準(zhǔn)備：

表一：twitter
無(wú)數(shù)據(jù)。

表二：user
50萬(wàn)個(gè)隨機(jī)的用戶名。

隨機(jī)內(nèi)容推特表(material_twitter)
無(wú)id，僅有隨機(jī)字符串內(nèi)容，共10萬(wàn)條。
用于插入控推特表。

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

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ù)代碼,關(guān)聯(lián)500000個(gè)用戶：

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

實(shí)體代碼

@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;
??}
??@Transient
??public?String getCreateUserName()?{
????return?createUserName;
??}
??public?void?setCreateUserName(String createUserName)?{
????this.createUserName = createUserName;
??}
??
}

開(kāi)始

插入測(cè)試1

代碼操作：
將隨機(jī)內(nèi)容推特表的數(shù)據(jù)加載到內(nèi)存中,然后一條條加入到推特表中,共10萬(wàn)條。

關(guān)鍵代碼:
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>

查詢測(cè)試1

通過(guò)id從1遞增到10萬(wàn)依次進(jìn)行查詢推特內(nèi)容，僅輸出微博內(nèi)容。
關(guān)鍵代碼:
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());
????}

查詢測(cè)試2

與查詢測(cè)試1總體一樣，增加微博的創(chuàng)建人名稱字段,此處需要關(guān)聯(lián)。
其中微博對(duì)應(yīng)有10萬(wàn)個(gè)用戶。可能一部份用戶重復(fù)。這里對(duì)應(yīng)的用戶數(shù)可能與hibernate配懶加載的情況有影響。

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

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

此處hibernate則會(huì)分別測(cè)試有懶加載，無(wú)懶加載。
mybatis會(huì)測(cè)有默認(rèn)與有緩存兩者情況。

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

測(cè)試時(shí)，對(duì)推特關(guān)聯(lián)的用戶數(shù)做了兩種情況，一種是推特共關(guān)聯(lián)了100個(gè)用戶，也就是不同的推特也就是在100個(gè)用戶內(nèi)，這里的關(guān)聯(lián)關(guān)系隨機(jī)生成。
另外一種是推特共關(guān)聯(lián)了50萬(wàn)個(gè)用戶，基本上50個(gè)用戶的信息都會(huì)被查詢出來(lái)。

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

關(guān)鍵代碼:
hibernate:

long?cnt = 100000;
for(long?i = 1; i <= cnt; ++i){
??????Twitter t = (Twitter)session.get(Twitter.class, i);
??????t.getAddUser().getName();//加載相應(yīng)字段
??????//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,user
?????????where?twitter.id=#{id}
???????????AND twitter.add_user_id=user.id

?????select>

測(cè)試結(jié)果

測(cè)試分析

測(cè)試分成了插入，單表查詢，關(guān)聯(lián)查詢。關(guān)聯(lián)查詢中hibernate分成三種情況進(jìn)行配置。其中在關(guān)聯(lián)字段查詢中，hibernate在兩種情況下，性能差異比較大。都是在懶加載的情況下，如果推特對(duì)應(yīng)的用戶比較多時(shí)，則性能會(huì)比僅映射100個(gè)用戶的情況要差很多。

換而言之，如果用戶數(shù)量少(關(guān)聯(lián)的總用戶數(shù))時(shí)，也就是會(huì)重復(fù)查詢同一個(gè)用戶的情況下，則不需要對(duì)用戶表做太多的查詢。其中通過(guò)查詢文檔后，證明使用懶加載時(shí)，對(duì)象會(huì)以id為key做緩存，也就是查詢了100個(gè)用戶后，后續(xù)的用戶信息使用了緩存，使性能有根本性的提高。甚至要比myBatis更高。

如果是關(guān)聯(lián)50萬(wàn)用戶的情況下,則hibernate需要去查詢50萬(wàn)次用戶信息,并組裝這50萬(wàn)個(gè)用戶，此時(shí)性能要比myBatis性能要差，不過(guò)差異不算大，小于1ms，表示可以接受。其中hibernate非懶加載情況下與myBatis性能差異也是相對(duì)其他測(cè)試較大，平均值小于1ms。

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

hibernate這種情況下有好有壞，要看具體的場(chǎng)景，對(duì)于管理平臺(tái)，需要展現(xiàn)的信息較多，并發(fā)要求不高時(shí)，hibernate比較有優(yōu)勢(shì)。
然而在一些小活動(dòng)，互聯(lián)網(wǎng)網(wǎng)站，高并發(fā)情況下，hibernate的方案太不太適合,myBatis+VO則是首選。

測(cè)試總結(jié)

總體初觀，myBatis在所有情況下，特別是插入與單表查詢，都會(huì)微微優(yōu)于hibernate。不過(guò)差異情況并不明顯，可以基本忽略差異。差異比較大的是關(guān)聯(lián)查詢時(shí)，hibernate為了保證POJO的數(shù)據(jù)完整性，需要將關(guān)聯(lián)的數(shù)據(jù)加載，需要額外地查詢更多的數(shù)據(jù)。這里hibernate并沒(méi)有提供相應(yīng)的靈活性。

關(guān)聯(lián)時(shí)一個(gè)差異比較大的地方則是懶加載特性。其中hibernate可以特別地利用POJO完整性來(lái)進(jìn)行緩存，可以在一級(jí)與二級(jí)緩存上保存對(duì)象，如果對(duì)單一個(gè)對(duì)象查詢比較多的話，會(huì)有很明顯的性能效益。以后關(guān)于單對(duì)象關(guān)聯(lián)時(shí)，可以通過(guò)懶加載加二級(jí)緩存的方式來(lái)提升性能。

最后，數(shù)據(jù)查詢的性能與orm框架關(guān)無(wú)太大的關(guān)系，因?yàn)閛rm主要幫助開(kāi)發(fā)人員將關(guān)系數(shù)據(jù)轉(zhuǎn)化成對(duì)象型數(shù)據(jù)模型，對(duì)代碼的深析上來(lái)看，hibernate設(shè)計(jì)得比較重量級(jí)，對(duì)開(kāi)發(fā)來(lái)說(shuō)可以算是重新開(kāi)發(fā)了一個(gè)數(shù)據(jù)庫(kù)，不讓開(kāi)發(fā)去過(guò)多關(guān)心數(shù)據(jù)庫(kù)的特性，直接在hibernate基礎(chǔ)上進(jìn)行開(kāi)發(fā)，執(zhí)行上分為了sql生成，數(shù)據(jù)封裝等過(guò)程，這里花了大量的時(shí)間。

然而myBatis則比直接，主要是做關(guān)聯(lián)與輸出字段之間的一個(gè)映射。其中sql基本是已經(jīng)寫(xiě)好，直接做替換則可，不需要像hibernate那樣去動(dòng)態(tài)生成整條sql語(yǔ)句。

好在hibernate在這階段已經(jīng)優(yōu)化得比較好，沒(méi)有比myBatis在性能上差異太多，但是在開(kāi)發(fā)效率上，可擴(kuò)展性上相對(duì)myBatis來(lái)說(shuō)好太多。最后的最后，關(guān)于myBatis緩存，hibernate查詢緩等，后續(xù)會(huì)再專門(mén)做一篇測(cè)試。

關(guān)于緩存配置

myBatis相對(duì)Hibernate 等封裝較為嚴(yán)密的ORM 實(shí)現(xiàn)而言,因?yàn)閔ibernate對(duì)數(shù)據(jù)對(duì)象的操作實(shí)現(xiàn)了較為嚴(yán)密的封裝，可以保證其作用范圍內(nèi)的緩存同步，而ibatis 提供的是半封閉的封裝實(shí)現(xiàn)，因此對(duì)緩存的操作難以做到完全的自動(dòng)化同步。以上的緩存配置測(cè)試僅為性能上的分析，沒(méi)有加入可用性上的情況，因?yàn)閙yBatis直接配置緩存的話，可能會(huì)出現(xiàn)臟數(shù)據(jù)。

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

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

更多精彩?

在公眾號(hào)【程序員編程】對(duì)話框輸入以下關(guān)鍵詞
查看更多優(yōu)質(zhì)內(nèi)容！

大數(shù)據(jù)?|?Java?|?1024?|?電子書(shū)?|?速查表?
Python進(jìn)階?|?面試?|?手冊(cè)?|?成神?|?思想?|?小程序
命令行?|?人工智能?|?軟件測(cè)試?|?Web前端?|?Python

掃碼關(guān)注我們
獲取更多學(xué)習(xí)資料
視頻 |?面試 |?技術(shù) | 電子書(shū)?