摘要：NoSQL数据库迁移需谨慎规划，包括模式迁移、数据迁移和验证。选择在线或离线迁移，考虑技术切换、工具和边缘情况。不必迁移所有数据，关注重要部分。测试至关重要。
NoSQL数据库迁移需谨慎规划，包括模式迁移、数据迁移和验证。选择在线或离线迁移，考虑技术切换、工具和边缘情况。不必迁移所有数据，关注重要部分。测试至关重要。
译自：What Matters Most for NoSQL Migrations
作者：Felipe Cardeneti Mendes
没有团队愿意承担数据库迁移。但是许多团队正在迁移 NoSQL 数据库，以优化大规模性能、减轻维护负担和/或控制成本。如果迁移已在您团队的考虑范围内，您如何使这个过程尽可能轻松，并最大程度地减少对您的团队和用户的干扰？
以下是一些经过实战检验的技巧，用于规划、执行 NoSQL 数据库迁移并降低其风险。
好消息是，从一个数据库迁移到另一个数据库，甚至迁移到同一数据库的新拓扑结构，实际上并不难。从本质上讲，迁移只是将数据从源系统移动到目标系统。团队将这个过程复杂化，通常是因为他们对所涉及的内容缺乏清晰的端到端理解。
在您真正开始迁移过程之前，您需要决定采取哪种类型的迁移方法。主要有两种选择：在线或离线。
离线迁移：在这里，您停止源系统，传输数据，然后切换您的客户端以使用新的数据库。在线迁移：在这里，没有应用程序停机时间。这增加了复杂性，并且需要进行测试以确保您不会对读取和写入数据库的应用程序产生上游影响。无论您决定采用哪种方式，您都需要执行三个关键步骤：
模式迁移和更改： 通常需要一定程度的模式调整，除非您要迁移到同一数据库的另一个版本，或者迁移到两个 API 兼容的数据库。数据迁移： 将您的数据从一个地方移动到另一个地方。数据验证： 验证您的数据，以确保一切正常运行。这将我们带到实际的迁移流程，如下图所示。该过程的各个阶段由虚线垂直线分隔。
开始时，应用程序正在从源数据库写入和读取数据。您将从那时开始迁移模式。在目标数据库上正确设置模式绝对至关重要。如果出现错误，您将需要重复所有迁移步骤。Discord 工程师 Bo Ingram 和我在最近的 NoSQL 数据建模以提高性能大师班 中广泛讨论了数据建模策略，该课程可按需提供。
如果您正在运行在线迁移，您还需要开始捕获源数据库中发生的更改。这里的最佳方法取决于您要从中迁移到（和迁移到）哪个数据库。例如，在 DynamoDB 中，您将启用 Dynamo Streams。如果您要从 Cassandra 迁移到 ScyllaDB，那么应用程序的双重写入在大多数情况下都可以正常工作。其他方法包括使用 Kafka、数据库的变更数据捕获 (CDC) 和类似工具。
接下来，是时候实际移动现有数据了。如果您在上一步中启用了 CDC，那么您应该等待所有更改重放完毕后再继续执行下一步。
完成之后，您的源数据库和目标数据库应该都已同步。那时，您需要先测试迁移结果，然后再更新应用程序以使用新的数据库。这可以通过多种方式完成。例如，您可以快速比较随机的单个记录。或者，您可以进行更广泛的检查，比较每个单独的记录，然后再做出是否继续的决定。要执行的验证级别取决于您团队的要求和风险承受能力。
最后，一旦系统按预期运行，您就可以将客户端流量切换到新的设置。您可以一次性全部移动，也可以使用 金丝雀部署策略 以增量方式进行移动，作为一种安全措施（一次移动一组用户）。
上面概述的迁移过程在理论上相当简单。但实际上，有时它会变得复杂。例如，您还需要考虑以下方面：
技术切换： 如果您要从一个数据库迁移到另一个不同的数据库，那么您将很快意识到您依赖的某些功能在新数据库上不可用。或者，它们可能可用，但实现方式不同。您还需要了解目标数据库的特性，以确保您的数据建模能够随着工作负载的增长而扩展。对于您所做的每个应用程序更改和数据建模更改，您都需要投入足够的时间进行测试。工具： 除非您是 Spark/Scala 专家，否则您几乎不可能找到一个工具可以从任何数据库迁移到任何数据库。即使存在这样的工具，也可能需要进一步调整才能专门为您工作，具体取决于您的工作负载和要求。当没有工具时，您几乎需要从头开始编写自己的工具和流程。边缘情况： 某些用例可能依赖于特定的数据库功能，例如自定义数据类型（例如计数器）或并发控制技术（可序列化性）。这些可能会在迁移过程中带来额外的挑战；它们可能不受直接支持，或者在目标系统中的行为可能不同。您需要尽早识别这些情况并特别小心地处理它们。只移动重要的内容最后一个经常被忽视的考虑因素是：您可能不需要迁移所有内容。
团队通常认为他们需要迁移所有数据，但这通常是过度的。更有选择性可以节省大量时间和精力。它还会迫使您更仔细地查看您的工作负载，这通常会揭示一些问题，例如一致性要求和用户行为模式，否则这些问题可能会被忽视。
当我问人们“您可以容忍一定程度的数据丢失吗？”时，他们的下意识反应几乎总是响亮的“不！”但假设您有一个 IoT 用例，并且您的应用程序每小时/每天/每周生成报告。在迁移过程中删除几个数据点可能并不重要，特别是如果您的仪表板在更长的时间范围内聚合数据。
在许多情况下，用户不在乎几周前的数据。如果您的工作负载确实如此，请不要费心迁移所有数据。日志和跟踪也是如此：您可以只对历史数据进行快照，然后在新系统上重新开始，而不是迁移历史数据。
当然，某些用例（如消息应用程序、社交平台或金融系统）确实需要零数据丢失。任何丢失的记录都可能直接影响业务。但即使如此，您仍然可以对如何构建迁移有一定的灵活性。例如，也许您需要迁移 10 个表，但是您可以将几个表映射到特定的微服务。在这种情况下，您可以将实际的迁移工作分解为更小的迭代。也许其中一些表使用了生存时间 (TTL) 数据，因此您可以仅迁移对您的业务最重要的部分。
在开始之前，花时间考虑这些迁移的细微差别。一点规划应该可以帮助您尽早发现潜在的挑战和优化机会，最终从长远来看可以为您节省大量时间和麻烦。最重要的是：在生产环境中运行迁移计划之前，请对其进行测试。跳过此步骤可能会导致您肯定希望避免的痛苦（且可能代价高昂）的意外情况。
来源：科技未来花开
