?昨天的文章里最后我簡單聊了聊數(shù)據(jù)庫測試的事情，最近也有很多用戶十分關(guān)心數(shù)據(jù)庫測試的問題，因為他們都在關(guān)心信創(chuàng)數(shù)據(jù)庫如何選型的事情。前幾天我和一個客戶聊到信創(chuàng)數(shù)據(jù)庫選型的時候，我的觀點是對于國產(chǎn)數(shù)據(jù)庫選型，目前一些國測的測試報告參考價值并不大。

數(shù)據(jù)庫基準測試是十分困難的，因為最近這十幾年我也幫助客戶組織過幾次基準測試，其中的苦辣，心中自知。目前很多數(shù)據(jù)庫廠商都以TPMC測試數(shù)據(jù)作為其數(shù)據(jù)庫性能卓越的證據(jù)。不過事實上，TPC-C測試是十分復(fù)雜的，并不是我們在自己的測試環(huán)境中跑幾下子BENCHMARK工具就能得到結(jié)果的。BENCHMARK測試是成本極高的測試，需要對軟硬件，網(wǎng)絡(luò)等環(huán)境做十分細致的優(yōu)化，才能夠跑出好的效果。其結(jié)果的有效性也是有一套評估標準的，延時的標準差，P90/P95/P99位置的延時都是考察某個TPC-C測試結(jié)果是否有效的重要因素。這些都不是隨便某個用戶或者數(shù)據(jù)庫廠商自己就能夠完成的。而從另外一個方面來說，用戶的應(yīng)用系統(tǒng)能夠在某個基礎(chǔ)設(shè)施上跑出好的效果，TPC-C的高低實際上占的比重并不高。比如說并發(fā)能力，我曾經(jīng)和一個商業(yè)銀行的主管算過一筆賬，他們目前的系統(tǒng)高峰期平均每秒交易量大約1000筆，折算為TPMC大約是6萬，哪怕未來5年提升5倍，也就是30萬TPMC。現(xiàn)在的一臺國產(chǎn)2路服務(wù)器，跑隨便哪個國產(chǎn)數(shù)據(jù)庫，都可以輕松達到100萬TPMC左右，因此對于大多數(shù)非互聯(lián)網(wǎng)業(yè)務(wù)，TPMC都不是問題。

數(shù)據(jù)庫測試是十分復(fù)雜與高成本的事情，要想比較公正的做好基準測試并不容易。十多年前我?guī)椭粋€客戶對比X86服務(wù)器與小型機的效能，做過一次至強服務(wù)器與IBM/HP/ORACLE等的小型機的對比測試。當(dāng)時用的是用戶自有數(shù)據(jù)與測試用例。為了保證公正性，我們允許廠家做一定程度的優(yōu)化，但是也頒布了十分嚴格的限制，比如不能使用異步提交，不能隨意篡改數(shù)據(jù)，不能把REDO放到內(nèi)存文件系統(tǒng)等。因為涉及到隨后的集采，因此各個廠商也都十分重視，我甚至在一個廠商的工作區(qū)里發(fā)現(xiàn)了一本我?guī)啄昵皩懙摹禣RACLE優(yōu)化日記》，看樣子這哥們是準備現(xiàn)學(xué)現(xiàn)用了。

