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

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

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

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

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

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

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

需要關注的信息有：

Ø   高峰期有哪些操作？

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

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

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

測試選型標準：高吞吐量、高I/O、高商業(yè)風險；

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

1、高吞吐量

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

2、負載均衡

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

3、讀寫分離

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

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

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

5、高并發(fā)

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

6、高可用性

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

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

（一）關鍵業(yè)務時間指標

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

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

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

那么問題來了，怎么設定關鍵業(yè)務的標準呢？

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

（二）SQL性能指標

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

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

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

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

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

（三）鎖及粒度

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

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

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

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

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

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

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

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

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

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

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

（四）硬件資源指標

然而并不是所有的數(shù)據(jù)庫性能問題都是來自數(shù)據(jù)庫本身，我們日常工作中最常見的另一個情景就是數(shù)據(jù)庫的硬件有若干問題，這里我們簡單的介紹一下可能會出現(xiàn)的情況，畢竟市面上有已經(jīng)有很多工具可以監(jiān)測這些問題了。

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

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

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

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

（六）擴展架構模型

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

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

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

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

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

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

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

（3）負載均衡和讀寫分離

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

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

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

（4）分布式存儲

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

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

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

Ø 負載均衡，即每臺設備上的請求量要盡可能相近；

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

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

2、Cache與Search的利用

（1）結合傳統(tǒng)關系型數(shù)據(jù)庫和NoSQL兩種類型數(shù)據(jù)庫的優(yōu)缺點，對于Oracle、Mysql這些數(shù)據(jù)庫，可以通過引入Cache（Redis、Memcached），減少數(shù)據(jù)庫的訪問，增加性能（主要是解決傳統(tǒng)關系型數(shù)據(jù)庫的IO性能瓶頸，Cache都是基于內存的，大大減少了磁盤讀寫）。特別說明一下，這里說的Cache不是指數(shù)據(jù)庫底層對應的Cache緩存，數(shù)據(jù)庫層次的緩存一般針對的是查詢內容，而且粒度也太小，一般只有表中數(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)將要有的性能能力，并分析具體的測試范圍和指標評估范圍，以決定后期需要采用的測試方法、策略和測試工具。畢竟性能不是靠測試和調優(yōu)出來的，是靠設計出來的，如果我們不了解數(shù)據(jù)庫的能力模型和相應的架構要求，我們將很難深入開展相應的性能測試和性能調優(yōu)工作。

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

有哪些SQL性能測試工具？SQL性能測試工具的主要特點

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

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

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

怎么進行Tuxedo性能測試？Tuxedo性能測試基本流程