企業傳統資料庫遷移到國產或開源資料庫的六個重要階段
韩锋频道 twt企业IT社区
【導讀】越來越多的企業正面臨將傳統資料庫遷移到開源或新型商業產品上，本文整理了在此過程中，困擾企業的一些常見問題，結合整個遷移過程中的六個階段進行說明， 這是一篇優秀的實用文章。 希望對讀者在資料庫選用及評估資料庫遷移風險等方面有所啟發。
【作者】韓鋒，CCIA（中國電腦協會）常務理事，前Oracle ACE，騰訊TVP，阿里雲MVP，dbaplus等多家社群創辦人或專家團成員。 有著豐富的一線資料庫架構、軟體研發、產品設計、團隊管理經驗。 曾擔任多家公司首席DBA、資料庫架構師等職。 在雲端、電商、金融、網際網路等產業均有涉獵，精通多種關聯式資料庫，對NoSQL及大數據相關技術也有涉獵，實務經驗豐富。 曾著有資料庫相關著作《SQL優化最佳實務》、《資料庫高效優化》。
隨著近年來資料庫的變化，正有越來越多的企業面臨將傳統資料庫遷移到開源或新型商業產品。 在這過程中，會面臨諸多問題。 這裡就將常見的一些問題整理出來，希望能夠在資料庫選型及評估資料庫遷移風險等方面有所幫助。 為了描述清晰，我將整個遷移過程劃分為幾個階段，其中橙色標識工作為資料庫團隊來支援。 以下將就每個階段，詳細展開說明。
1. 階段：遷移準備
1) . 遷移規劃
在進行遷移之初，首先要對遷移工作做個整體規劃，並制定好對應的原則方針。 例如明確遷移範圍、遷移方式、是否可停機、窗口期等等。 這些資訊是作為後續遷移的指導原則，遷移方案的發展很多需依靠這項規劃。 要避免出現快要遷移，發現預期不符合要求的狀況，提前做好必要的規劃。 此外，除技術因素外，其他如組織、管理、資源等，也在此階段一併考慮。 遷移是個很複雜的過程，涉及的各個面向很多，盡量在專案之初就有個全面的掌握。
2) . 業務梳理
要完成資料庫遷移，上層的業務系統也是需要考慮的，甚至在某種程度講，配套的應用遷移更加重要，在後續的遷移過程中佔比也更高、難度也更大。 因此，在遷移準備階段，就對涉及的業務有個全面的梳理非常有必要。 這裡需要梳理的訊息，非常廣泛。 包括但不限於對業務系統涉及的軟硬體環境、與資料庫互動、業務系統間呼叫關係等。 後續在做應用系統改造規劃中，上述資訊非常重要，其有助於評估工作困難、工作量等。 這裡舉個例子，某系統之前使用Oracle，開發採用C語言，在遷移到某國產庫時發現，資料庫不支援C driver，好不尷尬。
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程式碼散落在應用程式各處，需要統一修改。 如果使用了OR Mapping工具還好，如果有硬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) . 運行優化
遷移後上線運行，運行效率值得關注。 新的資料庫選型，對穩定性運作會帶來一定調整。 作為運作保障的一部分，建立其完整的運作最佳化能力非常必要，包括基本的慢查詢、日誌、栓鎖、會話等診斷工具及對應的處理措施。 這點對於國產庫特別重要，近年來國產資料庫發展迅速，但相較於其核心功能發展，上述週邊管理優化能力發展不足，需事先關注。
4) . 緊急應變
作為最後的保障措施，當出現問題時的緊急應變是需要事先規劃的。 這裡更多是流程製度的設定，保證出現問題時及時感知、及時修復，不影響業務。
Comments
Warning: count(): Parameter must be an array or an object that implements Countable in /var/www/html/wwwroot/itrenzheng.hk/wp-includes/class-wp-comment-query.php on line 399
Tell me what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!