資料庫效能需求分析及評估模型

       資料庫作為應用系統當中最重要的一塊，也是效能測試非常關注的一塊，根據我自己的專案經驗，和以往對應用系統的效能需求分析和測試策略制定過程，總結一下如何開展資料庫系統的效能需求分析，以及制定資料庫能力評估模型。

一、資料庫效能需求制定

1、需求資訊收集-任務/交易分佈

（1）收集有哪些主要交易任務（與業務系統需求一致）

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

2、需求資訊收集-交易混合圖

      需要關注的資訊有：

Ø   高峰期有哪些操作？

Ø   中介軟體操作有多少？資料庫操作有多少？

Ø   如果任務失敗，那麼商業風險有多少？

Ø   有沒有涉及保密係數高的資料？

      測試選型標準：高吞吐量、高I/O、高商業風險

二、資料庫能力需求

1、高吞吐量

      滿足高併發下的大資料量互動需求，滿足資料備份或ETL過程的大資料量遷移。具體需求資訊獲取參照以上資料庫應用需求。

2、負載均衡

      滿足高併發下資料庫的負載均衡能力，需求分析需要收集資料庫的部署架構、負載均衡策略等資料資訊。

3、讀寫分離

      獲取需求的要點是明確哪些是寫節點，哪些是讀節點，並且切換的策略什麼，資料同步的策略是什麼。

4、分割槽分片（分庫分表）

      獲取需求的要點是把握資料的垂直切換和水平分庫概念。明確需要對哪些資料塊進行切分，分別分散到哪幾臺資料庫主機上；需要對哪些大表進行資料水平切分，並且分佈到哪些DB或table中。通過需求分析，做出資料切分的合理性判斷，以及做出系統可測性的判斷。

5、高併發

      根據以上的資料庫應用需求，進一步制定資料庫的高併發需求，估算出單臺資料庫的API介面壓力和需要滿足的併發能力。

6、高可用性

      高可用性可能也綜合涉及到資料的多項能力，主要應用的是叢集技術，HA容錯及互備技術，體現的是無故障執行。獲取需求的要點是明確高可用性技術架構，瞭解HA採用的工作方式，以及掌握故障切換方法和資料一致性驗證需求。

三、資料庫評估模型

（一）關鍵業務時間指標

       在我們的印象中，應用的關鍵業務能夠提供真正的使用者行為洞察——他們捕捉實時效能資料，展現真實使用者在互動時的使用者體驗。衡量一個關鍵業務的效能包括捕捉交易的整體響應時間以及測量其不同層面的響應時間。這些時間都可以滿足你業務需要的基準做比較。

      如果你只想測量應用的某個方面，關鍵業務流程是最佳選擇。雖然容器指標可以提供豐富的資訊，可以幫助你確定何時自動縮放您的環境，但業務流程交易還是決定著你的應用效能最終效果。不管你作為什麼規模公司的程式“猿”，都應該首先關心你的使用者是否可以完成他們的關鍵業務流程。

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

      那麼問題來了，怎麼設定關鍵業務的標準呢？

      這裡提供一個簡單的方法供大家參考：假設關鍵業務在週三13：00~14:00是一個常見的高峰，那麼選擇這個時段平均響應時間作為標準，等到下週三的同一個時段，再將這周的這個時段的所有關鍵業務平均響應時間與前一週相比得到一個平均值，如此迴圈。通過這個機制，應用可以隨時間而發展，而原始的關鍵業務資料也變得更有意義。關鍵業務的監測是使用者體驗中最具反思性的測量方法，因此它們是能捕捉到的最重要的指標之一。