實際上那時候X86服務(wù)器已經(jīng)表現(xiàn)出了極其強勁的能力了，一臺10萬塊錢不到的服務(wù)器，基本上可以和2-300萬的小型機PK性能了。INTEL的哥們也不太懂?dāng)?shù)據(jù)庫優(yōu)化，裝好系統(tǒng)，調(diào)完基本參數(shù)，用了不到一天就完成了我們安排的3天的測試工作。而小型機廠商都十分小心，仔細地優(yōu)化每個測試用例。在分析測試數(shù)據(jù)的時候，我發(fā)現(xiàn)某個廠商的一組測試用例的結(jié)果有些異常，其他測試數(shù)據(jù)，小型機的結(jié)果與X86基本相當(dāng)，甚至有些用例還略差，不過這組測試數(shù)據(jù)，小型機完勝X86，也完勝其他小型機廠商。從我們的數(shù)據(jù)完整性校驗?zāi)_本中，也沒有發(fā)現(xiàn)數(shù)據(jù)被篡改的情況。我突然想起了那本《Oracle優(yōu)化日記》，于是讓測試小組去查一下幾張核心表的索引的CLUSTER FACTORY值，發(fā)現(xiàn)其中一張表的索引的CLUSTER FACTORY與其他企業(yè)的測試環(huán)境不同。原來這組測試用例里大多是用了索引范圍掃描，為了提高性能，這個廠商把表中的數(shù)據(jù)順序做了重排。這實際上是《Oracle優(yōu)化日記》里介紹的一個優(yōu)化小技巧，看來這哥們真的活學(xué)活用了。再后來我們的測試用例里就把記錄順序也作為了校驗的一項內(nèi)容。

數(shù)據(jù)庫基準測試是測試團隊與參測團隊魔高一尺，道高一丈的較量，如果測試團隊的技術(shù)能力不如參測團隊，那么測試數(shù)據(jù)的準確性就很難保證了?，F(xiàn)在的數(shù)據(jù)庫測試里都有代碼自主率測試這一項，很多企業(yè)在做數(shù)據(jù)庫選型的時候也十分看中這一點。我所知道的很多基于開源代碼開發(fā)的數(shù)據(jù)庫產(chǎn)品，在一些國測中也獲得了超過90%甚至95%的代碼自主率測試結(jié)果。這讓我十分疑惑，直到我真正看到了一份測試報告，才恍然大悟。有個基于某開源代碼開發(fā)的數(shù)據(jù)庫產(chǎn)品，代碼自主率測試結(jié)果是96.3%，不過仔細閱讀報告才發(fā)現(xiàn)，送測代碼總量為93萬行，送測的模塊里居然沒有SQL引擎，優(yōu)化器等，都是一些外圍模塊。但是作為一般的數(shù)據(jù)庫選型的用戶是看不到詳細的報告的，我們只能看到公布的96.3%的代碼自主率。這種測試也讓這些測試變得毫無意義。當(dāng)然我個人的觀點，代碼自主率也并不是一個十分有意義的指標。

實際上用戶做數(shù)據(jù)庫選型更需要了解的是某個數(shù)據(jù)庫產(chǎn)品到底好不好用，在某個應(yīng)用場景是否能夠很好的支撐。比如我的財務(wù)系統(tǒng)要用國產(chǎn)數(shù)據(jù)庫替換Oracle，那么我想知道用友、金蝶的產(chǎn)品在某個數(shù)據(jù)庫上跑的效果如何。數(shù)據(jù)庫廠商不會提供有價值的數(shù)據(jù)，金蝶用友官方也不會告訴你這些數(shù)據(jù)。我們的國測部門能不能組織國產(chǎn)數(shù)據(jù)庫與國產(chǎn)的套裝軟件廠家一起，做一些這方面的測試，并把測試結(jié)果公布出來呢？如果能夠公布這些測試數(shù)據(jù)，那么對于用戶做國產(chǎn)數(shù)據(jù)庫選型來說，其價值遠遠超出現(xiàn)有的所有測試。如果我們想了解數(shù)據(jù)庫對于復(fù)雜SQL的支持能力，那么從ERP系統(tǒng)的一些關(guān)鍵模塊的性能與Oracle的對比就可以清楚的了解某個數(shù)據(jù)庫產(chǎn)品對于復(fù)雜的SQL的支持情況。如果要了解高并發(fā)環(huán)境下并發(fā)寫入能力，那么某些物聯(lián)網(wǎng)套裝軟件的測試結(jié)果就很有參考價值了。?