企業從傳統數據庫遷移到國產或開源數據庫的六個重要階段

【導讀】越來越多的企業正面臨將傳統數據庫遷移到開源或新型商業產品上，本文整理了在此過程中，困擾企業的一些常見問題，結合整個遷移過程中的六個階段進行說明，這是一篇優秀的實用文章。希望對讀者在數據庫選型及評估數據庫遷移風險等方面有所啟發。隨著近些年來數據庫的變化，正有越來越多的企業面臨將傳統數據庫遷移到開源或新型商業產品上。在這一過程中，會面臨諸多問題。這里就將常見的一些問題整理出來，希望能夠在數據庫選型及評估數據庫遷移風險等方面有所幫助。為了描述清晰，我將整個遷移過程劃分為幾個階段，其中橙色標識工作為數據庫團隊來支持。下面將就每個階段，詳細展開說明。

1.階段：遷移準備1)

.

遷移規劃在進行遷移之初，首先要對遷移工作做個整體規劃，制定好對應的原則方針。例如明確遷移范圍、遷移方式、是否可停機、窗口期等等。這些信息是作為后續遷移的指導性原則，遷移方案的制定很多需依靠這一規劃。要避免出現快要遷移，發現預期不符合要求的情況，在提前做好必要的規劃。此外，除技術因素外，其他如組織、管理、資源等，也在這一階段一并考慮。遷移是個很復雜的過程，涉及的方方面面很多，盡量在項目之初就有個全面的掌握。2)

.

業務梳理要完成數據庫遷移，上層的業務系統也是需要考慮的，甚至在某種程度講，配套的應用遷移更加重要，在后續的遷移過程中占比也更高、難度也更大。因此，在遷移準備階段，就對涉及的業務有個全面的梳理非常有必要。這里需要梳理的信息，非常寬泛。包括但不限于對業務系統涉及的軟硬件環境、與數據庫交互、業務系統間調用關系等。后續在做應用系統改造規劃中，上述信息非常重要，其有助于評估工作難點、工作量等。這里舉個例子，某系統之前使用Oracle，開發采用C語言，在遷移到某國產庫時發現，數據庫不支持Cdriver，好不尷尬。3)

.

方案選型在做好業務梳理后，就是數據庫選型。這一過程也是遷移準備階段比較耗時的一個工作。如何從眾多的數據庫產品中選擇一款符合自己要求的，要考慮的因素很多。比較推薦的做法，是在公司內部之前就制定出推薦的方案矩陣，根據對數據庫能力要求、系統重要程度等，制定一個產品選型矩陣。如果前期有這個基礎，就比較簡單，只要按圖索驥即可。如果沒有的話，需要從頭完成一系列的工作，包括初始調研、技術評估、數據庫評測（功能、非功能、業務等）、適配性評估等。這里強調一個原則就是盡量在方案選型中保持最大的自由度，即不綁定單一廠商，隨時保持可替換能力。因此在方案選型中，不能本著業務少改造、遷移最簡單、成本最低的方案，而是應選擇長期可替代的原則。推薦的做法是選擇兼容通用協議的產品，盡量弱化數據庫端能力，選擇使用標準數據庫功能的產品最好。4)

.

技術培訓在方案選擇完畢后，需進行技術培訓。這里說的培訓，包含對研發、運維等多方面。對研發人員的培訓，著重闡述此數據庫在架構設計、結構優化、SQL語句等方面與原有數據庫的差異。如選擇通用性產品，則此處的工作較少，也就是方便進行其他庫間的遷移。這里面有個原則就是不遷就研發，該做的必要修改還是要修改。例如，在很多去O工作中，為了盡量減少遷移工作，很多項目選擇兼容Oracle語法、甚至存儲過程的產品。此類產品確實減少了遷移工作量，但從長遠角度來看并不是一個很好的選擇。對運維的培訓，則側重如何將這種新的數據庫融入到現有的運維體系中。特別是當前很多分布式架構數據庫，與傳統集中式數據庫不同，其對于運維帶來的挑戰也更大。2.階段：遷移評估1)

.

