資料庫是平替還是改造？

早上走路30多分鐘到公司的時候發現膝上型電腦沒帶是一件很崩潰的事情，騎上共享單車跑了一趟，回到公司已經八點多了。看來週一早上要帶電腦上班這個事情還沒有形成肌肉記憶，這種事情對於已經開始健忘的年齡來說，很可能以後經常會發生。

上週五我發了一篇10年前子衿最佳化團隊的階段測試題，有些朋友希望我公佈答案。不過今天有些更想說的事情，因此公佈答案的文章還是稍後再寫吧。週五參加了ITPUB的一個關於信創替代的線上沙龍。其中討論的一個問題是信創替代，平替還是改造的問題。對於資料庫而言，我正好看到過一些相關的案例，因此發表了一些觀點。不過因為時間關係，並沒有把我想表達的所有觀點都表達出來，因此今天我想先把這一切都寫下來，否則有些思考會被我的記憶淡忘。

對於資料庫而言，信創替代中的平替是指選取與Oracle等需要替代的資料庫相容度較高的產品，在不對應用系統做較大改造的前提下實現替代;而改造則根據國產資料庫的特點，對應用系統做較大的針對性改造，實現資料庫國產化替代。就這兩種替代方案而言，改造替代肯定是成本相對較高的模式。因此國產資料庫廠商一般建議先平替遷移，然後再做少量的最佳化改造，實際上這種模式就是我所說的平臺模式。因為其成本相對較低，替代速度較快，因此也比較受到使用者的青睞。

為了看清楚二者的優缺點，我先介紹一個某行業核心系統替代的案例。這個案例來自於兩個業務基本相似的不同企業。這套系統是企業最為核心的系統，複雜度也比較高，存在大量的複雜業務邏輯的SQL，資料量也相當巨大。

在這個案例中，一個企業採用平替模式，把原來在Oracle跑的應用直接遷移到與Oracle有較高相容性的分散式資料庫上，然後針對某些不相容特性與效能存在問題的SQL語句進行了比較周密的改寫與最佳化。系統上線也比較順利，不過上線一段時間後，遇到了一些偶發性的效能與系統卡頓的問題。被迫先暫時回切到Oracle系統，然後再去定位問題，解決問題後再做切換。

另外一個企業則認為他們選擇的國產資料庫在功能、效能、Oracle相容性方面都存在一定的問題，因此決定在遷移過程中多花點時間，多花點錢，一次性完成改造切換。雖然改造週期比第一家企業要長一些，不過透過這次改造，把一些以前系統設計不合理，完全依靠Oracle強大的能力硬扛的系統功能點都改造完了。因此係統上線後相對穩定，哪怕出現一些問題也可以很快解決掉。

我想採用這兩種方式進行改造遷移，最終都能夠解決遇到的問題，完成遷移。不過對於複雜的關鍵性業務系統而言，簡單的平替似乎並不是一個特別靠譜的方案。從Oracle平替遷移過來的應用往往存在大量的問題，放到沒有Oracle穩定與強大的國產資料庫上，可能會留下太多的隱患。

我上面所說的是複雜、大型、關鍵的業務系統，在這方面企業往往可以投入較大的資金去做改造，因此改造替換比簡單平替要更好一些。不過對於海量的小型的、業務不那麼複雜的系統而言，都採用深度改造的替代方法恐怕對企業的投資來說過於巨大。因此這些系統採用平替的方案可能更為務實一些。這是目前客戶希望國產資料庫做各種相容性的主要原因。

似乎這個問題已經講清楚了，其實不然，哪怕是改造替代，也要注意一些問題。有人可能會說，既然都改造替代了，那麼讓應用去適應國產資料庫就可以了，資料庫選型可以隨意一些了。

其實不然，我還是先講一個案例。有家企業做國產資料庫替代，為了節約資金，學習網際網路企業的先進經驗，選擇了一個基於MySQL的分庫分表的方案，將整個系統拆分成了幾十個幾個MySQL資料庫。不過因為研發隊伍能力與研發進度要求等問題，對於讀寫分離，歷史資料分離等都沒在開始時候做上。甚至有些複雜業務對於只習慣寫SQL完成業務邏輯的研發人員來說也十分困難。為了實現業務，在這些庫之間還設定了大量的廣播表，用以複製那些有共享資料需求的應用。系統上線後，隨著資料量的增長，系統出現的問題也越來越嚴重，很快就脫離了研發團隊技術能力。

這個案例可以看出信創替代中的另外一個問題，那就是企業在選型資料庫與解決方案的時候，一定要選擇研發與運維隊伍能夠把控的技術路線。沒有網際網路企業的技術能力的，就不要輕易學習人家的分庫分表;沒有分散式資料庫研發與應用經驗的企業，就老老實實用集中式資料庫。

信創替代，說難很難，說容易也容易，不過做之前根據自己的能力特點，選擇適當的方案還是十分關鍵的。現在對信創這個話題，有各種觀點。我覺得每種觀點都有一定的道理。不過對於某些企業或者行業，這個工作已經是必須做的事情了，那麼就去做好了。資料庫替代這個事情，想想都是問題，不過咬牙做下去，似乎都能找到答案。