优化 AWS DMS 与 Amazon Kinesis 数据流的复制性能 第2部分

关键要点

在本文中，我们探讨了如何通过调整不同的参数来优化 AWS 数据库迁移服务DMS从关系数据库向 Amazon Kinesis 数据流复制数据的性能。特别关注了多线程全量加载与变更数据捕获CDC过程的设置，展示了不同配置对吞吐量的影响。此外，提供了自定义表映射和分片设置的影响分析。

测试环境配置

在系列文章第1部分中，我们讨论了多线程全量加载和CDC设置的架构，以及在使用 AWS DMS 将数据从关系数据库复制到 Amazon Kinesis 数据流时，需要配置的各种参数，以及考量因素和最佳实践。

为展示在第1部分中所述的行为，我们组建了多个配置，包括并行加载和应用设置，自定义表映射规则，以定义分区键，以及目标 Kinesis 数据流的分片。我们选择将 Amazon RDS for PostgreSQL 作为源数据库引擎，使用 PostgreSQL 137 在 r5xlarge 实例上运行，并使用 pglogical 插件。我们使用 AWS DMS 进行数据迁移，DMS 引擎版本为 347，运行在 dmsr5xlarge 实例上。

我们创建了一个名为 largetest 的表，表定义如下：

sqlCREATE TABLE IF NOT EXISTS publiclargetest(pk integer NOT NULL DEFAULT nextval(largetestpkseqregclass)num2 double precisionnum3 double precisionCONSTRAINT largetestpkey PRIMARY KEY (pk))

CREATE SEQUENCE IF NOT EXISTS publiclargetestpkseqINCREMENT 1START 1MINVALUE 1MAXVALUE 9223372036854775807CACHE 1

我们将约100万条记录加载到 largetest 表中，针对全量加载的所有测试场景进行吞吐量测试。全量加载的吞吐量以 Fullloadthroughputrowstarget记录/秒和 Networktransmithroughput字节/秒来衡量。对于 CDC，我们创建了一种过程，在特定时间对 largetest 表进行大量更改，并测试复制性能。CDC 吞吐量以 CDClatencytarget秒和 Networktransmithroughput字节/秒来衡量。我们将在以下部分讨论各种场景和结果。

场景1：无并行加载设置和无自定义表映射的全量加载

我们为 full load 创建了 AWS DMS 任务，以 largetest 作为源，Kinesis 数据流按需模式作为目标。在 AWS DMS 任务中，为了进行基准测试，我们没有使用并行加载设置或自定义表映射规则。

我们为此测试案例选择了四个 Kinesis 数据流分片，设置如下：

jsonParallelLoadQueuesPerThread 0ParallelLoadThreads 0ParallelLoadBufferSize 0

在这些设置下，我们的基准线大约为每秒115条记录被导入到 Kinesis 数据流。相关的行吞吐量如下图所示。

相应的网络吞吐量约为350 KB/s，如下图所示。

我们还在有八个分片的 Kinesis 数据流上基准测试了该配置，其余并行加载设置或自定义表映射规则与之前的场景1a相同。测试显示每秒记录数适度增加到125，如下图所示。

相关网络吞吐量约为360 KB/s，如下图所示。

场景2：无并行加载设置且有自定义表映射

在此场景中，保持并行加载设置与之前相同，我们调整 AWS DMS 任务以使用如下自定义表映射：

json{ rules [ { ruletype selection ruleid 967609532 rulename 967609532 objectlocator { schemaname public tablename largetest } ruleaction include filters [] } { ruletype objectmapping ruleid 23 rulename TransformToKinesis ruleaction maprecordtorecord targettablename largetest objectlocator { schemaname public tablename largetest } mappingparameters { partitionkeytype attributename partitionkeyname pk attributemappings [ { targetattributename pk attributetype scalar attributesubtype number value {pk} } { targetattributename num2 attributetype scalar attributesubtype number value {num2} } { targetattributename num3 attributetype scalar attributesubtype number value {num3} } ] } } ]}

使用默认设置未定义自定义表映射时，AWS DMS 将 AWS DMS 对象映射参数 partitionkeytype 设置为表的主键。可以选择将 partitionkeytype 设置为 schematable，即源数据库同一模式中的表将加载到 Kinesis 数据流的同一分片。

通过将 partitionkeytype 设置为主键，可以强制 AWS DMS 使用 Kinesis 的 PutRecords API，并根据分区键将在所有目标分片之间分配记录。

使用这些自定义表映射规则，我们在目标四个分片中实现了每秒108条记录，如下图所示。

网络吞吐量约为350 KB/s，如下图所示。

使用这些自定义表映射规则，我们在目标八个分片中实现了每秒116条记录，如下图所示。使用自定义表映射并未显著改变吞吐量，但可以控制数据在分片之间的分布，避免潜在的热点分片。

网络吞吐量约为375 KB/s，如下图所示。

场景3：并行加载设置且无自定义表映射

我们修改了 AWS DMS 任务以使用 并行加载 设置，并去除了自定义表映射。对于四个和八个 Kinesis 分片，设置和结果如下。

对于目标四个分片，使用以下设置实现了每秒700条记录：

jsonParallelLoadQueuesPerThread 1ParallelLoadThreads 4ParallelLoadBufferSize 100

相应的网络吞吐量约为15 MB/s，如下图所示。

对于目标四个分片，使用以下设置实现了每秒1440条记录：

jsonParallelLoadQueuesPerThread 2ParallelLoadThreads 4ParallelLoadBufferSize 100

相应的网络吞吐量约为125 KB/s，如下图所示。

对于目标四个分片，使用以下设置实现了每秒2733条记录：

jsonParallelLoadQueuesPerThread 4ParallelLoadThreads 8ParallelLoadBufferSize 100

相应的网络吞吐量约为25 MB/s，如下图所示。

对于目标八个分片，使用以下设置实现了每秒1450条记录：

jsonParallelLoadQueuesPerThread 1ParallelLoadThreads 4ParallelLoadBufferSize 100

相应的网络吞吐量约为125 MB/s，如下图所示。

对于目标八个分片，使用以下设置实现了每秒1430条记录：

jsonParallelLoadQueuesPerThread 2ParallelLoadThreads 4ParallelLoadBufferSize 100

相应的网络吞吐量约为125 MB/s，如下图所示。

对于目标八个分片，使用以下设置实现了每秒2880条记录：

jsonParallelLoadQueuesPerThread 2ParallelLoadThreads 8ParallelLoadBufferSize 100

相应的网络吞吐量约为275 MB/s，如下图所示。

正如您在这些示例中观察到的，随着我们增加分片数量和并行加载设置中的线程数，吞吐量会增加。如在第1部分中讨论的一般规则是，最佳性能的并行加载线程数应设置为 Kinesis 分片的数量。一个分片支持最多 1 MB/s 的吞吐量；有关更多信息，请参考 Amazon Kinesis 数据流常见问题解答。

场景4：并行加载设置与自定义表映射

在本文中，我们并未展示并行加载设置与自定义表映射的结合效果。由于我们选择主键作为分区键，结果与之前的并行加载设置场景相似。

全量加载测试汇总

以下表格总结了使用四个分片的全量加载测试。

以下表格总结了使用八个分片的全量加载测试。