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

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

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

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

當年Oracle數據庫一統江湖，替掉90年代五花八門的數據庫產品，絕大多數企業(yè)也并不是做了很詳細的規(guī)劃，才一點點實施起來的。而且那時候Oracle數據庫也沒有那么好的口碑，在人們的眼中也并不是怎么選都不會錯的產品。很多企業(yè)是不情愿的用了Oracle，發(fā)現Oracle很不錯，以后信息系統上線就全部使用Oracle了。最后，企業(yè)里其他數據庫產品也逐漸在系統升級時換成Oracle了。

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

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

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

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

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

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

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

如果企業(yè)的研發(fā)能力較強，應用系統都已經微服務化了，那么可以把數據庫拆分的比較細小，使用MySQL是十分好的選擇。MySQL的運維十分簡單，業(yè)務邏輯都在應用里做了充分優(yōu)化后，只要在MySQL的高可用架構上做好設計，那么平時的運維是很簡單的，偶然發(fā)生某個庫出問題了，只要重啟數據庫實例或者切換備庫就可以解決問題了。

如果企業(yè)的應用相對復雜，SQL經常會出現數張大表的關聯查詢，而研發(fā)部門的優(yōu)化能力也有限，那么Postgresql可能是你比較好的選擇。PG的優(yōu)化器能力十分強大，可以解決大多數復雜查詢的性能問題。而PG的插件結構也可以讓你通過一些特殊的方式，甚至為某個特殊應用場景開發(fā)特殊的索引來解決一些開源版本無法解決的問題。

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

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

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

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

不過依然存在一些應用場景需要更高的可靠性，比如股票交易、實時系統等，這種系統在企業(yè)中雖然數量不是很大，但是往往又是最為核心的。如果需要分鐘級恢復應用，那么分布式數據庫在架構上更具優(yōu)勢。而對于互聯網交易、物聯網應用等業(yè)務邏輯相對簡單，高并發(fā)數據寫入，大批量數據輸出等場景，分布式數據庫也因為其極高的可擴展性而更為適合。

我想在一個企業(yè)中，很可能是集中式數據庫用于廣泛的，中小型的或者規(guī)模相對穩(wěn)定的系統使用相對簡單的集中式數據庫，而可用性要求極高、超高并發(fā)的少量系統使用分布式數據庫很可能是一種十分常見的形態(tài)。

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

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

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

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

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

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

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