再聊聊資料庫國產化替代

本文主要探討資料庫國產化資料庫中的策略，選型等方面的問題。今天的文章比較長，有5000多字，建議大家先收藏再慢慢閱讀。

從2019年華為事件發生開始，就不斷有企業和我討論資料庫國產化替代的事情。我也參與了一些資料庫國產化方案的編寫工作。不過這些年來，我看到的資料庫國產化替代似乎有點雷聲大雨點小。大家都挺關注，領導也夠重視，方案做了一遍又一遍，但是動作實際上並不大。這和前些年的去IOE浪潮形成了鮮明的對比，那一次大家也是從疑惑到開始試探，到大規模應用，不過類似的猶豫期短了很多，一旦小規模試探結束，大規模應用隨之而來。這回的資料庫國產化工作似乎推進的沒有這麼快。細想起來，這也很正常。去IOE給企業帶來的是十分明顯的省錢效益，用相對已經十分穩定的,價格十分便宜的，市場上採購週期極短的X86替代昂貴，採購週期很長的小型機，以及用免費的開源資料庫替代Oracle，可以大大降低企業IT的成本。而資料庫國產化替代就沒那麼簡單了，這項工作雖然說涉及到資訊化的根本安全，但是當某種特殊的威脅沒有立即發生到自己頭上的時候，總是覺得資料庫國產化替代的效費比不太划算，所以領導總說這是大事，但是到了行動上就只是蜻蜓點水，也就是很正常的事情了。

不過形勢比人強，隨著國際形勢的變化，資訊系統國產化替代的勢頭來的越來越猛。目前還按兵不動的企業受到的壓力也越來越大。很多企業把目標定為在2027年底前實現應替盡替，因此最晚從明年開始也要開始大規模的替換工作了。資料庫國產化替代的方案，也不能總是處於論證階段，而是真的要開始著手實施了。

實際上，如果真的去做這件事，方案選型也並不是很難的事情，也並非必須經過嚴格的考慮才不會出錯的，有時候你考慮了良久，反而最後的選擇不見得最好。而我的觀點是，可能會選錯資料庫但是你的資料庫國產化道路不會走錯，你會在不斷的糾偏過程中不斷的完善方案。

當年Oracle資料庫一統江湖，替掉90年代五花八門的資料庫產品，絕大多數企業也並不是做了很詳細的規劃，才一點點實施起來的。而且那時候Oracle資料庫也沒有那麼好的口碑，在人們的眼中也並不是怎麼選都不會錯的產品。很多企業是不情願的用了Oracle，發現Oracle很不錯，以後資訊系統上線就全部使用Oracle了。最後，企業裡其他資料庫產品也逐漸在系統升級時換成Oracle了。

我有一個客戶，20年開始準備資料庫國產化替代的事情。首先選了一款國產分散式資料庫，遷移了一套小系統。遷移過程中發現研發投入，上線運維方面，都存在不小的問題。21年根據上級單位要求，對OA系統進行國產化遷移，選擇了一套OA系統支援的集中式資料庫，發現整個遷移工作順利了很多，遷移費用也比第一個專案更低。於是他們決定試著在幾個新的專案裡使用這個集中式資料庫產品，進一步積累經驗。我想對於大多數企業來說，這種小步快跑，不斷修正的方式是成本最低，比較容易成功的。等到積累了足夠的遷移經驗的時候，再進行大規模遷移工作，那應該不會太難。

有些企業的IT規模較大，特別怕試錯，因此他們總是希望謀而後動，先把方案做紮實了，然後再全面推進。不過我總覺得做此類方案的靠譜指數往往偏低，“專家”提出來的方案也不見得是正確的、適合企業現狀的。就像見過豬跑，也很難想象得出紅燒肉是啥味道一樣，只做方案，不去嘗試，是不夠的。

可能有些朋友覺得對資料庫國產化替代這樣一個技術問題，不談技術，僅僅談決心，是不是有點太唯心了。資料庫替代這個難題，難道光靠下決心就可以實現的嗎?事實上，如果說資料庫國產化工作的成敗，放在第一位的還就不是技術問題，而是決心。只要下了決心，就一定能幹成。當然光有決心還是不夠的，技術問題也是需要充分考慮的。今天我們的下半部分，就來討論一下技術方面的問題，其中的核心還是資料庫選型的問題。

