如何開展數(shù)據(jù)庫系統(tǒng)的性能需求分析?如何制定數(shù)據(jù)庫能力評估模型？

數(shù)據(jù)庫作為應(yīng)用系統(tǒng)當(dāng)中最重要的一塊，也是性能測試非常關(guān)注的一塊，今天小編來總結(jié)一下如何開展數(shù)據(jù)庫系統(tǒng)的性能需求分析，以及制定數(shù)據(jù)庫能力評估模型。

一、數(shù)據(jù)庫性能需求制定

1、需求信息收集-任務(wù)/交易分布

（1）收集有哪些主要交易任務(wù)（與業(yè)務(wù)系統(tǒng)需求一致）；

（2）在一天的某些特定時刻系統(tǒng)都有哪些主要操作，以及操作量；

2、需求信息收集-交易混合圖

需要關(guān)注的信息有：

Ø   高峰期有哪些操作？

Ø   中間件操作有多少？數(shù)據(jù)庫操作有多少？

Ø   如果任務(wù)失敗，那么商業(yè)風(fēng)險有多少？

Ø   有沒有涉及保密系數(shù)高的數(shù)據(jù)？

測試選型標(biāo)準(zhǔn)：高吞吐量、高I/O、高商業(yè)風(fēng)險；

二、數(shù)據(jù)庫能力需求

1、高吞吐量

滿足高并發(fā)下的大數(shù)據(jù)量交互需求，滿足數(shù)據(jù)備份或ETL過程的大數(shù)據(jù)量遷移。具體需求信息獲取參照以上數(shù)據(jù)庫應(yīng)用需求。

2、負(fù)載均衡

滿足高并發(fā)下數(shù)據(jù)庫的負(fù)載均衡能力，需求分析需要收集數(shù)據(jù)庫的部署架構(gòu)、負(fù)載均衡策略等數(shù)據(jù)信息。

3、讀寫分離

獲取需求的要點(diǎn)是明確哪些是寫節(jié)點(diǎn)，哪些是讀節(jié)點(diǎn)，并且切換的策略什么，數(shù)據(jù)同步的策略是什么。

4、分區(qū)分片（分庫分表）

獲取需求的要點(diǎn)是把握數(shù)據(jù)的垂直切換和水平分庫概念。明確需要對哪些數(shù)據(jù)塊進(jìn)行切分，分別分散到哪幾臺數(shù)據(jù)庫主機(jī)上；需要對哪些大表進(jìn)行數(shù)據(jù)水平切分，并且分布到哪些DB或table中。通過需求分析，做出數(shù)據(jù)切分的合理性判斷，以及做出系統(tǒng)可測性的判斷。

5、高并發(fā)

根據(jù)以上的數(shù)據(jù)庫應(yīng)用需求，進(jìn)一步制定數(shù)據(jù)庫的高并發(fā)需求，估算出單臺數(shù)據(jù)庫的API接口壓力和需要滿足的并發(fā)能力。

6、高可用性

高可用性可能也綜合涉及到數(shù)據(jù)的多項能力，主要應(yīng)用的是集群技術(shù)，HA容錯及互備技術(shù)，體現(xiàn)的是無故障運(yùn)行。獲取需求的要點(diǎn)是明確高可用性技術(shù)架構(gòu)，了解HA采用的工作方式，以及掌握故障切換方法和數(shù)據(jù)一致性驗證需求。

三、數(shù)據(jù)庫評估模型

（一）關(guān)鍵業(yè)務(wù)時間指標(biāo)

在我們的印象中，應(yīng)用的關(guān)鍵業(yè)務(wù)能夠提供真正的用戶行為洞察——他們捕捉實時性能數(shù)據(jù)，展現(xiàn)真實用戶在交互時的用戶體驗。衡量一個關(guān)鍵業(yè)務(wù)的性能包括捕捉交易的整體響應(yīng)時間以及測量其不同層面的響應(yīng)時間。這些時間都可以滿足你業(yè)務(wù)需要的基準(zhǔn)做比較。

如果你只想測量應(yīng)用的某個方面，關(guān)鍵業(yè)務(wù)流程是最佳選擇。雖然容器指標(biāo)可以提供豐富的信息，可以幫助你確定何時自動縮放您的環(huán)境，但業(yè)務(wù)流程交易還是決定著你的應(yīng)用性能最終效果。不管你作為什么規(guī)模公司的程序“猿”，都應(yīng)該首先關(guān)心你的用戶是否可以完成他們的關(guān)鍵業(yè)務(wù)流程。

一旦你定義了整個關(guān)鍵業(yè)務(wù)，性能好壞就是衡量整個應(yīng)用生態(tài)系統(tǒng)的最好標(biāo)準(zhǔn)。我們需要設(shè)定低于平均關(guān)鍵業(yè)務(wù)響應(yīng)時間的交易為異常行為，這樣就能更好的觀察應(yīng)用的性能了，如下圖所示。

