國產(chǎn)數(shù)據(jù)庫對比測試應(yīng)注意的七個要點(diǎn)

白鱔(徐戟)
做國產(chǎn)數(shù)據(jù)庫的對比測試是一件十分不容易的事情,往往想獲得一個較為公正的結(jié)果,但是總是覺得被廠家牽著鼻子走。作者十多年來參加過多次數(shù)據(jù)庫基準(zhǔn)測試和選型測試,分享了自己的經(jīng)驗之談。

本文來自微信公眾號“twt企業(yè)IT社區(qū)”,作者/白鱔(徐戟),南京基石數(shù)據(jù)技術(shù)有限責(zé)任公司技術(shù)總監(jiān),在軟件開發(fā)、系統(tǒng)運(yùn)維、信息系統(tǒng)優(yōu)化、信息系統(tǒng)國產(chǎn)化替代等領(lǐng)域從事技術(shù)研究近30年,曾主持開發(fā)了國內(nèi)首套電信級聯(lián)機(jī)實時計費(fèi)系統(tǒng)、國內(nèi)首套三檢合一的檢驗檢疫管理系統(tǒng)、銀行綜合大前置平臺(IPP)等大型系統(tǒng)。著有《Oracle RAC日記》、《Oracle DBA優(yōu)化日記》和《DBA的思想天空》等技術(shù)專著。信息無障礙研究會專職顧問,深圳市鯤鵬產(chǎn)業(yè)聯(lián)盟高級顧問,Oracle ACE,POSTGRESQL ACE DIRECTOR。

一個朋友打電話來討論,說他們在做國產(chǎn)數(shù)據(jù)庫測試的時候,原本一個場景某數(shù)據(jù)庫跑出來的性能與他們的預(yù)期差不多,不過數(shù)據(jù)庫廠商不滿意,于是上去調(diào)整了一通,居然性能大幅提升,并且遠(yuǎn)超出他們對產(chǎn)品的理解。實際上做國產(chǎn)數(shù)據(jù)庫的對比測試是一件十分不容易的事情,往往想獲得一個較為公正的結(jié)果,但是總是覺得被廠家牽著鼻子走。作為一個最近這十多年來參加過多次數(shù)據(jù)庫基準(zhǔn)測試和選型測試的我,今天就聊聊這個話題吧。

既然是對比測試,那么公平是第一位的,而針對現(xiàn)在數(shù)據(jù)庫架構(gòu)十分復(fù)雜,差異性很大,這種情況下,要公正十分困難,在第一個環(huán)節(jié),底層硬件配置上就十分困難,有些時候只能使用等價配置。前陣子有個測試,參測的其他數(shù)據(jù)庫都是分布式數(shù)據(jù)庫,數(shù)據(jù)都是可以存儲在本地的SSD盤上的,不過有一個參測廠商是使用共享存儲讀寫分離架構(gòu)的,那么就必須給他們提供集中式存儲。而如果提供集中式存儲,那么硬件環(huán)境就又不相同了。讓分布式數(shù)據(jù)庫也使用集中式存儲?分布式數(shù)據(jù)庫廠商對集中式存儲的性能又提出了疑義。最后幸虧是后來那個廠家退出了,這件事才圓滿解決了,否則我都有點(diǎn)蒙圈。

測試中第二件讓人疑惑的事情就是能否讓數(shù)據(jù)庫廠商來操作測試或者操作測試環(huán)境。以我多年的經(jīng)驗來看,如果能夠不讓廠家接觸測試環(huán)境,盡可能不要讓他們接觸。以前做基準(zhǔn)測試的時候,IBM/HP等參加測試能力很強(qiáng)的企業(yè)都有十分豐富的應(yīng)對此類測試的經(jīng)驗,別的廠商和他們一起測試,絕對不是在參加一個公平的測試?,F(xiàn)在某些國產(chǎn)數(shù)據(jù)庫廠商已經(jīng)把IBM等的精髓學(xué)得差不多了,和他們一起玩,防不勝防。也有朋友擔(dān)心不讓廠家接觸環(huán)境,會不會因為優(yōu)化不到位而導(dǎo)致某些廠家的測試結(jié)果不客觀呢?其實這一點(diǎn)容易解決,廠家可以旁觀,或者對測試結(jié)果提出疑問,并且根據(jù)采集到的監(jiān)控數(shù)據(jù)提出問題點(diǎn),不過盡可能不要讓廠家直接操作系統(tǒng)。否則就會出現(xiàn)我文章前面講的場景,不知道廠家做了啥,系統(tǒng)莫名其妙的大幅提升了。

