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

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

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

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

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

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

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

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

Ø   高峰期有哪些操作？

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

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

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

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

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

1、高吞吐量

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

2、負(fù)載均衡

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

3、讀寫(xiě)分離

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

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

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

5、高并發(fā)

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

6、高可用性

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

三、數(shù)據(jù)庫(kù)評(píng)估模型

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

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

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

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

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

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

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

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

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

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

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

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

（三）鎖及粒度

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

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

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

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

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

②保持事務(wù)的簡(jiǎn)短，盡量不要讓一個(gè)事務(wù)處理過(guò)于復(fù)雜的讀寫(xiě)操作。事務(wù)過(guò)于復(fù)雜，占用資源會(huì)增多，處理時(shí)間增長(zhǎng)，容易與其它事務(wù)沖突，提升死鎖概率。

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

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

⑤盡可能使用分區(qū)表，分區(qū)視圖，把數(shù)據(jù)放置在不同的磁盤(pán)和文件組中，分散訪問(wèn)保存在不同分區(qū)的數(shù)據(jù)，減少因?yàn)楸碇蟹胖面i而造成的其它事務(wù)長(zhǎng)時(shí)間等待。

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

⑦使用較低的隔離級(jí)別，使用較低的隔離級(jí)別比使用較高的隔離級(jí)別持有共享鎖的時(shí)間更短。這樣就減少了鎖爭(zhēng)用。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（4）分布式存儲(chǔ)

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

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

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

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

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

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

2、Cache與Search的利用

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

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

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

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

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

測(cè)試MySQL性能的工具有哪些？MySQL性能測(cè)試工具對(duì)比

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

某智能停車(chē)管理系統(tǒng)性能測(cè)試項(xiàng)目案例分享

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