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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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