摘要：系列文章地址原文地址一個(gè)高性能的數(shù)據(jù)訪問層需要很多關(guān)于數(shù)據(jù)庫(kù)的內(nèi)部結(jié)構(gòu)以及很多優(yōu)化商業(yè)應(yīng)用的技術(shù)建議。在語(yǔ)句中的表現(xiàn)最好，不過(guò)不能使用約束，數(shù)據(jù)完整性的控制較差。應(yīng)用層的緩存則利用高速副本的方式來(lái)保證低響應(yīng)時(shí)間。

Github系列文章地址

原文地址

一個(gè)高性能的數(shù)據(jù)訪問層需要很多關(guān)于數(shù)據(jù)庫(kù)的內(nèi)部結(jié)構(gòu)、JDBC、JPA、Hibernate以及很多優(yōu)化商業(yè)應(yīng)用的技術(shù)建議。

如果你正在使用譬如Hibernate或者M(jìn)yBatis這樣的ORM框架，那么可以參考驗(yàn)證執(zhí)行語(yǔ)句的效率。另外推薦一個(gè) 測(cè)試中斷言機(jī)制 可以幫你在提交代碼之前就發(fā)現(xiàn)很多的查詢問題。

數(shù)據(jù)庫(kù)連接一直是數(shù)據(jù)庫(kù)中比較耗時(shí)的操作，因此建議是務(wù)必使用數(shù)據(jù)庫(kù)連接池 機(jī)制。另外，數(shù)據(jù)庫(kù)連接還受到數(shù)據(jù)庫(kù)底層的限制，因此也需要合理有效地釋放無(wú)用的數(shù)據(jù)庫(kù)連接。在性能調(diào)優(yōu)中，我們經(jīng)常需要測(cè)試并且設(shè)置合理的連接池大小。這里推薦一個(gè)FlexyPool工具可以幫助你選擇生產(chǎn)環(huán)境下合適的連接池大小。

JDBC Batching允許在單次數(shù)據(jù)庫(kù)連接中發(fā)送多個(gè)SQL語(yǔ)句。這篇博客里進(jìn)行了對(duì)比可以看出Batch操作的性能提升非常巨大 ，無(wú)論是在客戶端還是數(shù)據(jù)庫(kù)端。 PreparedStatements 是不錯(cuò)的用于Batching操作的選擇，像Oracle也僅支持基于PreparedStatements的Batching操作。

JDBC中已經(jīng)基于PreparedStataement.addBatch 與 PreparedStataement.executeBatch)提供了Batching操作的輔助，不過(guò)如果打算手動(dòng)的構(gòu)造Batching操作，那么在設(shè)計(jì)階段就要考慮到是否需要引入Batching。如果你用的是Hibernate，那么可以用簡(jiǎn)單的配置就開啟Batching，Hibernate 5.2 提供了 Session級(jí)別的Batching, 也是非常方便的。

Statement Caching算是最不常用的幾種優(yōu)化手段之一了，你可以利用PreparedStatements同時(shí)在客戶端(Driver)或者數(shù)據(jù)庫(kù)端同時(shí)緩存語(yǔ)句。

如果你是使用Hibernate作為ORM工具，那么IDENTITY生成器可能會(huì)影響到你的性能，因?yàn)樗鼤?huì)禁止掉JDBC Batching。Table生成器也不是啥好選擇，它會(huì)使用獨(dú)立的事務(wù)上下文進(jìn)行捕獲操作，而導(dǎo)致底層的事務(wù)日志承受額外的壓力，并且導(dǎo)致了每次連接池中的新的請(qǐng)求都需要一個(gè)新的Identifier。因此筆者還是推薦SEQUENCE生成器，SQL Server在2012版本之后也開始支持了該生成器。

在數(shù)據(jù)庫(kù)設(shè)計(jì)的時(shí)候，我們應(yīng)該盡可能地選用合適的列類型，這樣可以讓你的數(shù)據(jù)庫(kù)以最合適的方式去索引存儲(chǔ)你的數(shù)據(jù)。譬如在PostgreSQL中你應(yīng)該使用inet來(lái)存放IPv4的地址，特別是Hibernate還允許你自定義數(shù)據(jù)類型，這樣方面和數(shù)據(jù)庫(kù)中的列類型一一對(duì)應(yīng)。

Hibernate提供了很多的關(guān)系映射，不過(guò)并不是所有的映射都是性能優(yōu)化的。

我們?cè)陂_發(fā)的過(guò)程中需要注意避免單向的關(guān)系映射，以及@ManyToMany這種映射。對(duì)于集合查詢而言，雙向的@OneToMany關(guān)系才是值得推薦的。