那么問題來了，怎么設(shè)定關(guān)鍵業(yè)務(wù)的標(biāo)準(zhǔn)呢？

這里提供一個簡單的方法供大家參考：假設(shè)關(guān)鍵業(yè)務(wù)在周三13：00~14:00是一個常見的高峰，那么選擇這個時段平均響應(yīng)時間作為標(biāo)準(zhǔn)，等到下周三的同一個時段，再將這周的這個時段的所有關(guān)鍵業(yè)務(wù)平均響應(yīng)時間與前一周相比得到一個平均值，如此循環(huán)。通過這個機(jī)制，應(yīng)用可以隨時間而發(fā)展，而原始的關(guān)鍵業(yè)務(wù)數(shù)據(jù)也變得更有意義。關(guān)鍵業(yè)務(wù)的監(jiān)測是用戶體驗中最具反思性的測量方法，因此它們是能捕捉到的最重要的指標(biāo)之一。

（二）SQL性能指標(biāo)

查詢的性能主要體現(xiàn)為SQL查詢緩慢和數(shù)據(jù)返回時間過長。那么我們要怎么解決它呢？下面是測試需要重定關(guān)注的：

1、數(shù)據(jù)的查詢方式對傳輸效率的影響，比如選用了更多的數(shù)據(jù)：查詢返回的列太多的話會導(dǎo)致在選擇行和檢索數(shù)據(jù)時造成緩慢（如使用了SELECT*，沒有列出所需的列）。此外，在結(jié)果中列出所需的列，也能減少數(shù)據(jù)傳輸，有利于性能的提升。

2、重點(diǎn)關(guān)注索引的應(yīng)用，對于只是訪問表中的幾個字段，并且字段內(nèi)容較少，可以為這幾個字段單獨(dú)建立一個組合索引，這樣就可以直接只通過訪問索引得到數(shù)據(jù)，一般索引占用的磁盤空間比表小很多，所以這種方式可以大大減少磁盤IO開銷。

3、關(guān)注慢SQL執(zhí)行計劃及優(yōu)化：SQL執(zhí)行計劃是關(guān)系型數(shù)據(jù)庫最核心的技術(shù)之一，它表示SQL執(zhí)行時的數(shù)據(jù)訪問算法。當(dāng)業(yè)務(wù)需求越來越復(fù)雜，表數(shù)據(jù)量越來越大，SQL也需要支持非常復(fù)雜的業(yè)務(wù)邏輯，但SQL的性能還需要提高，因此，優(yōu)秀的關(guān)系型數(shù)據(jù)庫除了需要支持復(fù)雜的SQL語法及更多函數(shù)外，還需要有一套優(yōu)秀的算法庫來提高SQL性能。

4、關(guān)注批處理對性能影響：讀取大量的數(shù)據(jù)或生產(chǎn)復(fù)雜的分析報告時通常都是在批量操作。這些操作是資源密集型，可能會影響在線用戶的性能。想要解決這個問題需要將這些操作在低負(fù)載下進(jìn)行，如在夜間；或使用單獨(dú)的數(shù)據(jù)庫來處理和分析報告。

（三）鎖及粒度

數(shù)據(jù)庫一般都允許多用戶的存在，多個用戶同時活動必然會導(dǎo)致沖突，然而正常工作中這種情況又無法避免，所以測試需要關(guān)注的是鎖的應(yīng)用與性能的平衡關(guān)系：

1、頁/行鎖定：當(dāng)一個用戶試圖讀取另一個用戶正在修改的數(shù)據(jù)，或修改另一個用戶正在讀取的數(shù)據(jù)時，又或者嘗試修改另一個事務(wù)正在嘗試修改的數(shù)據(jù)時，就會出現(xiàn)并發(fā)問題。這時候資源就會被鎖定。

可以鎖定的資源在粒度（granularity）上差異很大。從細(xì)（行）到粗（數(shù)據(jù)庫）。細(xì)粒度鎖允許更大的數(shù)據(jù)庫并發(fā)，因為用戶能對某些未鎖定的行執(zhí)行查詢。然而，每個由數(shù)據(jù)庫系統(tǒng)產(chǎn)生的鎖都需要內(nèi)存，所以數(shù)以千計獨(dú)立的行級別的鎖也會影響數(shù)據(jù)庫的性能。粗粒度的鎖降低了并發(fā)性，同時消耗的資源也較少。

2、死鎖：死鎖是數(shù)據(jù)庫性能的重量級殺手之一，然而死鎖卻是不同事務(wù)之間搶占數(shù)據(jù)資源造成的。死鎖耗時耗資源，然而在大型數(shù)據(jù)庫中，高并發(fā)帶來的死鎖是不可避免的，所以我們只能讓其變的更少。