資源評估做好準備工作后，開始啟動之前，根據之前梳理的業務情況、所做的數據庫選型等信息，開始做必要的評估工作。這里的評估主要是為了后續遷移改造做好準備。首當其沖的就是資源評估，即完成上述遷移所需資源。這里有個隱藏的工作，就是相關的技術方案需要制定出來，包括數據庫及應用端的。畢竟數據庫能力不是一對一對等的，因此架構上會有很多調整甚至是重構。但這里所做的評估，相對還是比較粗的，因為很難對資源消耗有個細粒度的描述，做后者的前提是有完整的評測數據為基礎。為什么在這個階段就要做此工作呢？主要是因為很多傳統企業是采用預算制，需要提前很長周期做好后續的采購規劃。因此將資源評估工作做了前置。2)

.

應用評估在這個階段要完成在數據庫選型確定后，應用的評估工作。包括應用方案的調整（甚至重構）、應用的代碼修改量、可能潛在的風險等等。這里主要是由應用架構師來完成上述評估。3)

.

對象評估完成應用評估后，下面就是數據庫評估的。其評估的第一項就是對象評估，即對數據結構的評估。數據庫的能力層次不齊，原有的數據結構大概率都無法直接復用了，需要進行必要的調整甚至重新設計。這里有個建議，就是盡量減少數據庫端復雜對象的使用，盡量只考慮表及索引的設計，其余包括視圖、序列、觸發器、存儲過程、函數、包等都通過外部的等價設計來完成。這點主要是出于減少對數據庫的依賴所提出的，畢竟后面這個功能的實現差距非常大。當然，隨之帶來的外部等價實現的工作量也需要進行評估。此外，如果是分布式數據庫方案，還需要考慮例如分片策略等。這里有個常見的通病，就是將原有設計原封不動地在新環境中落地，然后修改語法不兼容的部分就算是完成這一過程。其帶來的后果，往往是上線后問題頻出。4)

.

SQL評估對象評估之后，開始對SQL語句的評估。較之前的經驗，這部分也是較難評估的。比較推薦的做法是抓取源端的全量SQL，根據掌握的目標庫的適配能力，做此評估工作。例如之前在去O的工作中，就從下面幾個維度來評估SQL，包括了SQL復雜度（多表關聯、文本過長等）、Oracle方言語法、特有語法（函數、偽列等）等。這些評估出的SQL，后續都將作為后續修改的依據。這里存在一個難點，就是兩種數據庫有相同SQL，但處理效果是有差異的情況，這些可能導致非預期的行為，也最好篩選出來。上述可通過簡單工具掃描SQL文本完成，例如我之前分享的一個小工具。3.階段：遷移改造1)

.

對象改造對象改造，對數據對象進行改造。有些對象僅做簡單的映射修改就可以了，有些則需要大的重構，甚至需要拆分、組合處理。很多對象（特別是復雜對象或重計算類對象），建議從數據庫端剝離，在上層等價實現。因此對象改造工作，不僅僅是DBA的工作，也有部分是需要應用研發參與的。針對上述修改工作，特別是一些關鍵業務表，是需要通過一定手段進行驗證測試的。2)

.

SQL改造SQL改造，往往是在整個遷移過程中，最為浩大的工作。這主要是由于SQL代碼散落在應用各處，需要統一修改。如果使用了ORMapping工具還好，如果有硬code，改起來還是挺吃力的。目前有很多工具（包括開源的），通過指定源和目標庫，輸入SQL語句協助完成改造工作。但這種方式，往往也僅僅起到輔助作用，轉換后的結果還是需要人工的審核修改工作。要保證語義等價，也要保證執行效率等等。3)

.

應用改造配合遷移工作，應用也存在改造的工作量。例如有些在數據庫端實現的邏輯，是需要改在應用端實現的；有些應用本身在新數據庫架構下就需要進行適配性改造等等。4).功能測試在數據庫改造（對象+SQL）和應用改造均完成后，還需要一個關鍵步驟—功能測試。按業務功能拆分，針對每個獨立功能，從應用側角度進行測試驗證，來保證上述改造的結果是正確的，性能是符合預期的。此處的功能測試，與后面的上線交割的功能測試不同，更強調是以小的應用單元為測試目標。這樣便于隨時修改，隨時測試。4.階段：遷移數據1)

