MyBatis vs Hibernate，到底哪個性能更好？
點擊“藍字”，關(guān)注，置頂公眾號
每日技術(shù)干貨，第一時間送達！
前言
由于編程思想與數(shù)據(jù)庫的設(shè)計模式不同，生出了一些ORM框架。
核心都是將關(guān)系型數(shù)據(jù)庫和數(shù)據(jù)轉(zhuǎn)成對象型。當(dāng)前流行的方案有Hibernate與myBatis。
兩者各有優(yōu)劣。競爭激烈，其中一個比較重要的考慮的地方就是性能。
因此筆者通過各種實驗，測出兩個在相同情景下的性能相關(guān)的指數(shù)，供大家參考。
友情提示：如果你嫌棄文章太長，可以拉到文末看結(jié)論即可。
測試目標(biāo)
以下測試需要確定幾點內(nèi)容：
性能差異的場景；
性能不在同場景下差異比；
找出各架框優(yōu)劣，各種情況下的表現(xiàn)，適用場景。
測試思路
測試總體分成：單表插入，關(guān)聯(lián)插入，單表查詢，多表查詢。
測試分兩輪，同場景下默認參數(shù)做一輪，調(diào)優(yōu)做強一輪，橫縱對比分析了。
測試中盡保證輸入輸出的一致性。
樣本量盡可能大,達到10萬級別以上，減少統(tǒng)計誤差。
測試提綱
具體的場景情況下
插入測試1：10萬條記錄插入。
查詢測試1：100萬數(shù)據(jù)中單表通過id查詢100000次,無關(guān)聯(lián)字段。
查詢測試2：100萬數(shù)據(jù)中單表通過id查詢100000次,輸出關(guān)聯(lián)對象字段。
查詢測試3：100萬*50萬關(guān)聯(lián)數(shù)據(jù)中查詢100000次,兩者輸出相同字段。
準備
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
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
隨機內(nèi)容推特表(material_twitter)
生成數(shù)據(jù)代碼,關(guān)聯(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ù)代碼,關(guān)聯(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;
}
@Transient
public String getCreateUserName() {
return createUserName;
}
public void setCreateUserName(String createUserName) {
this.createUserName = createUserName;
}
}
開始
插入測試1
代碼操作：
將隨機內(nèi)容推特表的數(shù)據(jù)加載到內(nèi)存中,然后一條條加入到推特表中,共10萬條。
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();
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();
<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>
通過id從1遞增到10萬依次進行查詢推特內(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());
}
查詢測試2
與查詢測試1總體一樣，增加微博的創(chuàng)建人名稱字段,此處需要關(guān)聯(lián)。
其中微博對應(yīng)有10萬個用戶。可能一部份用戶重復(fù)。這里對應(yīng)的用戶數(shù)可能與hibernate配懶加載的情況有影響。
此處體現(xiàn)了hibernate的一個方便處，可以直接通過getAddUser()可以取得user相關(guān)的字段。
然而myBatis則需要編寫新的vo，因此在測試batis時則直接在Twitter實體中增加創(chuàng)建人員名字成員(createUserName)。
此處hibernate則會分別測試有懶加載，無懶加載。
mybatis會測有默認與有緩存兩者情況。
其中mybatis的緩存機制比較難有效配置，不適用于真實業(yè)務(wù)(可能會有臟數(shù)據(jù))，在此僅供參考。
測試時，對推特關(guān)聯(lián)的用戶數(shù)做了兩種情況，一種是推特共關(guān)聯(lián)了100個用戶，也就是不同的推特也就是在100個用戶內(nèi)，這里的關(guān)聯(lián)關(guān)系隨機生成。
另外一種是推特共關(guān)聯(lián)了50萬個用戶，基本上50個用戶的信息都會被查詢出來。
在上文“準備”中可以看到關(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>
測試結(jié)果
測試分析
測試分成了插入，單表查詢，關(guān)聯(lián)查詢。關(guān)聯(lián)查詢中hibernate分成三種情況進行配置。
其中在關(guān)聯(lián)字段查詢中，hibernate在兩種情況下，性能差異比較大。都是在懶加載的情況下，如果推特對應(yīng)的用戶比較多時，則性能會比僅映射100個用戶的情況要差很多。
換而言之，如果用戶數(shù)量少(關(guān)聯(lián)的總用戶數(shù))時，也就是會重復(fù)查詢同一個用戶的情況下，則不需要對用戶表做太多的查詢。
其中通過查詢文檔后，證明使用懶加載時，對象會以id為key做緩存，也就是查詢了100個用戶后，后續(xù)的用戶信息使用了緩存，使性能有根本性的提高。甚至要比myBatis更高。
如果是關(guān)聯(lián)50萬用戶的情況下,則hibernate需要去查詢50萬次用戶信息,并組裝這50萬個用戶，此時性能要比myBatis性能要差，不過差異不算大，小于1ms，表示可以接受。
其中hibernate非懶加載情況下與myBatis性能差異也是相對其他測試較大，平均值小于1ms。
這個差異的原因主要在于，myBatis加載的字段很干凈，沒有太多多余的字段，直接映身入關(guān)聯(lián)中。反觀hibernate則將整個表的字都會加載到對象中，其中還包括關(guān)聯(lián)的user字段。
hibernate這種情況下有好有壞，要看具體的場景，對于管理平臺，需要展現(xiàn)的信息較多，并發(fā)要求不高時，hibernate比較有優(yōu)勢。
然而在一些小活動，互聯(lián)網(wǎng)網(wǎng)站，高并發(fā)情況下，hibernate的方案太不太適合,myBatis+VO則是首選。
測試總結(jié)
總體初觀，myBatis在所有情況下，特別是插入與單表查詢，都會微微優(yōu)于hibernate。不過差異情況并不明顯，可以基本忽略差異。
以后關(guān)于單對象關(guān)聯(lián)時，可以通過懶加載加二級緩存的方式來提升性能。
好在hibernate在這階段已經(jīng)優(yōu)化得比較好，沒有比myBatis在性能上差異太多，但是在開發(fā)效率上，可擴展性上相對myBatis來說好太多。
最后的最后，關(guān)于myBatis緩存，hibernate查詢緩等，后續(xù)會再專門做一篇測試。
關(guān)于緩存配置
myBatis相對Hibernate 等封裝較為嚴密的ORM 實現(xiàn)而言,因為hibernate對數(shù)據(jù)對象的操作實現(xiàn)了較為嚴密的封裝，可以保證其作用范圍內(nèi)的緩存同步，而ibatis 提供的是半封閉的封裝實現(xiàn)，因此對緩存的操作難以做到完全的自動化同步。
以上的緩存配置測試僅為性能上的分析，沒有加入可用性上的情況，因為myBatis直接配置緩存的話，可能會出現(xiàn)臟數(shù)據(jù),。
在關(guān)聯(lián)查詢數(shù)據(jù)的情況下，hiberntae的懶加載配二級緩存是個比較好的方案(無臟數(shù)據(jù))，也是與myBatis相比有比較明顯的優(yōu)勢。此情景下，性能與myBatis持平。
在真實情況下，myBatis可能不會在這個地方上配置緩存,會出現(xiàn)臟數(shù)據(jù)的情況，因而很有可能在此hibernate性能會更好。
作者：鄭沐興
來源：https://zhuanlan.zhihu.com/p/21966051
往期推薦