技術遷移策略完整指南：（第 3 部分 - 數據庫遷移）

已發表: 2020-12-25

想像一個場景，你買了一套新公寓，你們都準備好搬進去了，並且已經仔細計劃了整個過程。你們都準備好搬到新家了，然後你突然意識到——有一個問題。家具和手工藝品不適合您的新公寓。

如果您不得不傾倒所有家具並從頭開始，您會有什麼感覺？更進一步，將新公寓視為您的新數據庫，將家具視為數據。我們確信，對於您的業務而言，數據將比家具重要得多，因此您希望在計劃遷移時保留數據的每一點。

作為我們技術遷移系列的後續，在這篇博客中，我們將嘗試揭示數據庫遷移（DBM）的基礎知識，在執行數據庫遷移時應該理解、考慮和注意什麼。

為什麼以及何時需要數據庫遷移？

作為我們之前的應用程序遷移博客的後續，今天的文章以數據庫遷移（也稱為模式遷移）為中心，因為它是最重要的遷移之一，主要處理從一個數據庫框架選擇、提取、傳輸/更新數據到其他。

從本質上講，數據庫遷移的需求可以特定於業務需求，甚至可以滿足各種監管機構制定的最新多項監管政策。雖然沒有明確需要 DBM 的情況，但我們列出了一些不可避免的情況：

一個常見的原因是將您過時的系統遷移到滿足您的業務需求和現代數據需求的系統。新的現代存儲技術已成為大數據時代的必需品。
某些監管機構已強制要求數據僅保留在特定地理區域。因此，必須將分佈式數據遷移到單個位置。
一些公司更喜歡將本地數據庫遷移到雲數據庫。這通常可以節省支持數據所需的基礎設施和專業知識資源，並使系統更快。
遷移到新平台可確保全面的數據完整性。它降低了存儲和媒體成本，從而顯著提高了投資回報率。
許多現代公司希望將所有數據保存在一個地方。這樣，公司的所有部門都可以訪問數據。

將數據庫系統遷移到新平台可減少日常業務運營的中斷。如果明智地選擇新的數據庫平台，這可以用最少的人工操作來完成。

數據庫類型

在進行數據庫遷移之前，我們先來看看不同類型的數據庫：

關係數據庫——關係數據庫被稱為數據庫行業的主力軍。這些數據庫按一組表分類。表由行和列組成，其中行包含數據實例，列包含特定類別的數據條目。 SQL – 結構化查詢語言是關係數據庫的標準編程接口。
分佈式數據庫——顧名思義，數據分佈在任何組織的各個站點。通信鏈接用於將站點彼此連接起來。這有助於輕鬆訪問分佈式數據庫。
面向對象的數據庫——這種類型的數據庫融合了關係數據庫和麵向對象編程的屬性。用 C++ 和 Java 創建的各種項目可以存儲在關係數據庫中，但是面向對象的數據庫更適合它們。
NoSQL 數據庫——NoSQL 數據庫可以有效地分析存儲在多個虛擬服務器上的大型非結構化數據。相比之下，關係數據庫無法有效處理一些大數據性能。 NoSQL 數據庫可以輕鬆管理此類情況，並用於大量分佈式數據。
雲數據庫——雲數據庫是一個虛擬環境，可以靈活地按使用付費。用戶只需為適合其需求的帶寬和存儲容量付費。
圖數據庫——簡單來說，圖是節點和邊的集合。圖數據庫包含代表實體的節點，邊描述這些實體之間的關係。它是一種 NoSQL 數據庫，使用圖論來映射、存儲和查詢關係。
集中式數據庫——使用這種類型的數據庫，數據存儲在一個集中的位置。數據庫本質上包含允許用戶從遠程位置訪問數據庫的應用程序。

數據庫遷移的方法

將數據從一個數據庫平台遷移到另一個數據庫平台可能是一項至關重要的任務。如果在 LIVE 環境中計劃遷移，則必須非常謹慎地進行遷移。在繼續進行數據遷移之前，必須選擇一個方便的遷移時間。在將數據傳輸到新數據庫時，實時系統經常會遇到停機時間。
數據庫遷移主要有兩種方式：

大爆炸數據遷移：

