0 2  為什麼要做 Benchmark 測試

1. 資料庫版本升級前評估相容性和效能

資料庫的版本升級在運維人員日常工作中時有發生。想象下這麼一個場景，業務需要使用 Json，而當前使用的 MySQL 是5.6版本，MySQL 只有升級到5.7版本才支援 Json。在此情景下，我們需要評估資料庫版本升級前後的相容性和效能。在業務介入前，建議運維同學可以先使用 Benchmark 測試進行壓測和評估。

2. 資料庫選型替換前評估相容性和效能

隨著國產資料庫的快速發展，在替換原有的商業資料庫或者其他開源資料庫的時候，我們經常會遇到選型的問題，比如從單機的資料庫替換成分散式資料庫，我們就需要測試其相容性和效能，測試其水平擴充套件能力。

3. 新系統上線前，評估資料庫容量、負載

新系統上線前，我們如何確保大併發負載下業務不停服，資料庫可以平穩應對突發大流量？解決該問題需要我們模擬業務訪問量，評估單臺機器、多臺機器的壓力，評估其後續擴充套件性。

4. 採購新裝置，評估新裝置效能

在降本增效的環境下，之前企業中使用的高階儲存、商業資料庫和小型機可能逐步會被普通的 X86、開源資料庫，特別是國產資料庫所取代。如何確認新的硬體裝置效能是否滿足業務，可以壓測資料庫來觀察新裝置的 cpu，memory, io, network 的工作負載。

工欲善其事必先利其器，對資料庫的壓測，業界有哪些好用的工具呢？每種資料庫壓測工具是否有各自使用的場景呢？

1. Sysbench

Sysbench 是一個基於 LuaJIT 可編寫指令碼的多執行緒基準測試工具，可以執行 CPU/記憶體/執行緒/IO/資料庫等方面的效能測試，常用於評估測試各種不同系統引數下的資料庫負載情況。

該工具只能針對單個表進行測試，或者對多個獨立的表進行測試，多表之間沒有關聯，不能模擬接近生產系統的業務模型。Sysbench 優點是可以用來測試資料型別相容性，也可以透過自定義 lua 指令碼以實現不同業務型別的測試。

2. TPC-C

TPC-C Benchmark 是一個對 OLTP（聯機交易處理）系統進行測試的規範，透過使用一個商品銷售模型對 OLTP 系統進行測試，包含五類事務：

● NewOrder –新訂單的生成；

● Payment –訂單付款；

● OrderStatus –最近訂單查詢；

● Delivery –配送；

● StockLevel –庫存缺貨狀態分析。

TPC-C 使用 tpmC 值（Transactions per Minute）來衡量系統最大有效吞吐量（MQTh，Max Qualified Throughput），其中 Transactions 以 NewOrder Transaction 為準，即最終衡量單位為每分鐘處理的新訂單數。

3. TPC-H

TPC-H（商業智慧計算測試）是美國交易處理效能委員會（TPC，Transaction Processing Performance Council）組織制定的用來模擬決策支援類應用的一個測試集。目前，學術界和工業界普遍採用 TPC-H 來評價決策支援技術方面應用的效能。這種商業測試可以全方位評測系統的整體商業計算綜合能力，對廠商的要求更高，同時也具有普遍的商業實用意義，目前在銀行信貸分析和信用卡分析、電信運營分析、稅收分析、菸草行業決策分析中都有廣泛的應用。

TPC-H 基準測試由 TPC-D（由 TPC 於 1994 年制定的標準，用於決策支援系統方面的測試基準）發展而來的。TPC-H 用 3NF 實現了一個資料倉儲，共包含 8 個基本關係，其主要評價指標是各個查詢的響應時間，即從提交查詢到結果返回所需時間。TPC-H 基準測試的度量單位是每小時執行的查詢數（QphH@size），其中 H 表示每小時系統執行復雜查詢的平均次數，size 表示資料庫規模的大小，它能夠反映出系統在處理查詢時的能力。

TPC-H 是根據真實的生產執行環境來建模的，這使得它可以評估一些其他測試所不能評估的關鍵效能引數。總而言之，TPC 組織頒佈的 TPC-H 標準滿足了資料倉儲領域的測試需求，並且促使各個廠商以及研究機構將該項技術推向極限。

想必各位對 OceanBase 的效能都有所耳聞，TPC-C 打榜第一，TPC-H 打榜第二。那麼如何用各種 Benchmark 流暢絲滑地測試 OceanBase，肯定是大家關心的重要一環。在這裡我們先行給大家劇透兩種 Benchmark 測試的方法。

1. OBD 測試

OceanBase Deployer（簡稱 OBD）是 OceanBase 開源軟體的安裝部署工具。同時，OBD 也提供了自動進行 Benchmark 測試的功能，使用者輸入叢集必要的資訊，即可自動進行 Schema 下發、效能調優和工具測試，從而得到一個比較可靠的效能資料結果。

2. 手工測試

如果使用者出於個性化的測試目的，我們也提供了手工操作 Benchmark 測試的文件，從安裝部署到效能資料分析，“一站式服務”包教包會。

更多方法，更詳盡的操作，敬請關注 1月13日晚19:30 釘釘直播間，子行老師手把手線上教學。

在進行 Benchmark 測試的時候，有一些常見的操作和場景對效能影響很大，在這裡也給出我們的測試建議，幫助大家避免大部分的效能不符合預期問題。

1. 磁碟劃分

CLOG、LOG、SSTABLE 建議分為多個獨立檔案系統分盤部署，退而求其次的情況下也可以用 LVM 劃分出多個 LV。如果 OBSERVER 執行日誌、事務日誌、資料檔案都在一塊盤上，可能會引發多種風險。比如事務日誌（clog）在磁碟空間超過95%就會造成節點停寫、掉線，同時也會影響 liboblog 同步，以及影響 CLOG 回收或者副本遷移速度等。

2. 租戶設定

OceanBase 是多租戶模式的資料庫，所以測試租戶的設定對 Benchmark 測試同樣重要，建議儘量給進行測試的租戶提供最多的資源（記憶體、cpu等）。另外，租戶的 PRIMARY_ZONE 是用來控制租戶裡主副本的分佈。如果設定為 RANDOM，就可以將不同分割槽的主副本分散在不同 ZONE 的節點上，以達到機器利用率的最大化。反過來，如果將 PRIMARY_ZONE 設定為某個具體的 ZONE，則只能利用部分節點。

3. 使用分割槽表 

OceanBase 的分割槽表主要有兩個作用：

● 分割槽表的使用可以在特定的 SQL 操作中減少資料讀寫的總量以減少響應時間；

● 解決單機處理效能瓶頸，將海量請求分散到不同分割槽，而不同分割槽主副本則可以分散在不同節點。

建議大家在使用 TPC-H 和 BMSQL 測試的時候採用分割槽表，Sysbench 測試建議使用非分割槽表，因為 Sysbench 如果採用分割槽表，有大量的分散式查詢，效能不如非分割槽表。

其實造成 Benchmark 效能資料不符合預期的因素和操作還有很多，受於篇幅限制沒法詳細講解，如果大家對該話題感感興趣，請關注 OceanBase 社群版直播教程的第六期——如何測試 OceanBase 社群版，我們一起來嘮嘮。

1月13日晚（下週四） 19:30，準時相約 OceanBase 社群版教程官方直播間。一個小時為你聊透 “ OceanBase 如何進行 Benchmark 測試及調優”！