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

五月 3, 2024 by
Filed under: killtest 

韩锋频道 twt企业IT社区
【導讀】越來越多的企業正面臨將傳統資料庫遷移到開源或新型商業產品上,本文整理了在此過程中,困擾企業的一些常見問題,結合整個遷移過程中的六個階段進行說明, 這是一篇優秀的實用文章。 希望對讀者在資料庫選用及評估資料庫遷移風險等方面有所啟發。
【作者】韓鋒,CCIA(中國電腦協會)常務理事,前Oracle ACE,騰訊TVP,阿里雲MVP,dbaplus等多家社群創辦人或專家團成員。 有著豐富的一線資料庫架構、軟體研發、產品設計、團隊管理經驗。 曾擔任多家公司首席DBA、資料庫架構師等職。 在雲端、電商、金融、網際網路等產業均有涉獵,精通多種關聯式資料庫,對NoSQL及大數據相關技術也有涉獵,實務經驗豐富。 曾著有資料庫相關著作《SQL優化最佳實務》、《資料庫高效優化》。

隨著近年來資料庫的變化,正有越來越多的企業面臨將傳統資料庫遷移到開源或新型商業產品。 在這過程中,會面臨諸多問題。 這裡就將常見的一些問題整理出來,希望能夠在資料庫選型及評估資料庫遷移風險等方面有所幫助。 為了描述清晰,我將整個遷移過程劃分為幾個階段,其中橙色標識工作為資料庫團隊來支援。 以下將就每個階段,詳細展開說明。
640 (1)
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

Tell me what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!





*