聊一聊資料庫基準測試那些事
昨天的文章裡最後我簡單聊了聊資料庫測試的事情,最近也有很多使用者十分關心資料庫測試的問題,因為他們都在關心信創資料庫如何選型的事情。前幾天我和一個客戶聊到信創資料庫選型的時候,我的觀點是對於國產資料庫選型,目前一些國測的測試報告參考價值並不大。
資料庫基準測試是十分困難的,因為最近這十幾年我也幫助客戶組織過幾次基準測試,其中的苦辣,心中自知。目前很多資料庫廠商都以TPMC測試資料作為其資料庫效能卓越的證據。不過事實上,TPC-C測試是十分複雜的,並不是我們在自己的測試環境中跑幾下子BENCHMARK工具就能得到結果的。BENCHMARK測試是成本極高的測試,需要對軟硬體,網路等環境做十分細緻的最佳化,才能夠跑出好的效果。其結果的有效性也是有一套評估標準的,延時的標準差,P90/P95/P99位置的延時都是考察某個TPC-C測試結果是否有效的重要因素。這些都不是隨便某個使用者或者資料庫廠商自己就能夠完成的。而從另外一個方面來說,使用者的應用系統能夠在某個基礎設施上跑出好的效果,TPC-C的高低實際上佔的比重並不高。比如說併發能力,我曾經和一個商業銀行的主管算過一筆賬,他們目前的系統高峰期平均每秒交易量大約1000筆,折算為TPMC大約是6萬,哪怕未來5年提升5倍,也就是30萬TPMC。現在的一臺國產2路伺服器,跑隨便哪個國產資料庫,都可以輕鬆達到100萬TPMC左右,因此對於大多數非網際網路業務,TPMC都不是問題。
資料庫測試是十分複雜與高成本的事情,要想比較公正的做好基準測試並不容易。十多年前我幫助一個客戶對比X86伺服器與小型機的效能,做過一次至強伺服器與IBM/HP/ORACLE等的小型機的對比測試。當時用的是使用者自有資料與測試用例。為了保證公正性,我們允許廠家做一定程度的最佳化,但是也頒佈了十分嚴格的限制,比如不能使用非同步提交,不能隨意篡改資料,不能把REDO放到記憶體檔案系統等。因為涉及到隨後的集採,因此各個廠商也都十分重視,我甚至在一個廠商的工作區裡發現了一本我幾年前寫的《ORACLE最佳化日記》,看樣子這哥們是準備現學現用了。
實際上那時候X86伺服器已經表現出了極其強勁的能力了,一臺10萬塊錢不到的伺服器,基本上可以和2-300萬的小型機PK效能了。INTEL的哥們也不太懂資料庫最佳化,裝好系統,調完基本引數,用了不到一天就完成了我們安排的3天的測試工作。而小型機廠商都十分小心,仔細地最佳化每個測試用例。在分析測試資料的時候,我發現某個廠商的一組測試用例的結果有些異常,其他測試資料,小型機的結果與X86基本相當,甚至有些用例還略差,不過這組測試資料,小型機完勝X86,也完勝其他小型機廠商。從我們的資料完整性校驗指令碼中,也沒有發現資料被篡改的情況。我突然想起了那本《Oracle最佳化日記》,於是讓測試小組去查一下幾張核心表的索引的CLUSTER FACTORY值,發現其中一張表的索引的CLUSTER FACTORY與其他企業的測試環境不同。原來這組測試用例裡大多是用了索引範圍掃描,為了提高效能,這個廠商把表中的資料順序做了重排。這實際上是《Oracle最佳化日記》裡介紹的一個最佳化小技巧,看來這哥們真的活學活用了。再後來我們的測試用例裡就把記錄順序也作為了校驗的一項內容。
資料庫基準測試是測試團隊與參測團隊魔高一尺,道高一丈的較量,如果測試團隊的技術能力不如參測團隊,那麼測試資料的準確性就很難保證了。現在的資料庫測試裡都有程式碼自主率測試這一項,很多企業在做資料庫選型的時候也十分看中這一點。我所知道的很多基於開原始碼開發的資料庫產品,在一些國測中也獲得了超過90%甚至95%的程式碼自主率測試結果。這讓我十分疑惑,直到我真正看到了一份測試報告,才恍然大悟。有個基於某開原始碼開發的資料庫產品,程式碼自主率測試結果是96.3%,不過仔細閱讀報告才發現,送測程式碼總量為93萬行,送測的模組里居然沒有SQL引擎,最佳化器等,都是一些外圍模組。但是作為一般的資料庫選型的使用者是看不到詳細的報告的,我們只能看到公佈的96.3%的程式碼自主率。這種測試也讓這些測試變得毫無意義。當然我個人的觀點,程式碼自主率也並不是一個十分有意義的指標。
實際上使用者做資料庫選型更需要了解的是某個資料庫產品到底好不好用,在某個應用場景是否能夠很好的支撐。比如我的財務系統要用國產資料庫替換Oracle,那麼我想知道用友、金蝶的產品在某個資料庫上跑的效果如何。資料庫廠商不會提供有價值的資料,金蝶用友官方也不會告訴你這些資料。我們的國測部門能不能組織國產資料庫與國產的套裝軟體廠家一起,做一些這方面的測試,並把測試結果公佈出來呢?如果能夠公佈這些測試資料,那麼對於使用者做國產資料庫選型來說,其價值遠遠超出現有的所有測試。如果我們想了解資料庫對於複雜SQL的支援能力,那麼從ERP系統的一些關鍵模組的效能與Oracle的對比就可以清楚的瞭解某個資料庫產品對於複雜的SQL的支援情況。如果要了解高併發環境下併發寫入能力,那麼某些物聯網套裝軟體的測試結果就很有參考價值了。
來自 “ 白鱔的洞穴 ”, 原文作者:白鱔;原文連結:https://mp.weixin.qq.com/s/NJZ-f-lfC3r2Ioz4ITi2oA,如有侵權,請聯絡管理員刪除。
相關文章
- 聊一聊資料匯出那些事
- 聊一聊如何使用Crank給我們的類庫做基準測試
- 聊一聊 IP 地址那些事兒
- 聊一聊Iterable與Iterator的那些事!
- 聊一聊測試流程
- 聊一聊高併發高可用那些事 - Kafka篇Kafka
- 對話科藍軟體張俊喜:聊一聊資料庫智慧財產權的那些事兒資料庫
- 聊一聊華為雲彈性公網IP的那些事兒
- 聊一聊時序資料庫和TimescaleDB資料庫
- 聊一聊圖資料庫的發展現狀資料庫
- 聊一聊我對測試開發的看法
- 聊一聊評分模型校準模型
- 一文聊透 IP 地址的那些事
- 對話戴爾科技集團劉志洪 聊一聊非結構化資料儲存的那些事兒
- 聊一聊web前端那些事兒,關於深複製和淺複製Web前端
- 聊一聊遊戲的壓測遊戲
- 聊一聊資料應用中的資料集市
- 聊一聊HTML5那點事兒HTML
- 對話戴爾科技集團李俊邦 聊一聊智慧零售的那些事兒
- 資料庫基準測試工具 sysbench資料庫
- 一次SQL調優 聊一聊 SQLSERVER 資料頁SQLServer
- 從前世今生聊一聊,大廠為啥親睞時序資料庫資料庫
- 聊一聊 RestTemplateREST
- 聊一聊 cookieCookie
- 對話戴爾科技集團吳躍:聊一聊邊緣計算與AI的那些事兒AI
- [貝聊科技]理解資料庫索引資料庫索引
- 聊一聊 AOP :表現形式與基礎概念
- 聊一聊 TLS/SSLTLS
- 聊一聊異構系統間資料一致性
- 測試基準資料的準備
- 聊一聊redis十種資料型別及底層原理Redis資料型別
- 聊一聊Oracle的Tablespace(一)Oracle
- 聊一聊那些腦洞大開、有趣又奇葩的排序演算法排序演算法
- 聊一聊前端換膚前端
- 聊一聊 JVM 的 GCJVMGC
- 聊一聊Greenplum與PostgreSQLSQL
- 聊一聊模板方法模式模式
- 聊一聊session和cookieSessionCookie