本文存在反轉(zhuǎn)，有興趣的請看完。如果觀點不太，請見諒。大概是十年前吧，一個朋友突然打電話來說，他們公司有一個數(shù)據(jù)庫，性能超過 50倍，希望我?guī)椭纯矗懿荒茉谝恍┛蛻衾锿茝V推廣。當(dāng)時我就沒把這話當(dāng)回事，如果你說你們的數(shù)據(jù)庫性能已經(jīng)快趕上了，那我可能還會認(rèn)真的去考慮考慮。后來他覺得我對這件事不上心，親自飛到深圳，一定要給我上上課。在一個餐館里，幾杯酒下肚后，他拿出了電腦給我介紹他們的十分牛逼的數(shù)據(jù)庫系統(tǒng)。當(dāng)我看到第一頁上的Mysql語法完全兼容的時候，我就說咱們接著喝酒吧，大概我清楚了。為什么我這么有把握呢？實際上數(shù)據(jù)庫發(fā)展了幾十年，其核心技術(shù)是十分清晰的，SQL引擎、優(yōu)化器、資源管理、并發(fā)控制、存儲架構(gòu)這幾個方面的核心技術(shù)決定了數(shù)據(jù)庫最終能夠達(dá)到什么樣的高度。而在這些方面，無疑是最為優(yōu)秀的。數(shù)據(jù)庫的優(yōu)化器是決定某條SQL語句最快能跑多快的一個最為關(guān)鍵的因素，十分遺憾的是，目前的所有國產(chǎn)化數(shù)據(jù)庫，甚至加上所有的商用數(shù)據(jù)庫，沒有一個優(yōu)化器能夠和相媲美。作為一個通用數(shù)據(jù)庫，將會面臨各種復(fù)雜甚至變態(tài)的SQL語句，而優(yōu)化器都能夠找到最好的執(zhí)行計劃，這是高性能的數(shù)據(jù)庫產(chǎn)品必須具備的能力。
可惜的是，在這方面，一騎絕塵，具有絕對的統(tǒng)治力。可能有朋友會覺得我在瞎說了，現(xiàn)在霸榜TPCC測試第一名的不已經(jīng)是我們的國產(chǎn)數(shù)據(jù)庫了嗎？TPCC實際上是一種十分理想化的交易型場景，針對TPCC去做相關(guān)的數(shù)據(jù)庫產(chǎn)品優(yōu)化并不難，但是其價值并不大，這也是近些年美國的數(shù)據(jù)庫廠商大多數(shù)都已經(jīng)不再送測TPCC的主要原因，我們的數(shù)據(jù)庫產(chǎn)品擊敗的也是十多年前的數(shù)據(jù)庫。TPCC測試對于優(yōu)化器的要求其實并不高，甚至很多國產(chǎn)數(shù)據(jù)庫TPCC測試時都要求關(guān)閉HASH JOIN，以達(dá)到更高的測試效果。而HASH JION正是大數(shù)據(jù)量下表連接的十分高效的執(zhí)行方式。十年前的Mysql尚不支持Hash Join，用這個引擎去做一個數(shù)據(jù)倉庫的SQL引擎，那么這個數(shù)倉在處理復(fù)雜的OLAP分析的時候，效率會如何了，所以我當(dāng)時就對那個產(chǎn)品不感興趣了。所以在做數(shù)據(jù)庫國產(chǎn)化的時候，第一個需要了解的真相是，我們的國產(chǎn)數(shù)據(jù)庫在最為核心的優(yōu)化器，以及資源管理器、并發(fā)控制算法方面仍然與存在巨大的差距。雖然我們不太情愿承認(rèn)這一點，但是我們必須承認(rèn)。就像一個國產(chǎn)數(shù)據(jù)庫的核心研發(fā)人員所說的：“我們開始以為我們的優(yōu)化器已經(jīng)和水平相當(dāng)，但是在很多用戶實際應(yīng)用上我們才發(fā)現(xiàn)，我們還差的太遠(yuǎn)”，這句話只有真正懂?dāng)?shù)據(jù)庫的人才說得出來，盡管不是十分情愿。
在數(shù)據(jù)庫國產(chǎn)化領(lǐng)域還有另外一種說法是彎道超車，和一樣玩集中式數(shù)據(jù)庫我們不行，那我們就玩,玩MPP架構(gòu)，SHARE 。確實，分布式數(shù)據(jù)庫可以從很大程度上解決國產(chǎn)集中數(shù)據(jù)庫無法避開的SQL引擎及優(yōu)化器能力不足、資源管理并發(fā)管理方面算法效率較低的問題。就像幾年前一位領(lǐng)導(dǎo)在數(shù)據(jù)庫國產(chǎn)化相關(guān)的研討中說的：“一個人干不過你，咱們一群人還干不過你嗎？”。通過多節(jié)點，并發(fā)處理的能力來實現(xiàn)對有限節(jié)點的集中式數(shù)據(jù)庫實現(xiàn)超越，也是一條不錯的路線。不過，這條路走起來也不順利。首先是服務(wù)器的計算能力發(fā)展太快，存儲技術(shù)發(fā)展也太快了。集中式數(shù)據(jù)庫配上高性能的X86服務(wù)器，再加上閃存技術(shù)的加持，讓集中式數(shù)據(jù)庫的處理能力一下子增長了數(shù)十倍，我們追趕的難度又增加了。再加上分布式數(shù)據(jù)庫仍然避不開SQL引擎和優(yōu)化器的問題，在一個分布式環(huán)境中，優(yōu)化器開發(fā)的難度更大了，連一個單機(jī)的優(yōu)化器都做不好的研發(fā)團(tuán)隊，就更難做好分布式環(huán)境下的優(yōu)化器了。目前我們的大多數(shù)分布式國產(chǎn)數(shù)據(jù)庫，在某個特定領(lǐng)域的能力確實很強(qiáng)，比如在一些簡單的交易場景，針對銀行、證券甚至運(yùn)營商的業(yè)務(wù)邏輯較為簡單的，以數(shù)據(jù)寫入與不太復(fù)雜的查詢分析的場景，已經(jīng)支持的很好了。
目前也有不少金融企業(yè)逐漸完成國產(chǎn)數(shù)據(jù)庫替代的案例，這是極為正常的。不過很多國產(chǎn)分布式數(shù)據(jù)庫都對開發(fā)人員提出了更高的要求，肆意編寫SQL語句是絕對不允許的，必須按照數(shù)據(jù)庫提出的要求來編寫SQL。如果我們的應(yīng)用開發(fā)商能夠掌握這些技巧，在這些分布式數(shù)據(jù)庫上，完全可以寫出十分優(yōu)秀的系統(tǒng)。不幸的是，我們的IT決策人員大多數(shù)并不知道這個真相。所以說，我們今天講的第二個真相是，分布式數(shù)據(jù)庫并沒有大多數(shù)人想象的那么強(qiáng)大，起碼對某些常用應(yīng)用場景是如此的。看到這里，似乎本文是在宣揚(yáng)數(shù)據(jù)庫國產(chǎn)化無望的文章，其實不是的。因為下面我們要講的真相都是支持?jǐn)?shù)據(jù)庫國產(chǎn)化的。我們總是在談國產(chǎn)數(shù)據(jù)庫在很多關(guān)鍵技術(shù)方面與相比有著巨大的差距。但是我們往往忽略了一個十分樸素的現(xiàn)實，那就是其實實際上我們的絕大多數(shù)系統(tǒng)并不需要如此高的并發(fā)處理能力，數(shù)據(jù)量也并沒有大到無法處理的地步，真正需要的大多數(shù)高性能，高并發(fā)能力的系統(tǒng)并不多。在國產(chǎn)化數(shù)據(jù)庫替代的時候，并不一定要選擇必須能夠與相匹敵的產(chǎn)品。甚至在大多數(shù)應(yīng)用系統(tǒng)從數(shù)據(jù)庫遷移到國產(chǎn)化數(shù)據(jù)庫的時候，我們最總要的考慮因素并不是性能關(guān)閉數(shù)據(jù)庫的方法有，而是更應(yīng)該考慮兼容性、穩(wěn)定性、運(yùn)維便捷性、總體使用成本等方面的因素。
退一萬步說，一個企業(yè)里的至少80%以上的系統(tǒng)，是可以通過最為簡單的方式用國產(chǎn)化數(shù)據(jù)庫替代的。這一點已經(jīng)可以讓我們的數(shù)據(jù)庫國產(chǎn)化工作啟動起來了，隨著國產(chǎn)數(shù)據(jù)庫應(yīng)用的日益深入，我想，國產(chǎn)數(shù)據(jù)庫的技術(shù)提升也會加速。所以說，這個令人鼓舞的真相就是，我們的絕大多數(shù)應(yīng)用系統(tǒng)不需要那么強(qiáng)的能力。鼓舞之后打擊又來了，因為在信息系統(tǒng)中任何短板都是需要在應(yīng)用開發(fā)上去彌補(bǔ)的，因此如果我們不使用這樣強(qiáng)大的商用數(shù)據(jù)庫，而改用國產(chǎn)數(shù)據(jù)庫的話，我們的應(yīng)用開發(fā)人員必須去解決數(shù)據(jù)庫性能不足的問題，這對于信息系統(tǒng)的開發(fā)團(tuán)隊是一個巨大的考驗。曾經(jīng)有一個企業(yè)在把應(yīng)用系統(tǒng)向阿里云遷移的時候發(fā)現(xiàn)，原有的應(yīng)用開發(fā)團(tuán)隊能力不足，無法駕馭RDS/DRDS上的研發(fā)工作，于是只能重組整個隊伍，提升隊伍的技術(shù)水平，僅此一點，每年在研發(fā)方面的投入要增加2000萬。事實上，不僅僅是研發(fā)，在系統(tǒng)上線后的運(yùn)維、優(yōu)化等方面都需要有一定的投入，才能支撐數(shù)據(jù)庫國產(chǎn)化的工作。而事實上，我們的很多IT部門的決策者并不了解這方面，他們覺得只要選擇好一款國產(chǎn)化數(shù)據(jù)庫，把替換了，就萬事大吉了。如果我們在數(shù)據(jù)庫國產(chǎn)化工作中僅僅如此簡單操作，那么數(shù)據(jù)庫國產(chǎn)化的過程中肯定會遇到一地雞毛的。
第四個真相是，數(shù)據(jù)庫國產(chǎn)化是一個復(fù)雜的生態(tài)建設(shè)工程，而不僅僅是一次商業(yè)采購的產(chǎn)品替換，在這個問題上我們遠(yuǎn)沒有準(zhǔn)備好，必須花大力氣在應(yīng)用研發(fā)、系統(tǒng)優(yōu)化、運(yùn)維支撐等全領(lǐng)域都構(gòu)建起針對國產(chǎn)化數(shù)據(jù)庫的能力，才能把這項工作做好。今天要講的最后一個真相是，確實太昂貴了關(guān)閉數(shù)據(jù)庫的方法有，我們真的用不起。可能很多朋友都覺得應(yīng)該是使用成本最低的數(shù)據(jù)庫了，我們花100萬買一套數(shù)據(jù)庫，可以節(jié)約更多的研發(fā)、運(yùn)維方面的成本，不是很劃算嗎？實際上講數(shù)據(jù)庫成本的時候確實要算總賬，不能僅僅算買數(shù)據(jù)庫的錢。但是我們的計算過程出問題了。數(shù)據(jù)庫對于一般企業(yè)的許可證是一個核20萬左右（如果加上RAC//甚至我們常用的AWR都是要另外加錢都的），對于一臺16核的四路服務(wù)器來說，哪怕按照1/2的核數(shù)來計算許可證的話，購買的合法許可證費用是640萬，再加上每面22%的標(biāo)準(zhǔn)服務(wù)費（這個費用最主要是要合法的下載補(bǔ)丁），這絕對不是一般企業(yè)能夠承受的起的。可能有朋友不服氣了，我們就是花了幾十萬買了一套正版的。沒錯你花錢買了一套正版的，但是你在使用的時候超范圍使用了，這在法律上也構(gòu)成了盜版。
這也是為什么很多美國的大公司大量的在使用SQL ,MYSQL等數(shù)據(jù)庫的一個主要的原有。十多年前，去IOE浪潮興起的時候，我就和一位美國的DBA交流過為什么美國沒有去IOE浪潮。他說：“我們用不起那么多的，只是在必須使用的場景使用，其他的地方能用不花錢的MYSQL就用MYSQL,或者用便宜點的SQL ”。既然如此，我們趁著數(shù)據(jù)庫國產(chǎn)化的機(jī)會，把以前那么多存在盜版法律風(fēng)險的問題解決掉，不也是一件好事嗎。其實在這里我也要說一個不得不說的殘酷真相，那就是某些系統(tǒng)，目前還真的很難找到的替代品，那么我們也不必要糾結(jié)，繼續(xù)使用就行了。條件不成熟時候就強(qiáng)行換掉也是不符合科學(xué)的事情。可能有些朋友不相信這種場景的存在，我也沒辦法讓每個人都相信我的觀點，觀點并不等于事實，任何時候事實只有一個，觀點可能各不相同，沒必要每個人的觀點都相同。