什麼是資料庫遷移？
資料庫遷移是指將現有資料庫中的資料移至新的或更新後的資料庫，遷移內容包含資料庫中的結構定義物件 (例如資料表、索引、檢視表)、預存程序、函式和觸發條件。
瞭解資料庫遷移服務，並將資料庫遷移至 Google Cloud。
資料庫遷移與資料遷移有何不同？
資料遷移是資料庫遷移程序的一部分，可將資料從一個環境移至另一個環境。您可能需要在不遷移資料庫的情況下移動資料，例如進行儲存空間相關變更時。
資料和資料庫遷移成功的關鍵，在於準確快速地轉移資訊，同時盡可能減少轉移和轉換期間的停機時間和中斷。
為何要遷移資料庫？
有時，您遷移並非出於自願，而是不得不這麼做。舊版系統最終可能無法滿足現代企業的需求，維護這些系統可能會成為風險，而非資產。
以下是您可能需要遷移資料庫的幾個主要原因：
- 硬體服務終止：實體伺服器已老舊，製造商不再支援硬體或作業系統
- 效能瓶頸：目前的資料庫架構無法處理資料量或流量尖峰，導致使用者體驗不佳
- 安全性和法規遵循：舊系統可能缺乏現代安全防護功能、修補程式或稽核功能，無法滿足現今的法規標準
- 受制於特定供應商：您受限於專屬、昂貴或缺乏彈性的授權，無法創新或選擇最符合特定需求的工具
- 資料孤島：資料困在各自獨立的地端部署系統，難以提供給現代化分析或 AI 模型，導致團隊無法維持競爭力
如果現有架構無法滿足營運需求，就必須遷移，才能確保業務安全且有效率地運作。
同質與異質遷移
遷移資料庫時，您可能會聽到「同質」和「異質」這兩個詞。瞭解兩者差異，有助於規劃技術團隊的工作量。
遷移類型 | 說明 | 運作方式 |
同質 | 來源和目標資料庫使用相同或非常相似的引擎。 | 由於資料格式已相容，因此通常較為簡單。 |
異質 | 目標資料庫使用的引擎與來源不同。 | 這需要轉換結構定義和程式碼，讓新資料庫能夠理解。 |
遷移類型
說明
運作方式
同質
來源和目標資料庫使用相同或非常相似的引擎。
由於資料格式已相容，因此通常較為簡單。
異質
目標資料庫使用的引擎與來源不同。
這需要轉換結構定義和程式碼，讓新資料庫能夠理解。
資料遷移策略
遷移資料有四種常見策略。如要瞭解詳情並取得建議策略，請參閱雲端遷移策略。
- 重新託管：lift-and-shift。這是遷移資料最簡單的方法，會將現有資料庫的完整副本和其餘應用程式堆疊一起複製到其他環境。[同質]
- 更換平台：轉移並最佳化：這項策略會複製資料庫、應用程式和虛擬機器，然後針對新的雲端環境最佳化這些項目。這是一種異質遷移，例如從商業資料庫遷移至與 PostgreSQL 相容的資料庫 (例如 AlloyDB)。[同質/異質]
- 重構：遷移與改善。重構雲端遷移策略是指重新設計應用程式，使其符合雲端原生原則，因此必須變更應用程式程式碼。[通常為異質]
- 重新建構：重建雲端遷移策略會徹底改寫雲端架構與應用程式。視您的應用程式而定，這項程序的費用可能比重構成本低。[通常為異質]
資料庫遷移常見問題
可以使用 AI 遷移資料庫嗎？
是，這已成為加速流程的常見做法。AI，尤其是大型語言模型，可協助分析現有程式碼和結構定義，並建議目標資料庫的轉換方式。這有助於自動重寫複雜的程式碼，並找出可能導致遷移作業延遲的相容性問題。
資料庫遷移需要多久時間？
可能需要幾天到數個月的時間才能完成，因此請務必妥善規劃。考量因素包括資料庫大小 (小型專案可能需要幾天，複雜的多層遷移作業則可能需要幾個月)、遷移策略，以及是否使用資料庫遷移服務。
什麼是資料庫結構定義？
結構定義是資料庫的藍圖或地圖，定義了資料的組織方式，包括資料表、欄位以及彼此之間的關係。在遷移期間，如果您要改用其他類型的資料庫引擎，可能需要轉換這個藍圖。
資料庫遷移有哪些風險？
最大風險包括資料遺失、長時間停機和安全漏洞。如果遷移作業未妥善規劃，應用程式可能無法在新環境中正常運作。使用代管遷移服務並徹底測試系統，有助於降低這些風險。
遷移資料庫時需要停機嗎？
您通常可以透過複製功能，同時執行新舊資料庫，盡可能縮短停機時間。雖然在最後的「轉換」階段，通常需要短暫停機，但進階遷移服務的設計，就是為了盡可能縮短這段時間。
使用資料庫遷移服務的好處
資料庫遷移不只是移動資料，還要保留功能，確保工作負載在新系統上順利執行。遷移方式取決於您編寫的程式碼和遷移工具。
手動遷移資料不僅耗時，也可能帶來風險，但使用專屬遷移服務可協助您確保專案進度符合預期。
移轉速度更快
移轉速度更快
專用工具會使用最佳化路徑，快速轉移資料。
減少停機時間
減少停機時間
遷移服務可確保應用程式持續運作，讓客戶不會察覺服務中斷。
資料一致性
資料一致性
這些工具可確保資料在新系統中的外觀和運作方式，與舊系統相同。
安全性
安全性
資料傳輸時會經過加密，確保不會遭人窺探。
簡化複雜度
簡化複雜度
如果改用其他資料庫引擎，這些服務通常能協助您自動轉換程式碼。
降低費用
降低費用
減少手動作業並縮短專案時程，可節省人力和經常性費用。
遷移至雲端的好處
雖然資料庫幾乎可以在任兩個位置之間遷移，但大多數遷移作業是從 on-premises 遷移至雲端，或是從一個雲端遷移到另一個雲端。
公司遷移至雲端 (或其他雲端服務供應商) 的原因有很多：
- 加快應用程式開發作業
- 提升效能和擴充性
- 節省成本
- 安全性
- 使用更豐富的功能，尤其是 AI 相關功能
- 從傳統授權資料庫常見的 on-premises 投入成本 (CapEx) 轉變為採用雲端服務的營運成本 (OpEx)。
進一步瞭解遷移至雲端的好處。
從地端部署遷移至雲端的特別注意事項
基於上述原因，許多機構將 on-premises 工作負載遷移至雲端。相較於雲端至雲端的遷移，從 on-premises 遷移需要額外考量。
重新託管是遷移 on-premises 工作負載的常見策略，重新託管會將整個工作負載複製到雲端。這樣做可以獲得與雲端遷移相關的安全性、可靠性和一些成本優勢。
不過，這項策略也會將地端部署架構中任何現有的效率不彰情況轉移至雲端基礎架構，導致您無法享有雲端原生架構帶來的更大幅度成本節省和效率提升。您也可能無法享有災難復原、數據分析整合、AI/機器學習服務及合作夥伴產品/服務市集等領域的強大雲端功能。
請務必在遷移期間維護資料安全，尤其是在不同類型的環境之間。確保最佳安全性的方法之一，是使用值得信賴的資料庫遷移服務。
資料遷移最佳做法
資料和資料庫遷移作業可能相當複雜。請務必確保企業的資料、組織和職能，都能順利轉移至新架構。如果處理不當，可能會導致資料遺失、工作負載無法正常執行或安全問題。
最佳做法範例：
- 解讀資料。瞭解自家業務案例和應用程式的需求相當重要。
- 評估業務發展方向。將資源調度納入考量是選擇合適架構和供應商的關鍵。
- 使用功能旗標進行測試。先使用功能旗標，將新資料庫推出給一小群使用者。這樣就能在全面推出前，安全地測試系統。
- 根據實際情況，選取合適的資料遷移策略。
- 嚴謹遵循資料遷移計畫，確保發揮最佳效能。
成功遷移的步驟
如要深入瞭解相關程序，請參閱資料遷移的概念與原則，以及設定與執行資料遷移程序。
以下說明成功遷移作業的基本步驟，細節會因您的業務案例而異：
- 確認所有資料目前的位置、格式，以及遷移後應存放的位置。您可能會發現不需要遷移所有資料，並選擇封存或刪除舊資料。這也是留意任何潛在遷移風險的關鍵時刻。
- 規劃遷移策略。決定最合適的遷移策略、營業時間內能否承受停機，以及設定預算。
- 執行遷移作業。您可能會考慮使用遷移服務來進行實作。
- 在轉換之前測試新系統。這有助於找出任何無法正常運作的工作負載，並解決問題。您可能需要同時執行兩個資料庫，這樣就需要將資料從其中一個系統複製到另一個系統。請務必先確認所有工作負載都在新資料庫上運作，再關閉舊系統。
遷移作業需要的階段數量，取決於貴機構目前的設定和時程。舉例來說，從自行管理的地端部署環境遷移至代管雲端服務只需要完成一個步驟。如果有時間壓力，也可以先遷移至雲端上自行管理的資料庫，再改用全代管解決方案。
資料庫遷移作業的重要考量
理想情況下，資料庫遷移並不是公司經常執行的程序。為充分發揮遷移效益，請思考以下幾個關鍵問題：
考量 | 建議 |
應該先遷移哪些資料庫和應用程式？ | 從優先順序較低或內部的工作負載開始，讓團隊在接觸關鍵業務系統之前，有機會完善流程。 |
是否應變更資料模型？ | 評估現有模型是否符合需求。如果資料結構正在改變，改用其他模型 (例如 NoSQL 資料庫) 可提供更多彈性。 |
該自行管理資料庫，還是選擇代管服務？ | 盡可能選擇代管服務，全面擺脫維護與修補的負擔，讓團隊專注於建構應用程式，而非管理基礎架構。 |
遷移作業會如何干擾業務營運？ | 使用複製功能，讓新舊資料庫同時運作，直到您準備好進行最終轉換，盡可能減少服務中斷。 |
考量
建議
應該先遷移哪些資料庫和應用程式？
從優先順序較低或內部的工作負載開始，讓團隊在接觸關鍵業務系統之前，有機會完善流程。
是否應變更資料模型？
評估現有模型是否符合需求。如果資料結構正在改變，改用其他模型 (例如 NoSQL 資料庫) 可提供更多彈性。
該自行管理資料庫，還是選擇代管服務？
盡可能選擇代管服務，全面擺脫維護與修補的負擔，讓團隊專注於建構應用程式，而非管理基礎架構。
遷移作業會如何干擾業務營運？
使用複製功能，讓新舊資料庫同時運作，直到您準備好進行最終轉換，盡可能減少服務中斷。
