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

Github系列文章地址

原文地址

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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