java如何实现到DynamoDB的大规模迁移的更好吞吐量？
我一直在运行一个大型数据迁移到dynamo的测试，我们打算在今年夏天的prod帐户中进行该测试。我运行了一个测试，将大约32亿个文档批量写入我们的dynamo表，该表有一个散列键和范围键以及两个部分索引。每个文档都很小，不到1k。虽然我们成功地在大约3天内完成了这些项目，但我们对迪纳摩的表现感到失望，我们正在寻找如何改进的建议
为了进行此迁移，我们使用了2个ec2实例（c4.8XL）。每个进程最多运行我们迁移计划的10个进程；我们已经通过一些内部参数在进程之间划分了工作，并且知道一些进程将比其他进程运行更长的时间。每个进程都会查询我们的RDS数据库中的100000条记录。然后，我们将它们分成25个分区，并使用10个线程的线程池来调用DynamodbJavaSDK的batchSave（）方法。每个对batchSave（）的调用只发送25个文档，每个文档少于1k，因此我们希望每个调用只向AWS发出一个HTTP调用。这意味着在任何给定的时间，我们可以在一台服务器上有多达100个线程，每个线程调用25条记录的batchSave。在这段时间内，我们的RDS实例很好地处理了对它的查询负载，我们的2个EC2实例也处理得很好。在ec2方面，我们没有最大化cpu、内存、网络输入或网络输出。我们的写操作并不是按散列键分组的，因为我们知道，散列键可以减慢dynamo写操作的速度。通常，在一组100000条记录中，它们被分割成88000个不同的散列键。我最初创建的dynamo表具有30000个写吞吐量，但在测试期间的一个点上配置了40000个写吞吐量，因此我们的理解是dynamo端至少有40个分区来处理这个问题
在此期间，我们在对dynamo的batchSave（）调用中看到了非常多变的响应时间。当我为每个ec2实例运行100个线程时，在20分钟的时间跨度内，平均时间为0.636秒，但中位数仅为0.374秒，因此我们接到了很多超过1秒的呼叫。我希望在从EC2实例调用dynamo所需的时间内看到更多的一致性。我们的dynamo表似乎配置了大量的吞吐量，EC2实例的CPU低于10%，网络进出看起来很健康，但还没有接近最大化。控制台中的CloudWatch图形（非常糟糕…）未显示写入请求的任何限制
在我进行了这些采样之后，我们的一些进程完成了它们的工作，因此我们在ec2实例上运行的线程更少。当这种情况发生时，我们看到对dynamo的呼叫响应时间大大缩短。e、 g.当我们在ec2实例上运行40个线程而不是100个线程时，每个线程都调用batchSave，响应时间提高了5倍以上。然而，即使响应时间增加了，我们也并没有看到写吞吐量的提高。似乎无论我们将写吞吐量配置成什么，我们都从未真正看到实际吞吐量超过15000
我们想要一些关于如何在像这样的Dynamo迁移中获得更好性能的建议。当然，我们今年夏天的生产迁移将是时间敏感的，到那时，我们将希望迁移大约40亿条记录。有人对我们如何实现更高的整体吞吐量有什么建议吗？如果我们愿意在迁移期间为我们的主索引支付30000个写吞吐量单位，那么我们如何真正实现接近这一点的性能呢
# 1 楼答案
BatchWrite延迟的一个组成部分是批处理中耗时最长的Put请求。考虑到您必须循环查看DynamoDBMapper的列表。FailedBatch为空之前，您的进度可能不够快。考虑运行多个并行的{a1}调用，而不是批处理保存，这样您就可以独立地为每个写入的项目取得进展。
同样，Cloudwatch指标是1分钟的指标，因此您可能会有被1分钟窗口掩盖的消耗和节流峰值。更为复杂的是，默认情况下，SDK将在向客户端公开ProvisionedThroughPuteExceedeDexception之前重试限制调用10 times，这使得很难确定实际限制发生的时间和地点。为了提高您的理解，请尝试减少SDK重试次数，请求ConsumedCapacity=TOTAL，使用rate-limited scan blog post中所述的Guava RateLimitor自动调节写入，并记录受限制的主键，以查看是否出现任何模式
最后，表的分区数量不仅取决于您在表上提供的读写容量单元的数量。它还受存储在表中的数据量的影响。通常，一个分区最多存储10GB的数据，然后将被拆分。因此，如果只写入表而不删除旧条目，那么表中的分区数量将不受限制地增长。这会导致IOPS不足-即使您提供40000个WCU/s，如果由于数据量的原因已经有80个分区，40k WCU将分布在80个分区中，平均每个分区500个WCU。要控制表中过时数据的数量，可以使用速率有限的清理过程来扫描和删除旧条目，或者使用rolling time-series tables（幻灯片84-95）并删除/迁移整个数据表，因为它们变得不太相关。滚动时间序列表的成本低于速率限制清理，因为您不使用DeleteTable操作使用WCU，而每个DeleteItem调用至少使用1个WCU