（二）SQL效能指標

      查詢的效能主要體現為SQL查詢緩慢和資料返回時間過長。那麼我們要怎麼解決它呢？下面是測試需要重定關注的：

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

      2、重點關注索引的應用，對於只是訪問表中的幾個欄位，並且欄位內容較少，可以為這幾個欄位單獨建立一個組合索引，這樣就可以直接只通過訪問索引得到資料，一般索引佔用的磁碟空間比表小很多，所以這種方式可以大大減少磁碟IO開銷。

      3、關注慢SQL執行計劃及優化：SQL執行計劃是關係型資料庫最核心的技術之一，它表示SQL執行時的資料訪問演算法。當業務需求越來越複雜，表資料量越來越大，SQL也需要支援非常複雜的業務邏輯，但SQL的效能還需要提高，因此，優秀的關係型資料庫除了需要支援複雜的SQL語法及更多函式外，還需要有一套優秀的演算法庫來提高SQL效能。

      4、關注批處理對效能影響：讀取大量的資料或生產複雜的分析報告時通常都是在批量操作。這些操作是資源密集型，可能會影響線上使用者的效能。想要解決這個問題需要將這些操作在低負載下進行，如在夜間；或使用單獨的資料庫來處理和分析報告。

（三）鎖及粒度

      資料庫一般都允許多使用者的存在，多個使用者同時活動必然會導致衝突，然而正常工作中這種情況又無法避免，所以測試需要關注的是鎖的應用與效能的平衡關係：

      1、頁/行鎖定：當一個使用者試圖讀取另一個使用者正在修改的資料，或修改另一個使用者正在讀取的資料時，又或者嘗試修改另一個事務正在嘗試修改的資料時，就會出現併發問題。這時候資源就會被鎖定。

      可以鎖定的資源在粒度（granularity）上差異很大。從細（行）到粗（資料庫）。細粒度鎖允許更大的資料庫併發，因為使用者能對某些未鎖定的行執行查詢。然而，每個由資料庫系統產生的鎖都需要記憶體，所以數以千計獨立的行級別的鎖也會影響資料庫的效能。粗粒度的鎖降低了併發性，同時消耗的資源也較少。

      2、死鎖：死鎖是資料庫效能的重量級殺手之一，然而死鎖卻是不同事務之間搶佔資料資源造成的。死鎖耗時耗資源，然而在大型資料庫中，高併發帶來的死鎖是不可避免的，所以我們只能讓其變的更少。

①按照同一順序訪問資料庫資源

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

③儘量不要在事務中要求使用者響應，比如修改新增資料之後再完成整個事務的提交，這樣延長事務佔用資源的時間，也會提升死鎖概率。

④儘量減少資料庫的併發量（通過優化架構實現）。

⑤儘可能使用分割槽表，分割槽檢視，把資料放置在不同的磁碟和檔案組中，分散訪問儲存在不同分割槽的資料，減少因為表中放置鎖而造成的其它事務長時間等待。

⑥避免佔用時間很長並且關係表複雜的資料操作。

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

（四）硬體資源指標

      然而並不是所有的資料庫效能問題都是來自資料庫本身，我們日常工作中最常見的另一個情景就是資料庫的硬體有若干問題，這裡我們簡單的介紹一下可能會出現的情況，畢竟市面上有已經有很多工具可以監測這些問題了。

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

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

3、配置不正確的磁碟：資料庫需要效果明顯的磁碟訪問，配置不正確的磁碟會造成相當大的效能影響。

4、沒有足夠的記憶體：受限或不好的實體記憶體影響資料庫效能，可用的記憶體越多，效能越好。

（五）NoSQL

      NoSQL發展到今天，已經有了很大的吸引力，因為它處理大規模資料和高併發的能力非常顯著。但是，NoSQL卻很難測試，也不容易監控。

1、NoSQL特性：關係型SQL已經成熟，有行業標準介面，但是每一個NoSQL都是獨一無二的存在，並且都不支援複雜的資料庫模型。所以簡潔、有效、速度是它的業務應用標準。

2、叢集化和負載均衡：NoSQL資料庫相比關係型資料庫通常更多的是資源密集型。它們需要更多的記憶體和記憶體分配，叢集化和分散式是評估要點；

3、擴充套件性要求：隨著資料庫的需求增加，硬體也必須擴充套件，可擴充套件性是一項評估要點。

4、高可用性要求：可以說NoSQL對穩定性的要求更為苛刻（因為它們有些是基於記憶體的資料庫），高可用性是重要評估點。

