使用 AWS DMS 成本优化数据库迁移：第一部分 数据库博客

优化 AWS DMS 数据库迁移成本：第 1 部分

撰稿人：Shailesh Kumar Mishra 和 Babaiah Valluru 2024 年 2 月 7 日 发表于 AWS 数据库迁移服务、最佳实践、中级学习(200)永久链接评论 分享

关键要点

在数据库迁移中，降低成本优化是非常重要的。迁移不仅仅是移动数据，而是在确保每个资源高效利用、基础设施费用最小化、投资回报率最大化的情况下进行的。对成本影响进行仔细考虑并实施战略性措施至关重要。需要在最小化开支和确保最佳性能及可靠性之间找到平衡，以增强迁移投资的价值。随着我们深入研究数据库迁移架构的设计，多个组成部分必须逐一分析，以确保迁移过程的顺利和高效。

在本篇文章中，我们将探讨如何使用 AWS 数据库迁移服务 AWS DMS来优化数据库迁移成本，并讨论数据库迁移的方法、配置、考虑事项和方法。

这是一个两部分的系列文章。在第 1 部分本篇，我们讨论数据库迁移的组成部分、迁移成本及其影响因素，以及如何选择适合的 AWS DMS 实例类型，这将决定 DMS 任务的容量。而在 第 2 部分，我们将讨论如何定期评估 AWS DMS 实例的大小，并根据需求进行扩展或缩减，以及如何利用 AWS DMS 的特性和配置来优化迁移成本。

数据库迁移的组成部分

数据库迁移通常包括以下组成部分：