這種方法是人們選擇在有限的時間範圍內一次遷移整個數據庫的地方。雖然大爆炸數據遷移看起來不那麼複雜，但它需要足夠的在線網站停機時間。此外，使用這種方法，遷移過程的完全回滾可能不容易實現，以防遷移隨時失敗。

涓流數據遷移

使用這種方法，必須將遷移過程分成更小的塊或階段。幾乎就像一種敏捷的遷移方法，如果一個階段失敗，那麼只需要回滾那個階段，然後重複這個過程。但是，Trickle 數據遷移非常耗時，因此可能會增加項目成本。

不同類型的遷移

關係數據庫到關係數據庫

這種方法是最直接的遷移。有大量可用的工具可以非常有效地執行這種類型的遷移，幾乎 100% 有效。

關係數據庫到非關係數據庫，反之亦然

與上述遷移相比，這種遷移更加困難。由於關係數據庫和非關係數據庫根本不同，它們的遷移可能不是 100% 有效的。從本質上講，遷移到非關係數據庫意味著犧牲 ACID 屬性（原子、一致、隔離和持久），這些屬性保證了數據庫的可伸縮性。
但是，有多種免費工具可以支持從關係數據庫到非關係數據庫的數據庫遷移。儘管不廣泛推薦使用它們，因為這些工具不支持系統的模式結構，而且大多數工具似乎過於僵化而無法適應系統要求。

儘管我們可以為這種類型的遷移提供一些基本的轉換技巧，但我們可以考慮（為方便起見，讓我們將 MySQL 視為我們的關係數據庫，將 MongoDB 視為我們的非關係數據庫）

將 MySQL String 數據類型轉換為 MongoDB 中的 String。這可能包括 char、varchar、blob、text 等。
在 MongoDB 中將 MySQL Numeric 數據類型轉換為 Number。這可能包括 int、float、decimal、double 等。
在 MongoDB 中將 MySQL Date 數據類型轉換為 Date。這可能包括日期、年份、時間戳等。
在 MongoDB 中將 MySQL Bool & Boolean 數據類型轉換為 Boolean。
您可以以相同的方式評估其他案例。

使用混合模型遷移

混合模型設計將兩種流行的數據庫模型集成在一個框架中，同時減輕了每個系統的缺點。例如，我們總是可以採用混合方法，我們可以利用關係數據庫來進行要求不高的操作，結合非關係數據庫來進行數據密集型計劃。

數據備份

在執行之前規劃遷移策略可以確保遷移過程順利進行。話雖如此，我們需要始終有一個 B 計劃。假設最壞的情況是數據丟失，或者數據在執行遷移時損壞；您必須準備好將數據恢復到其原始狀態，然後再重試。這就是為什麼在 DBM（數據庫遷移）期間數據備份是一個非常必要的步驟。那麼，有哪些選項可以確保安全的數據備份，讓我們深入研究一下。

雲備份

保護您的遷移計劃的最有效和最安全的方法之一是執行對雲存儲的備份。本質上，當您將數據備份到雲存儲時，您的文件存儲在異地。這消除了可能導致問題的本地硬件漏洞。那麼，為什麼要進行雲備份？

雲備份是負擔得起的，因為您只需按使用付費。
雲備份是安全的，因為它提供端到端加密。
允許輕鬆的災難恢復和數據恢復
強大的雲備份選項包括系統映像的整個備份。因此，您無需重新安裝操作系統。計算機和服務器恢復到上一個正常運行的版本。

文件共享軟件

像 Dropbox 這樣的軟件套件正在不斷發展以滿足用戶的需求。 Dropbox 維護可在需要時恢復的文件版本。與雲備份類似，此選項價格合理，文件存儲在異地。它的優點是什麼？

文件可以在任何位置恢復到任何系統。
它是免費的並且支持協作。
高度安全（雲存儲加密傳輸中的文件）
離線工作能力

然而，一個缺點是恢復不是自動化的。您需要將數據複製並粘貼到文件共享目錄結構中才能保存數據。這些文件必須駐留在定義的結構中，否則它們將不會被備份。如果文件位於共享文件夾或目錄中，您可能需要更多帶寬來備份這些文件。