5、監控要求：相對於已經成熟的關係SQL，NoSQL現在的監控可以說是比較困難的，國內也只有聽雲一家公司能夠支援主流的Memcached, MongoDB, Redis等非關係型資料庫服務（但是NoSQL監控部分要收費）；ApplicationsManager也支援對Memcached, MongoDB,Redis、HBase、Oracle NoSQL的監控（這些的監控指標還不夠豐富，有待完善）。

（六）擴充套件架構模型

1、資料切分和分散式

資料切分可以是物理上的，對資料通過一系列的切分規則將資料分佈到不同的DB伺服器上，通過路由規則路由訪問特定的資料庫，這樣一來每次訪問面對的就不是單臺伺服器了，而是N臺伺服器，這樣就可以降低單臺機器的負載壓力。資料切分也可以是資料庫內的，對資料通過一系列的切分規則，將資料分佈到一個資料庫的不同表中。

（1）資料垂直切分

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

（2）資料水平切分

      資料的垂直切分基本上可以簡單的理解為按照表、按照模組來切分資料，而水平切分就不再是按照表或者是功能模組來切分了。一般來說，簡單的水平切分主要是將某個訪問極其平凡的表再按照某個欄位的某種規則來分散到多個表之中，每個表中包含一部分資料。

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

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

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

其中Master負責寫操作的負載，也就是說一切寫的操作都在Master上進行，而讀的操作則分攤到Slave上進行。這樣一來的可以大大提高讀取的效率。在一般的網際網路應用中，經過一些資料調查得出結論，讀/寫的比例大概在 10：1左右 ，也就是說大量的資料操作是集中在讀的操作，這也就是為什麼我們會有多個Slave的原因。

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

（4）分散式儲存

分散式儲存是將資料分散儲存在多臺獨立的裝置上。傳統的網路儲存系統採用集中的儲存伺服器存放所有資料，儲存伺服器成為系統效能的瓶頸，也是可靠性和安全性的焦點，不能滿足大規模儲存應用的需要。分散式網路儲存系統採用可擴充套件的系統結構，利用多臺儲存伺服器分擔儲存負荷，利用位置伺服器定位儲存資訊，它不但提高了系統的可靠性、可用性和存取效率，還易於擴充套件。

分散式儲存利用的就是資料的切分，也叫資料分片，資料分片將達到以下三個目的：

Ø 分佈均勻，即每臺裝置上的資料量要儘可能相近；

Ø 負載均衡，即每臺裝置上的請求量要儘可能相近；

Ø 擴縮容時產生的資料遷移儘可能少。

      有了分散式儲存，就會有分散式計算，這就是大資料的範疇了，在這裡不多說。

2、Cache與Search的利用

（1）結合傳統關係型資料庫和NoSQL兩種型別資料庫的優缺點，對於Oracle、Mysql這些資料庫，可以通過引入Cache（Redis、Memcached），減少資料庫的訪問，增加效能（主要是解決傳統關係型資料庫的IO效能瓶頸，Cache都是基於記憶體的，大大減少了磁碟讀寫）。特別說明一下，這裡說的Cache不是指資料庫底層對應的Cache快取，資料庫層次的快取一般針對的是查詢內容，而且粒度也太小，一般只有表中資料沒有變更的時候才發揮作用。我們這裡說的Cache，是指外部引入的資料庫快取。

（2）通過引入Search（Lucene、Solr、ElasticSearch），利用搜尋引擎高效的全文索引和分詞演算法，以及高效的資料檢索實現，來解決資料庫和傳統的Cache軟體完全無法解決的全文模糊搜尋、分類統計查詢等功能。

      通過以上的資料庫效能評估模型分析，我們就能把握資料庫系統將要有的效能能力，並分析具體的測試範圍和指標評估範圍，以決定後期需要採用的測試方法、策略和工具。畢竟效能不是靠測試和調優出來的，是靠設計出來的，如果我們不瞭解資料庫的能力模型和相應的架構要求，我們將很難深入開展相應的效能測試和效能調優工作。