現在國產、開源資料庫數量巨大，種類繁多，如何選擇確實令人頭疼。很多朋友都很關心資料庫選型的技術問題，不過我覺得資料庫選型，技術問題還可以往後放一放。因為資料庫對應用系統研發的影響很大，因此資料庫最忌諱的是經常更換。一旦完成選型，最好是能夠五到十年內不要更換。因此在資料庫選型的時候，要麼選擇相對活躍的開源社群，要麼選擇規模較大的大廠產品。對於IT規模較大的企業，一些很有特色的小廠產品，雖然可能在某些方面很有吸引力，不過也要慎重對待。在這一點上，大規模使用的關係型資料庫選型一定要考慮長遠，而對於一些特色功能的，使用範圍較小的資料庫，則可以選擇一些中小企業的產品。

資料庫選型，在商業路線上有開源、商用兩個大的路線可選。開源和商用資料庫產品的選擇，一直爭論不休。開源資料庫的誘惑是任何一個企業都無法拒絕的，許可證免費，社群的支援力量，大量的使用者積累下來的應用運維經驗，這些對於資料庫替代來說都是十分稀缺的資源。因為開源資料庫的程式碼是開放的，從開原始碼中，最終可以找到解決某些疑難問題的方法，因此相對於程式碼封閉的商用資料庫而言，開源資料庫更容易形成良好的第三方服務生態。不過開源資料庫算不算國產資料庫，算不算信創資料庫的問題，也困擾了很多企業。另外開源資料庫無法獲得原廠的支援，也就缺少了一個兜底的支撐單位，這也讓很多企業面臨選擇困境。

商用資料庫則正好相反，許可證是要收費的，而且目前國產商用資料庫的許可證是需要花錢購買的，而且也不像Oracle一樣可以打打插邊球。國產商用資料庫的使用者群體目前也還不夠大，第三方服務能力也十分薄弱，遠遠比不上一些著名的開源資料庫產品。不過商用資料庫後面有一個“原廠”存在，可以幫你兜底。只不過這個“原廠”的兜底能力因原廠的規模與實力不同，有較大的差別。

有些人覺得資料庫國產化替代絕對不能用開源資料庫簡單的替代了，這一點我不是太認同。開源資料庫已經被很多規模不同而企業證明了，是Oracle等資料庫的很好的替代者之一。因為開源社群的特點，大部分開源協議保證了這些資料庫並不會因為美國的進出口管制措施而影響你的使用。在應用最為廣泛的開源資料庫-MySQL和Postgresql資料庫方面，很多企業已經獲得了巨大的收益。

如果企業的研發能力較強，應用系統都已經微服務化了，那麼可以把資料庫拆分的比較細小，使用MySQL是十分好的選擇。MySQL的運維十分簡單，業務邏輯都在應用裡做了充分最佳化後，只要在MySQL的高可用架構上做好設計，那麼平時的運維是很簡單的，偶然發生某個庫出問題了，只要重啟資料庫例項或者切換備庫就可以解決問題了。

如果企業的應用相對複雜，SQL經常會出現數張大表的關聯查詢，而研發部門的最佳化能力也有限，那麼Postgresql可能是你比較好的選擇。PG的最佳化器能力十分強大，可以解決大多數複雜查詢的效能問題。而PG的外掛結構也可以讓你透過一些特殊的方式，甚至為某個特殊應用場景開發特殊的索引來解決一些開源版本無法解決的問題。

目前已經有不少國產資料庫也走上了開源的道路，這些資料庫也是國產化替代中的不錯的選項。與美國主導的社群的開源資料庫產品相比，我國企業主導的開源資料庫產品在極端情況下會更安全。目前PingCap的TiDB、螞蟻的Oceanbase、華為的openGauss、阿里的PolarDB都已經形成了一定規模的開源生態。

