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