①按照同一順序訪問數(shù)據(jù)庫資源

②保持事務(wù)的簡短，盡量不要讓一個事務(wù)處理過于復(fù)雜的讀寫操作。事務(wù)過于復(fù)雜，占用資源會增多，處理時間增長，容易與其它事務(wù)沖突，提升死鎖概率。

③盡量不要在事務(wù)中要求用戶響應(yīng)，比如修改新增數(shù)據(jù)之后再完成整個事務(wù)的提交，這樣延長事務(wù)占用資源的時間，也會提升死鎖概率。

④盡量減少數(shù)據(jù)庫的并發(fā)量（通過優(yōu)化架構(gòu)實現(xiàn)）。

⑤盡可能使用分區(qū)表，分區(qū)視圖，把數(shù)據(jù)放置在不同的磁盤和文件組中，分散訪問保存在不同分區(qū)的數(shù)據(jù)，減少因為表中放置鎖而造成的其它事務(wù)長時間等待。

⑥避免占用時間很長并且關(guān)系表復(fù)雜的數(shù)據(jù)操作。

⑦使用較低的隔離級別，使用較低的隔離級別比使用較高的隔離級別持有共享鎖的時間更短。這樣就減少了鎖爭用。

（四）硬件資源指標(biāo)

然而并不是所有的數(shù)據(jù)庫性能問題都是來自數(shù)據(jù)庫本身，我們?nèi)粘９ぷ髦凶畛Ｒ姷牧硪粋€情景就是數(shù)據(jù)庫的硬件有若干問題，這里我們簡單的介紹一下可能會出現(xiàn)的情況，畢竟市面上有已經(jīng)有很多工具可以監(jiān)測這些問題了。

1、沒有足夠的CPU或CPU速度太慢：更多的CPU可以分擔(dān)服務(wù)器的負(fù)載，從而提高性能。

2、慢的磁盤沒有足夠的IOPS：磁盤性能可以描述為每秒輸入/輸出操作（IOPS），它表示每秒磁盤的吞吐量。

3、配置不正確的磁盤：數(shù)據(jù)庫需要效果明顯的磁盤訪問，配置不正確的磁盤會造成相當(dāng)大的性能影響。

4、沒有足夠的內(nèi)存：受限或不好的物理內(nèi)存影響數(shù)據(jù)庫性能，可用的內(nèi)存越多，性能越好。

（六）擴(kuò)展架構(gòu)模型

1、數(shù)據(jù)切分和分布式

數(shù)據(jù)切分可以是物理上的，對數(shù)據(jù)通過一系列的切分規(guī)則將數(shù)據(jù)分布到不同的DB服務(wù)器上，通過路由規(guī)則路由訪問特定的數(shù)據(jù)庫，這樣一來每次訪問面對的就不是單臺服務(wù)器了，而是N臺服務(wù)器，這樣就可以降低單臺機(jī)器的負(fù)載壓力。數(shù)據(jù)切分也可以是數(shù)據(jù)庫內(nèi)的，對數(shù)據(jù)通過一系列的切分規(guī)則，將數(shù)據(jù)分布到一個數(shù)據(jù)庫的不同表中。

（1）數(shù)據(jù)垂直切分

數(shù)據(jù)的垂直切分，也可以稱之為縱向切分。將數(shù)據(jù)庫想象成為由很多個一大塊一大塊的“數(shù)據(jù)塊”（表）組成，我們垂直的將這些“數(shù)據(jù)塊”切開，然后將他們分散到多臺數(shù)據(jù)庫主機(jī)上面。這樣的切分方法就是一個垂直（縱向）的數(shù)據(jù)切分。

（2）數(shù)據(jù)水平切分

數(shù)據(jù)的垂直切分基本上可以簡單的理解為按照表、按照模塊來切分?jǐn)?shù)據(jù)，而水平切分就不再是按照表或者是功能模塊來切分了。一般來說，簡單的水平切分主要是將某個訪問極其平凡的表再按照某個字段的某種規(guī)則來分散到多個表之中，每個表中包含一部分?jǐn)?shù)據(jù)。

除了垂直切分、水平切分，還有其他的切分或分片方式，如導(dǎo)出切分、混合切分。

（3）負(fù)載均衡和讀寫分離

一般是通過負(fù)載均衡器，其職責(zé)就是定位到一臺具體的DB服務(wù)器。具體的規(guī)則如下：負(fù)載均衡器會分析當(dāng)前sql的讀寫特性，如果是寫操作或者是要求實時性很強(qiáng)的操作的話，直接將查詢負(fù)載分到Master，如果是讀操作則通過負(fù)載均衡策略分配一個Slave。

