本文轉載自 韓鋒頻道 作者：韓鋒
資料庫遷移，是個老生常談的問題，之前也曾寫過一篇文章。近期，針對這一課題，自己有了些新的思考，下面將具體展開談談。在這之前，我先談談資料庫遷移的現實需求。這也算是目前行業發展的一個小總結。
1。 背景：遷移之源，多變之秋
人生基本上就是兩件事，選題和解題。最好的人生是在每個關鍵點上，既選對題，又解好題。人生最大的痛苦在於解對了題，但選錯了題，而且還不知道自己選錯了題。正如人生最大的遺憾就是，不是你不行，而是你本可以。
❖ 資料規模大幅增加
近些年來，資訊資料呈快速增長態勢。如下圖所示，全球資料量總和，預計將從 2018 年的 33ZB 增至 2025年的 175ZB。國內資料體量在未來 7年將實現複合增速 30%以上的快速增長，並在 2025年成為與歐洲、中東、非洲、亞太和美國等地區相比體量最大的區域。資料的爆發式增長，導致對資料儲存容量、資料計算需求有個更好的要求，這也催生企業在基礎設施層面不斷革新，進而不斷推動資料庫向前進一步發展。
從資料庫市場來看，也驗證了這一趨勢。整體市場呈現穩定的發展趨勢，最近的資料表明，國內的資料庫市場已經達到200億規模。
❖ 開源方案，大行其道
開源資料庫，其原始碼具備全球共享、免費等特點，開發者可在其原始碼中修改或使用。在近一、二十年來，越來越多的企業將開源方案作為構建底層支援的可選答案。特別是隨著網際網路的興起，大量網際網路企業選擇使用了開源資料庫產品，也加速這些產品的成熟與發展。這其中MySQL、PostgreSQL、MongoDB 和 Redis 是當前開源資料庫最為重要的參與者。
❖ 資料上雲，大勢所趨
從2017至 2018年，整個資料庫市場增長了 18。4%，其中雲資料庫增長貢獻 68%。以AWS、Microsoft、Alibaba為代表的雲廠商，取得了快速發展，極大地重塑了全球供應商格局。國內網際網路科技巨頭，紛紛佈局資料庫產業，借力雲計算實現資料庫等基礎軟體領域的迭代與超越。如下圖的資料庫規模排名，雲資料庫廠商均取得不俗的增長，最新資料則更是如此。甚至有機構預測，今明兩年從資料庫部署形態上看，雲部署資料庫會超過傳統部署方式。
❖ 國產化趨勢明顯
正如下圖所示，國內資料庫市場仍然為歐美壟斷，但國產化趨勢已非常明顯。以國產自研或開源定製路線的廠商層出不求，從最新的調查結果來看，已經有130+的國產資料庫廠商初選。
從一葉扁舟到百舸爭流，傳統國產資料庫歷經長時間艱難探索，已逐步嶄露頭角。國外大廠長期壟斷國內資料庫市場。Oracle、IBM 和 Microsoft 等老牌廠商憑藉先發優勢在市場份額中佔據了有利地位。國產資料庫起步較晚，但潛力巨大。正如下圖可見，國產資料庫佔比正不斷增加。
❖ 總結：多種變化，驅動遷移
綜上所述，從資料規模體量的增大，到開源商業的變化，再到雲化趨勢明顯、國產化趨勢加劇；而這些變化都帶來同一個訴求，那就是資料庫遷移。展開來說，是如何完成異構資料庫遷移？完成體系架構完全不同的資料庫之間的遷移（例如從單機到分散式）？完成從線下到雲上的遷移？完成線上的、不終端業務的遷移？等等。諸多上述問題，對遷移提出了非常高的要求。本文下面嘗試從遷移的多個階段來闡述，需要哪些能力才能完成這一過程。
2。 資料庫遷移之路
人生基本上就是兩件事，選題和解題。最好的人生是在每個關鍵點上，既選對題，又解好題。人生最大的痛苦在於解對了題，但選錯了題，而且還不知道自己選錯了題。正如人生最大的遺憾就是，不是你不行，而是你本可以。
在實際的遷移中，是一個比較複雜的過程，可根據階段做個拆解。
1）。遷移評估階段
此階段是完成遷移前的評估，為後續遷移改造、遷移過程做好鋪墊工作
❖ 資料庫畫像
資料庫畫像結果，可為後續選型評估、架構規劃提供依據。
系統級
收集系統級資訊，包括但不限於硬體（CPU、MEM、NET、DISK）、作業系統（核心、引數、安全策略等）、效能（系統高峰期24小時負載）等
例項級
收集例項級資訊，包括但不限於架構（單機/叢集、版本等）、引數（資料庫引數等）、資料規模（表、索引等空間使用）、執行態資訊（如QPS、TPS、會話、事務等）
物件級
收集物件級資訊，包括但不限於結構資訊（表、分割槽、分片、索引、檢視、序列等）、統計資訊、訪問特徵（讀寫比、頻率等）、預警類（如大表、複雜結構、DBLink等）
語句級
收集語句級資訊，包括但不限於SQL文字（全量）、執行特徵（次數、響應時間等）、執行計劃。
應用級
收集複雜應用資訊，包括但不限於計算文字（如儲存過程、觸發器、函式等）、 執行特徵（次數、響應時間等）
❖ 應用畫像
應用畫像結果，為後面應用改造做好鋪墊。
應用拓撲
收集應用架構、應用與DB關係、應用訪問特徵等。
❖ 風險評估
針對上面收集的資料庫、應用畫像資訊，針對重點風險點做出評估。
資料庫架構
源庫使用叢集、分庫分表等架構，做出提示。
資料庫結構
源庫使用複雜結構（如分割槽表）、不支援結構（LOB、可更新檢視等），做出提示。
資料庫語句
源庫使用複雜SQL（如多表關聯）、特殊語法或方言等給出提示。
資料庫應用邏輯
源庫大量使用儲存過程、觸發器、函式等。
應用架構
應用使用何種訪問方式（如java、c、go等），對於某些舊有的方式予以提示。
效能維度
源庫存在明顯的效能訪問高峰，明顯的熱點物件。
規模維度
源端資料庫總體或單體物件規模較大的情況。
❖ 選型建議
根據上面收集資訊及風險評估內容，給出選型的建議。這裡存在幾個難點，一個是多目標資料庫的基礎能力抽象，一個是兩者的適配評估。功能上包括兩部分：
目標端建模
目標端在架構、結構、應用、效能指標等方面的基礎抽象。
評估適配建議
根據源端和目標端情況，結合風險及效能要求給出適配選型建議。
2）。遷移改造階段
❖ 物件改造
這一階段主要是透過結構對映及不相容提示，來減少改造工作量。
對映規範
適配多目標端給出結構對映規範。
結構改造
基於給定輸入，輸出改造後結構。可能存在非一一對應的情況，可根據源與目標的差異，異構改造。
不相容提示
對於不相容的情況，給出文字提示，人工介入。
❖ 語句改造
這一階段主要透過語句改寫，減少改造工作量；同時提供增強功能，滿足語句改造後的測試等需求。
SQL改造
基於給定輸入，給出改造後的語法。
不相容提示
對於不相容的情況，給出文字提示，人工介入。
增強-執行計劃對比
可對比兩邊執行計劃，方便研發最佳化語句寫法。
增強-效能對比
可對比兩邊執行效率，方便研發最佳化。此處需保證同等測試環境。
增強-SQL自主最佳化
提供最佳化改寫能力，而非基於簡單規則。此處需注意，語義等價性問題。
❖ 應用改造
此處應用是指資料內建的計算能力（如儲存過程等）。這一階段主要是透過邏輯改寫，減少人工工作量。在實現上，一般建議使用外部程式邏輯（如java）進行處理，而不是改造為目標端內部計算應用。原因是儘量減少資料庫耦合。此處，存在較多難點，且需要人工檢查改造後的語義是否正確。
應用改造
基於給定輸入，給出改造後的實現（推薦java）。
不相容提示
對於不相容的情況，給出文字提示，人工介入。
應用校驗
對比兩側的實現，驗證處理邏輯是否一致。
3）。遷移資料階段
❖ 全量/增量資料遷移
完成異構資料庫間的資料遷移工作。主要難點是效率、準確性。
全量遷移
增量資料遷移
基於指定時間戳後的增量遷移能力
增強-分拆、合併能力
支援一拆多，多合一遷移能力。
增強-遷移計算能力
支援在遷移實時計算能力（如lookup）。
增強-通用異構適配能力
統一遷移能力，不依賴某種庫。
增強-提供可配置UI
提供可配置同步介面，簡化操作。
增強-資料轉換能力
提供字符集、時區等轉換能力。
❖ 資料對比
見後面說明
4）。線上執行階段
❖ 資料同步
線上執行時，需提供資料庫端的異構同步能力，滿足業務隨時回遷的需求。
實時同步
提供異構資料庫間資料實時同步能力，難點在於大吞吐、實時性。
增強-細粒度同步
支援庫、使用者、表同步能力。
增強-同步計算能力
支援在同步的實時計算能力（如lookup） ，難點在於效率。
❖ 資料對比
資料對比，是使用者對比雙線執行的基本要求，需要滿足實時對比並兼顧效率。
異構對比
提供異構資料來源之間全量、增量資料對比能力。
增強-細粒度對比
支援庫、使用者、表、記錄級別對比能力。
增強-資料補差
提供差異資料的雙向補齊能力。
❖ 資料路由
資料路由，為業務提供統一資料庫訪問入口，並基於此提供雙路控制能力，可做到按流量、按讀寫、按訪問類別（生產、測試）等做資料訪問路由。
❖ 基礎運維
此部分的能力比較多，本質就是同時提供異構資料庫線上同步運維能力。例如包括統一變更、統一匯入匯出、統一授權、統一審計等。儘量從運維側角度來看，後面是一套邏輯庫。