建站
咨詢
售后
建站咨詢
新聞中心
?昨天的文章里最后我簡單聊了聊數(shù)據(jù)庫測試的事情，最近也有很多用戶十分關心數(shù)據(jù)庫測試的問題，因為他們都在關心信創(chuàng)數(shù)據(jù)庫如何選型的事情。前幾天我和一個客戶聊到信創(chuàng)數(shù)據(jù)庫選型的時候，我的觀點是對于國產(chǎn)數(shù)據(jù)庫選型，目前一些國測的測試報告參考價值并不大。
創(chuàng)新互聯(lián)建站服務項目包括隆安網(wǎng)站建設、隆安網(wǎng)站制作、隆安網(wǎng)頁制作以及隆安網(wǎng)絡營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關系等，向廣大中小型企業(yè)、政府機構等提供互聯(lián)網(wǎng)行業(yè)的解決方案，隆安網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前，我們服務的客戶以成都為中心已經(jīng)輻射到隆安省份的部分城市，未來相信會繼續(xù)擴大服務區(qū)域并繼續(xù)獲得客戶的支持與信任！
數(shù)據(jù)庫基準測試是十分困難的，因為最近這十幾年我也幫助客戶組織過幾次基準測試，其中的苦辣，心中自知。目前很多數(shù)據(jù)庫廠商都以TPMC測試數(shù)據(jù)作為其數(shù)據(jù)庫性能卓越的證據(jù)。不過事實上，TPC-C測試是十分復雜的，并不是我們在自己的測試環(huán)境中跑幾下子BENCHMARK工具就能得到結果的。BENCHMARK測試是成本極高的測試，需要對軟硬件，網(wǎng)絡等環(huán)境做十分細致的優(yōu)化，才能夠跑出好的效果。其結果的有效性也是有一套評估標準的，延時的標準差，P90/P95/P99位置的延時都是考察某個TPC-C測試結果是否有效的重要因素。這些都不是隨便某個用戶或者數(shù)據(jù)庫廠商自己就能夠完成的。而從另外一個方面來說，用戶的應用系統(tǒng)能夠在某個基礎設施上跑出好的效果，TPC-C的高低實際上占的比重并不高。比如說并發(fā)能力，我曾經(jīng)和一個商業(yè)銀行的主管算過一筆賬，他們目前的系統(tǒng)高峰期平均每秒交易量大約1000筆，折算為TPMC大約是6萬，哪怕未來5年提升5倍，也就是30萬TPMC。現(xiàn)在的一臺國產(chǎn)2路服務器，跑隨便哪個國產(chǎn)數(shù)據(jù)庫，都可以輕松達到100萬TPMC左右，因此對于大多數(shù)非互聯(lián)網(wǎng)業(yè)務，TPMC都不是問題。
數(shù)據(jù)庫測試是十分復雜與高成本的事情，要想比較公正的做好基準測試并不容易。十多年前我?guī)椭粋€客戶對比X86服務器與小型機的效能，做過一次至強服務器與IBM/HP/ORACLE等的小型機的對比測試。當時用的是用戶自有數(shù)據(jù)與測試用例。為了保證公正性，我們允許廠家做一定程度的優(yōu)化，但是也頒布了十分嚴格的限制，比如不能使用異步提交，不能隨意篡改數(shù)據(jù)，不能把REDO放到內(nèi)存文件系統(tǒng)等。因為涉及到隨后的集采，因此各個廠商也都十分重視，我甚至在一個廠商的工作區(qū)里發(fā)現(xiàn)了一本我?guī)啄昵皩懙摹禣RACLE優(yōu)化日記》，看樣子這哥們是準備現(xiàn)學現(xiàn)用了。
實際上那時候X86服務器已經(jīng)表現(xiàn)出了極其強勁的能力了，一臺10萬塊錢不到的服務器，基本上可以和2-300萬的小型機PK性能了。INTEL的哥們也不太懂數(shù)據(jù)庫優(yōu)化，裝好系統(tǒng)，調(diào)完基本參數(shù)，用了不到一天就完成了我們安排的3天的測試工作。而小型機廠商都十分小心，仔細地優(yōu)化每個測試用例。在分析測試數(shù)據(jù)的時候，我發(fā)現(xiàn)某個廠商的一組測試用例的結果有些異常，其他測試數(shù)據(jù)，小型機的結果與X86基本相當，甚至有些用例還略差，不過這組測試數(shù)據(jù)，小型機完勝X86，也完勝其他小型機廠商。從我們的數(shù)據(jù)完整性校驗腳本中，也沒有發(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)化小技巧，看來這哥們真的活學活用了。再后來我們的測試用例里就把記錄順序也作為了校驗的一項內(nèi)容。
數(shù)據(jù)庫基準測試是測試團隊與參測團隊魔高一尺，道高一丈的較量，如果測試團隊的技術能力不如參測團隊，那么測試數(shù)據(jù)的準確性就很難保證了?，F(xiàn)在的數(shù)據(jù)庫測試里都有代碼自主率測試這一項，很多企業(yè)在做數(shù)據(jù)庫選型的時候也十分看中這一點。我所知道的很多基于開源代碼開發(fā)的數(shù)據(jù)庫產(chǎn)品，在一些國測中也獲得了超過90%甚至95%的代碼自主率測試結果。這讓我十分疑惑，直到我真正看到了一份測試報告，才恍然大悟。有個基于某開源代碼開發(fā)的數(shù)據(jù)庫產(chǎn)品，代碼自主率測試結果是96.3%，不過仔細閱讀報告才發(fā)現(xiàn)，送測代碼總量為93萬行，送測的模塊里居然沒有SQL引擎，優(yōu)化器等，都是一些外圍模塊。但是作為一般的數(shù)據(jù)庫選型的用戶是看不到詳細的報告的，我們只能看到公布的96.3%的代碼自主率。這種測試也讓這些測試變得毫無意義。當然我個人的觀點，代碼自主率也并不是一個十分有意義的指標。
實際上用戶做數(shù)據(jù)庫選型更需要了解的是某個數(shù)據(jù)庫產(chǎn)品到底好不好用，在某個應用場景是否能夠很好的支撐。比如我的財務系統(tǒng)要用國產(chǎn)數(shù)據(jù)庫替換Oracle，那么我想知道用友、金蝶的產(chǎn)品在某個數(shù)據(jù)庫上跑的效果如何。數(shù)據(jù)庫廠商不會提供有價值的數(shù)據(jù)，金蝶用友官方也不會告訴你這些數(shù)據(jù)。我們的國測部門能不能組織國產(chǎn)數(shù)據(jù)庫與國產(chǎn)的套裝軟件廠家一起，做一些這方面的測試，并把測試結果公布出來呢？如果能夠公布這些測試數(shù)據(jù)，那么對于用戶做國產(chǎn)數(shù)據(jù)庫選型來說，其價值遠遠超出現(xiàn)有的所有測試。如果我們想了解數(shù)據(jù)庫對于復雜SQL的支持能力，那么從ERP系統(tǒng)的一些關鍵模塊的性能與Oracle的對比就可以清楚的了解某個數(shù)據(jù)庫產(chǎn)品對于復雜的SQL的支持情況。如果要了解高并發(fā)環(huán)境下并發(fā)寫入能力，那么某些物聯(lián)網(wǎng)套裝軟件的測試結果就很有參考價值了。?
網(wǎng)站名稱：聊聊數(shù)據(jù)庫基準測試
URL網(wǎng)址：http://www.5511xx.com/article/dpchpip.html