其中Master負(fù)責(zé)寫操作的負(fù)載，也就是說一切寫的操作都在Master上進(jìn)行，而讀的操作則分?jǐn)偟絊lave上進(jìn)行。這樣一來的可以大大提高讀取的效率。在一般的互聯(lián)網(wǎng)應(yīng)用中，經(jīng)過一些數(shù)據(jù)調(diào)查得出結(jié)論，讀/寫的比例大概在 10：1左右 ，也就是說大量的數(shù)據(jù)操作是集中在讀的操作，這也就是為什么我們會有多個Slave的原因。

但是為什么要分離讀和寫呢？熟悉DB的技術(shù)人員都知道，寫操作涉及到鎖的問題，不管是行鎖還是表鎖還是塊鎖，都是會降低系統(tǒng)執(zhí)行的效率。我們這樣的分離是把寫操作集中在一個節(jié)點(diǎn)上，而讀操作在其他的N個節(jié)點(diǎn)上進(jìn)行，從另一個方面有效的提高了讀的效率，保證了系統(tǒng)的高可用性。

（4）分布式存儲

分布式存儲是將數(shù)據(jù)分散存儲在多臺獨(dú)立的設(shè)備上。傳統(tǒng)的網(wǎng)絡(luò)存儲系統(tǒng)采用集中的存儲服務(wù)器存放所有數(shù)據(jù)，存儲服務(wù)器成為系統(tǒng)性能的瓶頸，也是可靠性和安全性的焦點(diǎn)，不能滿足大規(guī)模存儲應(yīng)用的需要。分布式網(wǎng)絡(luò)存儲系統(tǒng)采用可擴(kuò)展的系統(tǒng)結(jié)構(gòu)，利用多臺存儲服務(wù)器分擔(dān)存儲負(fù)荷，利用位置服務(wù)器定位存儲信息，它不但提高了系統(tǒng)的可靠性、可用性和存取效率，還易于擴(kuò)展。

分布式存儲利用的就是數(shù)據(jù)的切分，也叫數(shù)據(jù)分片，數(shù)據(jù)分片將達(dá)到以下三個目的：

Ø 分布均勻，即每臺設(shè)備上的數(shù)據(jù)量要盡可能相近；

Ø 負(fù)載均衡，即每臺設(shè)備上的請求量要盡可能相近；

Ø 擴(kuò)縮容時產(chǎn)生的數(shù)據(jù)遷移盡可能少。

有了分布式存儲，就會有分布式計算，這就是大數(shù)據(jù)的范疇了，在這里不多說。

2、Cache與Search的利用

（1）結(jié)合傳統(tǒng)關(guān)系型數(shù)據(jù)庫和NoSQL兩種類型數(shù)據(jù)庫的優(yōu)缺點(diǎn)，對于Oracle、Mysql這些數(shù)據(jù)庫，可以通過引入Cache（Redis、Memcached），減少數(shù)據(jù)庫的訪問，增加性能（主要是解決傳統(tǒng)關(guān)系型數(shù)據(jù)庫的IO性能瓶頸，Cache都是基于內(nèi)存的，大大減少了磁盤讀寫）。特別說明一下，這里說的Cache不是指數(shù)據(jù)庫底層對應(yīng)的Cache緩存，數(shù)據(jù)庫層次的緩存一般針對的是查詢內(nèi)容，而且粒度也太小，一般只有表中數(shù)據(jù)沒有變更的時候才發(fā)揮作用。我們這里說的Cache，是指外部引入的數(shù)據(jù)庫緩存。

（2）通過引入Search（Lucene、Solr、ElasticSearch），利用搜索引擎高效的全文索引和分詞算法，以及高效的數(shù)據(jù)檢索實現(xiàn)，來解決數(shù)據(jù)庫和傳統(tǒng)的Cache軟件完全無法解決的全文模糊搜索、分類統(tǒng)計查詢等功能。

通過以上的數(shù)據(jù)庫性能評估模型分析，我們就能把握數(shù)據(jù)庫系統(tǒng)將要有的性能能力，并分析具體的測試范圍和指標(biāo)評估范圍，以決定后期需要采用的測試方法、策略和測試工具。畢竟性能不是靠測試和調(diào)優(yōu)出來的，是靠設(shè)計出來的，如果我們不了解數(shù)據(jù)庫的能力模型和相應(yīng)的架構(gòu)要求，我們將很難深入開展相應(yīng)的性能測試和性能調(diào)優(yōu)工作。

更多數(shù)據(jù)庫性能測試推薦閱讀：

有哪些SQL性能測試工具？SQL性能測試工具的主要特點(diǎn)

測試MySQL性能的工具有哪些？MySQL性能測試工具對比

怎樣進(jìn)行數(shù)據(jù)庫性能測試？數(shù)據(jù)庫壓力測試的幾個步驟

某智能停車管理系統(tǒng)性能測試項目案例分享

怎么進(jìn)行Tuxedo性能測試？Tuxedo性能測試基本流程