繼承是面向?qū)ο蟮恼Z(yǔ)言中的不可或缺的一部分，但這也是關(guān)系型數(shù)據(jù)庫(kù)與面向?qū)ο蟮恼Z(yǔ)言之間的不協(xié)調(diào)最甚的地方。JPA提供了譬如SINGLE_TABLE、JOIN以及TABLE_PER_CLASS來(lái)處理繼承映射的問題，而這幾個(gè)辦法都是各有千秋。

SINGLE_TABLE在SQL語(yǔ)句中的表現(xiàn)最好，不過(guò)不能使用NOT NULL約束，數(shù)據(jù)完整性的控制較差。

JOIN 通過(guò)更復(fù)雜的語(yǔ)句控制來(lái)保證了數(shù)據(jù)的完整性，只要你不使用多態(tài)查詢或者@OneToMany關(guān)系注解，那一切還好。

應(yīng)該避免使用TABLE_PER_CLASS，它基本上無(wú)法生成高效的SQL語(yǔ)句。

在使用JPA或者Hibernate時(shí)候，應(yīng)該隨時(shí)注意持久化上下文的大小，避免同時(shí)管理過(guò)多的實(shí)體類。通過(guò)限制受管實(shí)體類的數(shù)量，我們可以更好地進(jìn)行內(nèi)存管理，而默認(rèn)的臟檢測(cè)機(jī)制也會(huì)有更好的效果。

獲取過(guò)多的冗余數(shù)據(jù)可能是導(dǎo)致數(shù)據(jù)訪問層性能下降的原因之一，即使是包含了投影等操作，對(duì)于實(shí)體的查詢應(yīng)該也是排外的，即不會(huì)引入冗余數(shù)據(jù)的。我們應(yīng)該只獲取那些業(yè)務(wù)邏輯需要到的數(shù)據(jù)，這里推薦使用DTO Projections。過(guò)早的數(shù)據(jù)獲取以及Open Session In View這種反模式都是要被避免的。

關(guān)系型數(shù)據(jù)庫(kù)使用了很多的內(nèi)存緩沖結(jié)構(gòu)體來(lái)避免大量的磁盤訪問，但是我們往往忽略了數(shù)據(jù)庫(kù)緩存。我們可以通過(guò)調(diào)整數(shù)據(jù)庫(kù)查詢引擎，將更多的內(nèi)容留于內(nèi)存中以避免磁盤查詢最終明顯的減少響應(yīng)耗時(shí)。應(yīng)用層的緩存則利用高速副本的方式來(lái)保證低響應(yīng)時(shí)間。而Second-Level緩存能夠有效減少讀寫事務(wù)的響應(yīng)時(shí)間，特別是在主從復(fù)制架構(gòu)中。根據(jù)不同的應(yīng)用取錢，Hibernate提供了 READ_ONLY, NONSTRICT_READ_WRITE, READ_WRITE, 以及 TRANSACTIONAL這幾種方式。

在考慮性能和數(shù)據(jù)完整性的時(shí)候，事務(wù)隔離層 就變得至關(guān)重要。對(duì)于并發(fā)較高的應(yīng)用，需要避免更新失敗, 可以使用 樂觀鎖或者擴(kuò)展的持久化上下文.

而為了避免 樂觀鎖中的 false positives, 可以使用 無(wú)版本的樂觀控制或者基于寫屬性集的實(shí)體劃分.

雖然你是用了JPA或者Hibernate，但是你可以用一些原生查詢，建議是好好利用Window Functions, CTE (Common Table Expressions), CONNECT BY, PIVOT等等。這些工具能夠避免你一次性傳輸過(guò)多的數(shù)據(jù)進(jìn)入應(yīng)用層，如果你可以把這個(gè)操作托付給數(shù)據(jù)庫(kù)層進(jìn)行，那么可以僅關(guān)心最終的結(jié)果，從而節(jié)約了磁盤IO與網(wǎng)絡(luò)帶寬。

關(guān)系型數(shù)據(jù)庫(kù)能夠方便地進(jìn)行擴(kuò)展，像Facebook、Twitter、Pinterest這些大公司都擴(kuò)展了數(shù)據(jù)庫(kù)系統(tǒng)：

數(shù)據(jù)副本與分片是兩種常用的增加吞吐量的擴(kuò)展方式，你應(yīng)該合理的組合應(yīng)用這些方式從而提高你的商業(yè)應(yīng)用的能力。