第二個問題其實引出了第三個問題,就是哪些對數(shù)據(jù)庫的調(diào)整是不允許的。在對比測試時,有些廠商為了獲得好成績,無所不用之極。比如把REDO/UNDO/TEMP放入內(nèi)存盤中,開啟異步提交,關(guān)閉集群延時檢查等。在優(yōu)化器上還會采用關(guān)閉HASH JOIN,強(qiáng)制啟用結(jié)果緩沖等。我們的原則是,所有不能在生產(chǎn)系統(tǒng)中使用的配置和參數(shù)是堅決不允許在測試中使用的。不過對于國產(chǎn)數(shù)據(jù)庫,這些you點(diǎn)麻煩,因為我們不知道哪些參數(shù)是不允許使用的。不過我們可以將數(shù)據(jù)庫默認(rèn)安裝后的參數(shù)與配置保存一份,測試過程中再采集幾份,作為今后分析測試結(jié)果有消息的證據(jù)。

第四個問題是在測試過程中是否允許改寫SQL語句,不同的數(shù)據(jù)庫,其優(yōu)化器和SQL引擎是有差異的,有些在ORACLE上能跑并且跑得不錯的SQL,可能在國產(chǎn)庫上跑得很差甚至無法執(zhí)行。這一點(diǎn)其實很常見,也并不能說國產(chǎn)數(shù)據(jù)庫就不行。如果通過等價改寫能夠解決這個問題,那么我們應(yīng)該能夠承認(rèn)這個測試結(jié)果。只不過我們要記錄一下,經(jīng)過了等價改寫。既然判斷是等價改寫,我們就需要嚴(yán)格比對輸出的結(jié)果是否正確。

第五個問題是,是否允許在中途調(diào)整數(shù)據(jù)庫參數(shù)或者表的分區(qū)分布。這一點(diǎn)嚴(yán)格上說應(yīng)該不允許,不過對于一些較為復(fù)雜的測試,特別是在分布式數(shù)據(jù)庫上的測試,剛開始的分布策略設(shè)計可能不夠合理。有些時候做些調(diào)整,會有很大的性能提升。不過要注意的一點(diǎn)是,如果做了這方面的調(diào)整(哪怕是修改了一個參數(shù)),所有的已經(jīng)測試過的測試項都必須重新測試一遍,并將以前所有的測試結(jié)果作廢。為了確保測試進(jìn)度,這種調(diào)整一定要做限制,比如每個廠商只允許調(diào)整一次。

第六個問題,SQL性能測試最好帶有背景壓力。我們經(jīng)常會遇到測試時候性能不錯,實戰(zhàn)時候差強(qiáng)人意的情況。這是因為SQL在測試環(huán)境是獨(dú)立運(yùn)行的,沒有任何背景壓力干擾,高可用切換場景或者故障自愈場景也是如此,在沒有一定負(fù)載下,都是很正常的,帶一定的背景負(fù)載很可能就不同了。我們以前曾經(jīng)見過某國產(chǎn)數(shù)據(jù)庫,跑200并發(fā)BENCHMARK的時候性能不錯,不過如果連上10000個空會話,再跑BENCHMARK,性能要打不少折扣。這可能是數(shù)據(jù)庫在維護(hù)會話列表的代碼上沒有做好優(yōu)化導(dǎo)致的,雖然是個小問題,不過如果沒有注意,到了生產(chǎn)環(huán)境還是會引發(fā)問題的。

第七個問題是要關(guān)注SQL執(zhí)行的穩(wěn)定性問題,如果你的應(yīng)用場景是對小SQL的執(zhí)行延時有要求的,比如銀行的核心交易系統(tǒng),現(xiàn)在網(wǎng)聯(lián)對核心交易超時的監(jiān)控十分嚴(yán)格,那么SQL執(zhí)行的穩(wěn)定性就十分關(guān)鍵了。同樣一條SQL是否執(zhí)行起來忽快忽慢,相同的SQL是否經(jīng)常出現(xiàn)多次執(zhí)行執(zhí)行計劃不同,這也應(yīng)該我們關(guān)注的。如果時間充裕,最好多跑幾遍,最后算個標(biāo)準(zhǔn)差出來,做個比對。

實際上很多時候測試往往并不能對我們的決策產(chǎn)生多大的影響,有可能IT部門辛苦幾個月干完了測試,突然某廠家與企業(yè)高層簽署了戰(zhàn)略合作協(xié)議,那活就白干了。不過測試中發(fā)現(xiàn)的問題,積累的經(jīng)驗,今后運(yùn)維中還是有點(diǎn)價值的。

THEEND

最新評論(評論僅代表用戶觀點(diǎn))

更多
暫無評論