你的資料庫，能撐起多少併發，有數嗎？
點選藍色“有關SQL”關注我喲
加個“星標”，天天與10000人一起快樂成長
阿里巴巴的 OceanBase 資料庫，效能超過 Oracle 100倍，號稱世界第一。大家可還記得今年的 OB 打榜賽？
不論真假，我還是對衡量標準，很感興趣。尤其是資料倉庫的標準TPC-H.
TPC-H測試標準，以8張表，22個查詢作為基礎，在一定時間內(通常是1小時)，通過7個併發查詢，衡量資料庫的每秒處理事務數，作為資料庫效能度量標準。用一個公式來描述整個過程，就是 [email protected]
2018 年，惠普使用 microsoft sql server on linux 作為測試物件，向 TPC 組織， 提交了一次TPC-H效能報告。
在1T的資料量下，花費近47萬美金，達到了每小時100萬的查詢數，即每秒可完成280查詢。公式表達，1009065.5 [email protected]
後臺回覆：惠普，即可得這份《報告》以及相應的表和查詢指令碼
當然，這還沒考慮到查詢效能的可接受程度，以27.6s這樣的平均速，其實很多使用者是會不滿意的。
這份報告雖然說明一定的問題，比如 Throughput 度量，價效比，但缺少對伺服器的效能監控。比如7個併發，1小時連續壓測下，伺服器的效能監控圖。
再者，資料庫的最終吞吐量，是否可以再擴大，也沒有具體說明白。如果降低併發，是不是能夠獲得較好的效能？
為了模擬惠普的這次測試，我通讀了TPC-H的測試標準，惠普的這份測試報告，還有幾篇來自維普的論文。最終找到了模擬的方法。
以下是詳細的測試步驟：
1）下載 HammerDB 軟體
2）準備 SQL Server 測試環境
3）復現 Power Test
4) 復現 Throughput Test
1) 下載 HammerDB
公眾號後臺回覆 HammerDB，即可得到 zip 版本的 HammerDB 連線。
解壓縮後，直接開啟，就可以使用
2）準備 SQL Server 測試環境
這就要自己準備了，到微軟的官方網站下載180天的試用版，即可
3）復現 Power Test
由於這次模擬的是 SQL Server TPC-H 測試標準，所以在 HammerDB 中，我們需要預先配置：
第一次開啟 HammerDB 是這樣的，以 Oracle TPC-C 為預設選中狀態：
通過選單 Options, 配置 SQL Server TPC-H 測試標準：
在 TPC-H 整套測試方案中，指定了8張表，22個查詢，配備相應的資料生成程式與查詢生成程式，但這兩個程式都是使用c/c++寫的，必須先通過編譯，再通過呼叫介面來用在自己的測試方案中，我嘗試了下，放棄！不僅原始碼複雜，有些環境還需要額外配置。
在搜尋了 n 篇論文以及博文之後，我發現 HammerDB 已經替我們把這些環境配置都搞定了，於是就它了。
有了 HammerDB,我們唯一要做的事情，就是指定一個可用的測試資料庫就可以。
這裡需要說明的是 Scale Factor，也就是擴充套件因子。說人話，就是資料庫大小配置。總共可以分為6級，1GB,10GB,30GB,100GB,300GB,1000GB.
那麼既然是自己測試，選擇1，即1GB，就可以了
點一下 Build，就完成了資料庫環境配置。
通過 SQL Server Profiler, 我們可以看到資料庫正在發生的一切：
通過 HammerDB 的Build介面，可以看到執行狀態:
當然，時間會很久，我們可以去喝一杯咖啡再來，HammerDB會自動報告，資料裝載是否完成：
由於裝載時間非常長，所以一旦資料庫建立成功，我們就要對它進行備份:
接下來，我們就要試著執行一次 Power Test:
首先配置 Driver Script:
Driver Script 做的事情，就是為測試中的虛擬使用者，配置執行的操作。比如配置一組22個查詢組成的查詢流，讓虛擬使用者在登入資料庫，依次執行這22個查詢。
配置完 Driver Script, 我們就可以生成指定數量的併發使用者。這些使用者，可以執行剛才配置的 Driver Script.
Power Test 測試目的，是察看是否有明顯的響應時間缺陷，所以設定單個使用者：
一旦配置完成，就可以雙擊 Create 來生成虛擬使用者的配置資訊：
接著，我們點選執行單使用者的單次執行：
耐心等待測試完成：
單輪測試用了124秒，似乎不夠理想。但這是我可憐的筆記本虛擬機器伺服器啊。
然後，肯定會有讀者說，這是資料倉庫啊，不能沒有寫入的操作啊。是的，這個寫入，我們也可以模擬，通過開啟 Refresh Function:
然後再重複新建使用者，並開啟測試。
4）復現 Throughput Testing
Throughput 是吞吐量的意思，這個概念很有意思。
首先來說說併發使用者。當同時有10個使用者訪問資料庫時，假設他們同時執行1條 SELECT 語句。此時，併發數是10，Throughput 也是10，但你能不能說資料庫併發度不夠呢？不能。因為此時這併發的10個使用者，都對速度感到滿意，說明完全可以再容納更多的人來資料庫查詢。
於是，增加了100個人來，還是執行 一條SELECT語句。那麼此時，如果大家還是對響應很滿意，說明資料庫非常棒，還可以吸納更多的人。
好，加20倍流量，來了200人。於是，有使用者反映，速度慢了，明顯慢了一倍以上，當有50%的人都說慢了的時候，顯然資料庫的吞吐量，要小於 200.
我們往下調調，來150人吧。此時90%以上的人，對速度滿意，那麼就可以說，資料庫的吞吐量在 150左右了。
這，就是 TPC-H 測試標準報告中，要體現的內容了。不過，人家更標準，使用的是 [email protected]
所以，我們要使用 hammerDB來模擬這個操作：
首先設定4個併發使用者，第一個使用者會模擬寫入的操作：
開啟 [email protected] 的統計功能：
等待測試完成
理論上，測試時間越長，測試的準確度越高，但我們只是模擬，所以執行一組 Query Set, 讓 HammerDB 幫我們預估就可以了：
可以看到，4個併發測試下來，大概可以得到每小時近20000個事務處理。也就是每秒鐘處理6個事務。
那麼是不是 Throughput 為6，就是我的資料庫極限了呢，我懷疑，可以更高。於是我調高了使用者併發數，加了2個，再來看 QphH:
發現，最高的 QphH 雖然比4個使用者那次高，但明顯已經影響了使用者的響應時間，普遍從原來的100s 延長到了160s 以上。說明，已經不能再增加併發查詢了，6事務/秒已經是我這臺數據庫的極限。
很可惜的是，HammerDB 並不能動態增加使用者數，導致測試不流暢，不得不說是個遺憾。我看到 oracle 廠商在 demo 他們的系統時，併發使用者數，是動態可加的，想加就加，相減就減，操作隨意地令人髮指。提高了測試的準確度。
說Oracle是世界，乃至宇宙第一，還不得不服。
--完--
往期精彩：
