天天看點

MyBatis vs Hibernate,到底哪個性能更好?開始

前言

由于程式設計思想與資料庫的設計模式不同,生出了一些ORM架構。

核心都是将關系型資料庫和資料轉成對象型。目前流行的方案有Hibernate與myBatis。

兩者各有優劣。競争激烈,其中一個比較重要的考慮的地方就是性能。

是以筆者通過各種實驗,測出兩個在相同情景下的性能相關的指數,供大家參考。

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

測試目标

以下測試需要确定幾點内容:

性能差異的場景;

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

找出各架框優劣,各種情況下的表現,适用場景。

測試思路

測試總體分成:單表插入,關聯插入,單表查詢,多表查詢。

測試分兩輪,同場景下預設參數做一輪,調優做強一輪,橫縱對比分析了。

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

樣本量盡可能大,達到10萬級别以上,減少統計誤差。

測試提綱

具體的場景情況下

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

查詢測試1:100萬資料中單表通過id查詢100000次,無關聯字段。

查詢測試2:100萬資料中單表通過id查詢100000次,輸出關聯對象字段。

查詢測試3:100萬*50萬關聯資料中查詢100000次,兩者輸出相同字段。

準備

資料庫: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      

測試資料準備:

表一:twitter

無資料。

表二:user

50萬個随機的使用者名。

随機内容推特表(material_twitter)

無id,僅有随機字元串内容,共10萬條。

用于插入控推特表。

生成資料代碼,關聯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      

生成資料代碼,關聯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

代碼操作:

将随機内容推特表的資料加載到記憶體中,然後一條條加入到推特表中,共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萬依次進行查詢推特内容,僅輸出微網誌内容。

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());
}      
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總體一樣,增加微網誌的建立人名稱字段,此處需要關聯。

其中微網誌對應有10萬個使用者。可能一部份使用者重複。這裡對應的使用者數可能與hibernate配懶加載的情況有影響。

此處展現了hibernate的一個友善處,可以直接通過getAddUser()可以取得user相關的字段。

然而myBatis則需要編寫新的vo,是以在測試batis時則直接在Twitter實體中增加建立人員名字成員(createUserName)。

此處hibernate則會分别測試有懶加載,無懶加載。

mybatis會測有預設與有緩存兩者情況。

其中mybatis的緩存機制比較難有效配置,不适用于真實業務(可能會有髒資料),在此僅供參考。

測試時,對推特關聯的使用者數做了兩種情況,一種是推特共關聯了100個使用者,也就是不同的推特也就是在100個使用者内,這裡的關聯關系随機生成。

另外一種是推特共關聯了50萬個使用者,基本上50個使用者的資訊都會被查詢出來。

在上文“準備”中可以看到關聯資料生成方式。

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;
}      
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>      

測試結果

MyBatis vs Hibernate,到底哪個性能更好?開始

測試分析

測試分成了插入,單表查詢,關聯查詢。關聯查詢中hibernate分成三種情況進行配置。

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

換而言之,如果使用者數量少(關聯的總使用者數)時,也就是會重複查詢同一個使用者的情況下,則不需要對使用者表做太多的查詢。

其中通過查詢文檔後,證明使用懶加載時,對象會以id為key做緩存,也就是查詢了100個使用者後,後續的使用者資訊使用了緩存,使性能有根本性的提高。甚至要比myBatis更高。

如果是關聯50萬使用者的情況下,則hibernate需要去查詢50萬次使用者資訊,并組裝這50萬個使用者,此時性能要比myBatis性能要差,不過差異不算大,小于1ms,表示可以接受。

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

這個差異的原因主要在于,myBatis加載的字段很幹淨,沒有太多多餘的字段,直接映身入關聯中。反觀hibernate則将整個表的字都會加載到對象中,其中還包括關聯的user字段。

hibernate這種情況下有好有壞,要看具體的場景,對于管理平台,需要展現的資訊較多,并發要求不高時,hibernate比較有優勢。

然而在一些小活動,網際網路網站,高并發情況下,hibernate的方案太不太适合,myBatis+VO則是首選。

另外,關注公衆号Java技術棧,在背景回複:面試,可以擷取我整理的 MyBatis 系列面試題和答案,非常齊全。

測試總結

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

差異比較大的是關聯查詢時,hibernate為了保證POJO的資料完整性,需要将關聯的資料加載,需要額外地查詢更多的資料。這裡hibernate并沒有提供相應的靈活性。

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

以後關于單對象關聯時,可以通過懶加載加二級緩存的方式來提升性能。

最後,資料查詢的性能與orm架構關無太大的關系,因為orm主要幫助開發人員将關系資料轉化成對象型資料模型,對代碼的深析上來看,hibernate設計得比較重量級,對開發來說可以算是重新開發了一個資料庫,不讓開發去過多關心資料庫的特性,直接在hibernate基礎上進行開發,執行上分為了sql生成,資料封裝等過程,這裡花了大量的時間。然而myBatis則比直接,主要是做關聯與輸出字段之間的一個映射。其中sql基本是已經寫好,直接做替換則可,不需要像hibernate那樣去動态生成整條sql語句。

好在hibernate在這階段已經優化得比較好,沒有比myBatis在性能上差異太多,但是在開發效率上,可擴充性上相對myBatis來說好太多。

最後的最後,關于myBatis緩存,hibernate查詢緩等,後續會再專門做一篇測試。

關于緩存配置

myBatis相對Hibernate 等封裝較為嚴密的ORM 實作而言,因為hibernate對資料對象的操作實作了較為嚴密的封裝,可以保證其作用範圍内的緩存同步,而ibatis 提供的是半封閉的封裝實作,是以對緩存的操作難以做到完全的自動化同步。

以上的緩存配置測試僅為性能上的分析,沒有加入可用性上的情況,因為myBatis直接配置緩存的話,可能會出現髒資料,。

在關聯查詢資料的情況下,hiberntae的懶加載配二級緩存是個比較好的方案(無髒資料),也是與myBatis相比有比較明顯的優勢。此情景下,性能與myBatis持平。

在真實情況下,myBatis可能不會在這個地方上配置緩存,會出現髒資料的情況,因而很有可能在此hibernate性能會更好。