组成部分描述源数据库识别需要迁移的现有数据库系统，例如 PostgreSQL、MySQL 或 Oracle。了解源数据库的架构、数据量和依赖关系。目标数据库确定数据将迁移到的目标数据库系统，例如 Amazon 关系数据库服务Amazon RDS、[Amazon Aurora](https//awsamazoncom/rds/aurora/、NoSQL 数据库、数据湖或其他可选项。考虑目标数据库的兼容性和特性。数据迁移工具或服务选择合适的工具从源数据库提取数据并将其加载到目标数据库，然后进行源数据库到目标数据库的变更数据捕获CDC，例如 AWS DMS、AWS 合作伙伴解决方案或开源工具如 Debezium。架构转换在异构迁移中，源和目标数据库具有不同的架构结构或数据类型，需要使用 AWS DMS 架构转换SC或 AWS 架构转换工具AWS SCT 来协调迁移，视迁移目标而定。此组件可以帮助转换架构和数据，以符合目标数据库要求。

对于那些寻求在数据库架构迁移中优化成本的技术爱好者，使用 AWS SCT 是一个战略性选择。此工具免费提供，能够有效地将现有数据库架构从一个引擎转换为另一个引擎，支持多种源数据库，如 Oracle、Microsoft SQL Server、MySQL、Sybase 和 IBM Db2 LUW。AWS SCT 是一种经济高效的解决方案，能够显著简化数据库架构的迁移过程，减少人工干预。

AWS DMS 也提供了架构转换功能，AWS DMS 架构转换是一个完全托管的功能，允许在不同数据库平台之间自动评估和转换数据库架构和代码对象。这帮助通过减少所需的手动努力来简化迁移。AWS DMS 架构转换允许将源数据库架构转换为目标引擎，使用户能够选择特定的架构项目。可以应用转换规则来修改数据类型、移动对象或在转换前更改对象名称。当某些源数据库特性不具备与 Amazon RDS 相应的目标数据库端点时，可以使用 扩展包 来模拟这些特性。转换后的代码和扩展包架构可以应用于目标数据库。此外，DMS 架构转换支持与最新 AWS SCT 版本兼容的特性，确保与不断发展的 AWS 技术之间的集成和兼容性。

数据库迁移成本及其因素

有效地优化数据库迁移成本需要全面了解和管理多种因素。这包括仔细考虑迁移的数据量、选择适当的实例类型和存储选项、使用自动化和压缩技术，以及优化网络带宽的利用。在本篇文章中，我们讨论如何在 AWS DMS 中有效管理这些因素，以实现成本效益高的数据库迁移，同时保持高性能和可靠性。

以下是需考虑的因素：

因素描述AWS DMS 复制实例小时使用量这是影响 AWS DMS 使用的主要因素。AWS DMS 实例根据实例的总小时使用量计费。每小时根据所选择的实例类型产生特定费用。AWS DMS 复制实例类型选择的复制实例类会影响定价。不同的实例类具有不同的性能特征和相关费用，例如，R 或 C 类的高性能实例类相较于 t2 或 t3 的低性能类会更昂贵。AWS DMS 复制实例部署类型根据您的特定需求，您可以选择将 AWS DMS 实例部署在单个可用区或多个可用区。如果环境不需要 AWS 数据库迁移服务DMS实例始终可用，并且可以容忍一些数据复制延迟，使用单可用区AZDMS 实例将比多 AZ 配置节省开支。AWS DMS 复制实例存储卷每个计算优化C或内存优化R实例类型都会分配 100 GB 的 GP2 网络附加存储，用于交换空间、复制日志和数据缓存。相似地，每个爆发式性能T实例类型包括 50 GB 的 GP2 网络附加存储。如果您需要额外的存储以便长时间保存日志，您可以选择扩展已分配的存储并按需支付额外费用。数据传输数据传输到 AWS DMS 不会产生额外费用，并且在相同可用区内，AWS DMS 与 Amazon RDS 和 Amazon 弹性计算云Amazon EC2实例之间的数据传输也是免费的。然而，当将源数据库迁移到位于不同可用区、区域或 AWS 之外的目标数据库时，则会按照标准 AWS 数据传输费率收费。

以下图表展示了需要考虑的 AWS DMS 成本的不同因素。

建议使用 AWS DMS 价格计算器 来估算 AWS DMS 实例运行的成本，结合以上所有成本因素进行有效预测。

pixivturbo加速器

以下是 AWS DMS 的两个关键特性，助力降低底层 AWS DMS 实例的配置复杂性，这些特性支持按实际使用量计费：

特性描述AWS DMS 无服务器数据迁移AWS DMS 无服务器 提供灵活的定价模型。您只需根据实际使用的计算能力按小时收费，而无需假设并持续消耗固定的计算能力。无服务器选项使您可以根据工作负载的实际情况灵活调整，用于持续的数据复制。当数据复制任务的活动水平在一天内发生变化时，AWS DMS 无服务器将根据每小时实际工作负载收取费用。高峰期服务会根据更高的交易量自动扩展，而在非高峰时段将缩减到最低以减少成本。AWS DMS 同构数据迁移从成本优化的角度来看，同构数据迁移 利用实例配置文件、数据提供者和迁移项目。通过设置与源和目标数据提供者兼容的迁移项目，AWS DMS为数据迁移建立无服务器环境，确保高效运行。此方式遵循按实际使用计费模型，确保您仅为消耗的资源付费。AWS DMS 连接源数据提供者，读取数据，将文件存储在磁盘上，并使用原生数据库工具恢复数据。

选择适合的 AWS DMS 实例类型

评估源数据库的工作负载和资源要求。根据工作负载特征、数据量和性能要求为 AWS DMS 复制实例选择合适的实例类型。避免过度配置资源，以减少成本。您选择的实例类型将对迁移成本产生显著影响。例如，C4 实例比 T2 实例更强大，但成本也更高。选择最符合您需求和预算的实例类型。对于小量迁移数据，可以使用较小的实例类型。对于较大的迁移，可能需要使用较大的实例类型。如果需要在开发或测试环境中使用突发实例，可以在较低环境中使用较小的复制实例。

在本部分，我们讨论数据库迁移的不同方面，帮助您选择适合的 AWS DMS 实例的大小和类型。

内存密集型工作负载

内存密集型工作负载需要大量内存才能运行任务。分布式数据库和实时流数据分析的缓存通常是这种工作负载的常见实例。如果迁移涉及大对象LOB值，数据库迁移可能会变得内存密集。通常，表中的 LOB 数据列可能在 AWS DMS 实例上使用更多内存，因为 LOB 是可以存储大量数据的大对象。例如，一个可以存储 1 GB 的 LOB 列将在 AWS DMS 实例上需要 1 GB 的内存。此外，AWS DMS 需要在迁移时在内存中存储 LOB 数据的副本。这意味着如果表中有大量 LOB 列，AWS DMS 实例可能会需要大量内存，根据 AWS DMS 任务中的 LOB 设置而定。

选择正确的 LOB 配置需要平衡多个因素。在完整 LOB 模式下，过程开始时在目标数据库中创建一个空的 LOB 列，然后逐步填充 LOB 数据，因为 AWS DMS 不知道每行和列中最大 LOB 数据大小。这种方法可能会使迁移过程速度减缓，相对而言，有限 LOB 模式将 LOB 数据迁移到预配置的最大大小。内联 LOB 模式在 LOB 数据大小超过已配置的最大大小限制时，会切换到完整 LOB 模式。最佳的 LOB 模式使用应基于特定迁移要求。如果迁移大量 LOB 列，您可能需要使用完整 LOB 模式。如果内存有限，您可能需要使用有限 LOB 模式。而对于少量 LOB 列迁移，可以选择内联 LOB 模式。

以下是一些可能影响内存或消耗更多内存的其他因素，因此 AWS DMS 实例可能需要更多内存：

在 AWS DMS 完全加载和 CDC 任务期间迁移的数据量 数据越大，所需内存越多。在完全加载期间，如果有任何在途或进行中的事务，AWS DMS 复制实例将首先在内存中缓存更改。当内存满时，将切换到磁盘，直到完全加载完毕。考虑在什么程度的交换缓存更改是合适的。每秒事务数量 每秒事务次数TPS越高，所需内存越多，因为 AWS DMS 实例中的排序组件会跟踪正在进行和已完成的事务，然后将其发送到目标端点。这在发送到目标端点之前需要在 AWS DMS 实例上存储内存。并发复制任务的数量 如果您运行多个并发复制任务，则需要更多内存，因为每个任务会单独占用 AWS DMS 实例内存。

如果需要更多内存，则可以升级到更大的实例类型。您可以使用 Amazon CloudWatch 指标来监控复制实例的性能。如果监测到内存压力，您可以增大实例类别或修改其他配置。我们将稍后进一步讨论如何监测 CloudWatch 指标。

如果您的迁移包含任何这些因素，请采取措施减轻内存使用，例如使用针对内存使用优化的数据库迁移工具，将迁移分解为更小的批次，以及使用临时中间数据库以减轻生产数据库的负载。

CPU 密集型工作负载

数据库迁移可能因具有高计算要求而成为 CPU 密集型，这在多玩家游戏应用、大数据分析、三维建模和视频编码等应用中非常常见。

首先，您的迁移是同构还是异构？在同构数据库迁移中，源和目标数据库为同一类型的数据库引擎，这意味着数据可以直接从源传输到目标，无需转换。而在异构数据库迁移中，源和目标数据库是不同的数据库引擎，因此数据需要从源格式转换为目标格式。此转换过程可能会占用大量 CPU，特别是当数据量很大或复杂时。

以下是一些可能消耗更多 CPU 的数据库迁移示例：

从关系数据库迁移到 NoSQL 数据库 NoSQL 数据库通常以不同于关系数据库的方式存储数据，这意味着数据在迁移到 NoSQL 数据库之前需要进行转换。从大型机数据库迁移到云本地数据库 大型机数据库通常复杂且庞大，因此将其迁移到云数据库可能是 CPU 密集型的。从遗留数据库迁移到现代数据库 遗留数据库通常过时且效率低下，迁移到现代数据库可能需要消耗大量的 CPU 资源来转换数据和更新架构。

其次，您是否打算并行化迁移过程？有时迁移需要更快地完成，这也可以节省 CPU 资源。当数据迁移通过 AWS DMS 并行化时，因为 AWS DMS 实例需要在多个线程中处理数据，因此将消耗更多 CPU 资源，尤其是当数据复杂或庞大时。当一个表被分割成多个 AWS DMS 任务，每个任务需要处理自己的一部分数据，这可能需要更多的 CPU 资源，如果整个表用一个任务处理，CPU 使用会减少。

同样，当 AWS DMS 任务以多个线程运行时，每个线程需要处理自己的数据流，这也将需要更多的 CPU 资源，而不是单个线程运行。

并行化数据迁移所需的 CPU 数量将依据以下特定因素而变化：

正在迁移的数据量使用的分区或线程数量数据的复杂性正在执行的数据迁移类型

此外，考虑分批迁移数据。这有助于减少需要一次处理的数据量，这也同样可以节省 CPU 资源。

通过遵循这些建议，您可以减少数据库迁移的 CPU 需求，确保顺利成功