除此之外，實際上現在有很多國產資料庫產品也都是基於開源專案的。比如人大金倉KingBaseES、瀚高HighoDB、優璇資料庫等都是基於Postgresql開源專案的。openGauss這個開源專案的源頭也是Postgresql 9.2，海量G100、MogDB、神州通用資料庫等則都是基於openGauss開源專案的閉源商用資料庫。不少朋友和我討論過這些基於開源專案的閉源商用國產資料庫產品，認為這種套殼國產化產品不能算是真正的國產資料庫。對於這個問題，可能大家的觀點很難一致。我還是比較贊成基於開源專案構建商用產品的，因為這樣可以大大減少研發的開銷，另外也可以利用壯大開源社群，充分整合開源社群的資源。只要產品對於開源協議是遵循的，不違反開源協議的前提下做閉源，是沒有問題的。當然，如果能夠像openGauss等國產開源專案一樣，一方面脫離國外開源社群，另外一方面釋出開源版本，那就更好了。如果一個資料庫既有商用版本，又有開源版本，那麼既可以解決企業大規模使用的成本問題，又可以為企業的核心應用託底，這解決了很多大型企業資料庫替代的一個大問題了。

除了商業路線以外，還有一個十分重要的選項是集中式資料庫與分散式資料庫。集中式資料庫使用、運維起來很簡單，不過可擴充套件性、高可用方不如分散式資料庫。分散式資料庫高可擴充套件，容錯能力強，但是結構複雜，運維複雜，出了問題也不好定位。這二者優缺點都十分明顯，確實不好選擇。實際上還存在第三種路線，就是亞馬遜發明的Aurora，這種日誌就是資料庫理念的產品可以實現強一致性的讀寫分離，因此很多情況下被算成是非對稱架構的分散式資料庫，而實際上這是一種介於集中式資料庫與分散式資料庫之間的架構(實際上Oracle RAC也可以近似歸類於這種型別)，今天我們把它看做第三種技術路線。

集中式與分散式資料庫的選擇依然取決於企業的應用場景、應用目標與企業IT的能力積累。集中式資料庫相對簡單，對於應用開發與運維來說，只要做好高可用架構、主備庫等，可用性也是有保障的。最嚴重情況下，確保30分鐘內恢復應用也是有保障的。

不過依然存在一些應用場景需要更高的可靠性，比如股票交易、實時系統等，這種系統在企業中雖然數量不是很大，但是往往又是最為核心的。如果需要分鐘級恢復應用，那麼分散式資料庫在架構上更具優勢。而對於網際網路交易、物聯網應用等業務邏輯相對簡單，高併發資料寫入，大批次資料輸出等場景，分散式資料庫也因為其極高的可擴充套件性而更為適合。

我想在一個企業中，很可能是集中式資料庫用於廣泛的，中小型的或者規模相對穩定的系統使用相對簡單的集中式資料庫，而可用性要求極高、超高併發的少量系統使用分散式資料庫很可能是一種十分常見的形態。

第三類資料庫目前在國產資料庫中還比較少，最為典型的是阿里的PolarDB-PG、PolarDB-O，這是基於Postgresql開源專案的非對稱分散式架構資料庫產品。透過底層多副本實現IO能力的擴充套件，透過讀寫分離叢集實現有限的橫向擴充套件。實際上目前的絕大多數國產集中時間資料庫產品都可以研發類似的衍生產品。我瞭解到很多國產集中式資料庫廠商都在開發類似Oracle RAC的產品，而達夢的類似RAC功能的資料庫產品已經開始商用了。不過我依然覺得類似PolarDB的非對稱讀寫分離架構對於絕大多數企業來說已經夠用了。既可以透過讀寫分離分離開銷最大的讀負載，又可以實現亞分鐘級別的高可用故障切換，完全能夠滿足高可用性要求的核心繫統的需求了。一個集中式資料庫產品如果能夠具有此種能力，並且在前端透過代理實現讀負載的自動解除安裝，那麼對於80%以上是讀負載的絕大多數管理資訊系統來說，就完全解決了單機無法擴充套件的問題。集中式資料庫廠商可以憑藉此能力與分散式資料庫爭奪核心業務的市場。

