技术迁移策略完整指南：（第 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，专门从事数据库迁移，我们很乐意在任何此类工作中提供帮助或咨询。请继续关注技术迁移系列的第四篇也是最后一篇博客。