一般來說，還有其他可用的備份介質，例如備份到閃存驅動器或外部硬盤驅動器。但不推薦使用這些選項，因為與雲備份或文件共享軟件相比，它們並不完全安全。例如，對硬盤驅動器的任何物理損壞都可能導致數據丟失。此外，它們更容易受到勒索軟件攻擊和加密病毒的影響。

如何確保數據安全？

在進行數據遷移時，您需要確保敏感數據不被破壞或篡改。如果遷移出錯，可能會導致更大的後果，並導致數據洩露或數據丟失，例如 2020 年此處引用的示例。

不幸的是，數據洩露可能會對客戶的聲譽造成損害，導致業務和客戶的流失；或在某些情況下，可能會引發法律訴訟。為避免所有此類後果，您需要事先制定安全計劃，並牢記遷移策略。

首先，可靠和安全的服務器訪問和數據訪問應該放在您的優先級列表中。
增加數據傳輸所需的權限數量。在較大的組織中，安全部門限制對服務器的訪問並定義所涉及的服務器之間的數據遷移。
當涉及更多方時，數據處於高風險中。因此，請避免通過便攜式存儲設備或電子郵件在各方之間進行傳輸。在這種情況下，數據很容易被洩露。
為確保數據的安全訪問、存儲和檢索，必須不斷練習加密和解密。您可以使用混合加密算法來確保最大的數據安全性。但這並不推薦給所有人。如果遷移失敗，則數據將變得混亂，並可能導致數據損壞或數據丟失。

為確保安全遷移，請避免使用原始工具。使用原始工具可能會削弱您的系統並留下漏洞讓黑客訪問。您必須使用功能特定的強大工具進行數據遷移。

數據遷移過程

數據遷移主要是一個多階段的過程，應遵循以下步驟，以避免數據丟失並確保安全的數據庫遷移。

評估：

收集業務需求分析並定義需要使用 DBM 實現的關鍵目標。
定義範圍
進行廣泛的數據分析：
- 審查源數據、數據格式、審查模式結構、內容和數據實例之間的關係
了解目標系統
識別利益相關者
預算整個活動

數據備份

確保您正在遷移的數據得到安全備份。建議使用雲備份。
確保目的地干淨並免受任何數據黑客攻擊。

資源可用性：

遷移的可用時間和目標系統的停機時間。
確保僱用的人力資源確實具有正確的技能。
確定正確的工具和腳本。

數據遷移執行：

遷移過程可能包括腳本、ETL 工具或其他類似的工具來移動數據。
在遷移時，您將轉換數據，規範化數據類型，最後檢查可能的錯誤。

測試和調整：

團隊和客戶團隊需要嚴格確保所有數據都正確遷移
所以，檢查數據是否正確移動，數據是否完整，確保沒有缺失值。
此外，請確保數據有效且不包含任何空值。
如果有任何數據不匹配，則應進行數據回滾並重新啟動整個過程。

審計

一旦新數據庫上線，就可以設置一個系統來審核數據。這將確保數據庫遷移的準確性，並引起對不完整和不准確數據的注意。

數據庫遷移的潛在風險

數據庫遷移是一個非常複雜的過程，它伴隨著風險和不確定性。您始終可以通過適當的計劃和執行來克服這些問題。可能遇到的風險有：

過時的源系統：在這裡，數據源可以是過時的、冗餘的、過時的或瑣碎的
不同的數據庫架構：在這種情況下，源數據庫可能位於多個位置，並且它們可能具有彼此完全不同的架構，但目標數據庫需要一切同步。
延長停機時間：在某些情況下，計劃的遷移時間比預期的要長，因此系統的停機時間會延長。這可能會導致最終客戶的業務損失，並且可能是不可接受的。
潛在數據丟失：並非所有數據丟失都可以在測試階段識別出來。當系統獲得足夠的流量時，最終可能會識別出一些數據丟失實例。

從實時數據庫遷移：對於任何高交易量的網站，遷移數據庫總是很困難，因為數據不斷更新；並且無法遷移實時和實時數據。任何遷移都必須有一個停機時間。

最後的話

您可以隨時向第三方專家尋求有關數據庫遷移的指導。我們是 Creole Studios，專門從事數據庫遷移，我們很樂意在任何此類工作中提供幫助或諮詢。請繼續關注技術遷移系列的第四篇也是最後一篇博客。