分散式資料庫廠商也可以把手伸進集中式資料庫廠商的碗裡，今年OceanBase 4.0的釋出會上給了資料庫產業界一個新的啟示，分散式資料庫還可以有新的玩法。OB 4.0釋出了一個單機資料庫模式，對於一些企業，資料與業務規模還沒有到必須上分散式資料庫的地步，你可以先上一個單機版的OB，等以後有需求的時候，可以很方便的擴充套件為分散式資料庫。這樣企業的大小資料庫都可以使用相同的資料庫產品，根據需要選擇集中式還是分散式。OB 4.0釋出的時候，有個資料庫廠商的朋友看到這個訊息後和我說：“這下子不好玩了，如果OB單機模式確實如宣傳所講，能達到這樣的效能，那麼這算是降維打擊了”。能不能降維打擊還不好說，因為要想把一個分散式資料庫架構的資料庫產品改造為一個單機集中式資料庫，而且效能能夠與普通的集中式資料庫相媲美，並不是一件容易事。真實的情況如何，還需要實際應用來證明。

資料庫選型是一個十分複雜的過程，很難透過一些規則進行量化，透過量化打分來完成資料庫選型看似很科學，實際上並不一定能夠做出很好的選擇來。資料庫選型應該是從企業的特點出發的，不僅僅要看資料庫本身的技術先進性，企業自身的技術特點，技術能力以及企業在資料庫、研發等方面的投資配比等都會影響資料庫選型的最終結果。今天時間有限，我就不再展開討論了，如果大家有興趣，我今後專門來討論這方面的問題。

最後聊聊資料庫的對比測試與評價問題，這個也是困擾企業資料庫選型的一個問題。任何的測試都無法做到完全公正，因此透過測試實現選型的公正並不一定能夠做到，也並不一定必須。我們要做到的是，被選中的資料庫真的能夠滿足我們的日常應用需求。從我的經驗上看，BENCHMARK測試，TPCC之類的對於絕大多數企業的資料庫選型來說沒有太大的意義。僅僅從簡單的TPCC來說，20萬TPMC基本上可以滿足絕大多數企業的併發交易需求了，但是BENCHMARK這種簡單的測試，無法測出企業對複雜SQL的支撐能力的好壞，因此意義不大。對於企業資料庫替代測試中比較重要的測試專案包含資料庫相容性測試、複雜SQL支援能力與效能測試、高可用測試等。

資料庫相容性測試主要是和Oracle比，大部分企業將從Oracle大量遷移系統到國產資料庫上。相容性意味著遷移成本的高低。如果應用能夠修改少量的程式碼，甚至不修改一行程式碼就能夠實現遷移，那麼對於有數百套甚至上千套系統需要遷移的企業來說，可以節約大量的成本。在這方面，達夢是真正的王者，以我們這些年做過的遷移來看，達夢資料庫與Oracle的語法相容性是最好的。在這方面國產商用資料庫普遍要好於開源資料庫，海量G100、人大金倉、OCEANBSE(Oracle相容租戶模式)等在與Oracle的SQL、PL/SQL相容性方面都做的不錯。

複雜SQL的測試最好選擇一些比較複雜的系統進行，比如ERP系統、SCM供應鏈管理系統等，這些系統的業務邏輯十分複雜，大量的多張大表關聯，大資料量輸出的場景比較多，因此可以檢驗一個資料庫產品對於複雜SQL的處理能力與執行效能。如果某個資料庫能夠比較好的支撐這些應用，那麼其SQL能力就完全能夠滿足你其他系統的需求了。有些朋友會說，如果用資料倉儲的應用來測試不是更能體現複雜SQL的能力嗎?實際上過猶不及，OLAP不僅僅是SQL的問題，還有寬表最佳化、列儲存、索引最佳化等方面的需求，與OLTP系統中的複雜SQL是不同的。

資料庫國產化替代涉及的問題太多，我也無法透過一個五六千字的文章一網打盡。今天就聊這麼多吧，早上六點多就開始寫這篇文字，邊想邊寫，可能比較亂，某些地方也可能會有些疏漏，而且僅僅是一家觀點，未必正確，也未必與您的需求相一致，有不同的觀點，希望多交流。今後我會找個時間，認真梳理下這篇文章，找時間再發一個更好的版本把。希望今天的文字能夠對正在做這項工作，或者正在思考這個問題的朋友有所幫助。