.

遷移方案改造工作完成后，就進入了遷移數據環節。在遷移之初，最先確定的是遷移方案，這主要取決于對源目標端的數據庫、物理環境、遷移窗口、是否并行、是否回退等諸多因素。在大的方面可分為應用側同步、數據庫側同步、存儲側同步三種方式，各有優勢點吧。個人建議，如果能在應用側處理，盡量在應用側；其主要原因是與業務結合緊密、同步驗證容易、方便并行回退等等。但這種方案的缺點在于，需要應用側有大量修改工作，無法形成統一標準的方案。一般針對核心、重要的系統，建議采取應用側同步的方式。針對數據庫、存儲端同步方案，一般都是較為通用的方案。下文重點講述數據庫同步的方式。2)

.

結構遷移結構遷移，是將數據結構的遷移。一般這一過程是可以提前完成的。數據結構確定后，即可完成這一過程。不與后面數據同步放在一起，是為了便于出現問題時的排查分析。3)

.

全量遷移如數據規模很大，可將整個過程劃分為全量+增量遷移兩部分。全量同步，一般是可離線、靜態去做，通過備份恢復、導入導出等方式，將絕大部分數據遷移過去。這部分不放在停機窗口中，可提前進行。并在遷移之后，記錄一個位點。4)

.

增量遷移增量遷移，從全量遷移記錄位點開始。根據遷移技術本身，可采取停機或不停機的方式。一般都是通過追log的方式，逐步追齊數據，并短時靜默應用，完成數據最終達到一致的狀態。5.階段：上線交割1)

.

SQL審核在上線交割之前，還需要完成部分前置工作。SQL審核，是為了保證SQL上線前的運行質量。SQL審核細分，可分為事前、事中、事后審核，這里更多指事前審核部分。即在開發過程中，針對SQL運行情況給予評估判斷，來保證上線后的質量可控。一般是通過預定義一組規則，完成對語句的審核。這一過程貫穿在整個開發過程中。2)

.

數據校驗數據遷移后，在上線前還需要對數據同步后的質量有所判斷，這就引入數據校驗的初衷。嚴格來講，這是數據質量保證的一部分。其作用是對同步兩邊的數據是否一致做出判斷，來整體把握同步質量，也是為后面是否正式切換的判斷依據之一。這里存在幾個難點，一是海量數據如何快速比對，二是異構條件下數據如何比對，三是兩側數據同步變化時如何比對？目前已經有些產品能夠支持較為完整的數據校驗功能。個人也是比較建議，在數據遷移后進行對比。雖然這里有些成本，但要比運行一段時間后發現差異而無法回退好的多。3).功能測試在正式遷移前，針對遷移后的全量環境做完成的業務功能測試是非常必要的。需要對遷移后的結果有個全局的掌握。一方面可以驗證整個遷移過程是否OK，另一方面也可為后續正式遷移提供基線判斷標準。4).性能測試在功能測試的同時，還需保證遷移后的性能滿足預期設定，因此性能測試也必不可少。這里可以使用數據庫側進行性能測試，但更建議是從應用側完成性能測試，因為后者是從用戶視角，更具有說服力。6.階段：運行保障1)

.

數據庫運維遷移完成，系統上線后就進入到運行保障階段。從數據庫來說，提供的基本能力之一就是基于新數據庫架構下的運維能力。對于一個新的選型來說，需要將新品種數據庫納入到整體的運維體系中，這其中涉及的工作不少。一般是需要提前規劃完成的。2).高可用保障除了日常運維外，高可用被獨立出來，主要是這部分重要性很高。新的數據庫選型，代表著運行風險更高，如何保證高可用值得關注。一般是建議提前規劃好高可用方案（而不是上線后），并進行周全的高可用切換測試。甚至上線后，可應保證一定頻率的切換演練，做到有備無患。3).運行優化