为什么AWS Dynamo SDK不提供存储大于64kb的对象的方法？

Question

我有一个用例，我希望在Dynamo DB中存储大于64kb的对象。如果您实现一种“分页”功能，将对象分成较小的块并将它们存储为密钥的多个值，看起来这样做相对容易实现。

这让我想到了。为什么亚马逊没有在他们的SDK中实现这个？存储大于64kb的物体是不是一个坏主意？如果是这样，那么“正确”的基础设施是什么？

Answer 1

在我看来，这是一个可以理解的权衡DynamoDB。为了高度可用和冗余，他们需要复制数据。为了获得超低延迟，他们允许不一致的读取。我不确定它们的内部实现，但我猜这个64KB上限越高，你的不一致读取可能与项目的实际当前状态过时的时间越长。在超低延迟系统中，毫秒可能很重要。

这推动了查询返回块1和2（但尚未3）到客户端的不一致问题。

根据问题评论，如果您想存储更大的数据，我建议在S3中存储并从DynamoDB中项目的属性引用S3位置。

Answer 2

对于记录，DynamoDB中的最大项目大小现在为400K，而不是问到问题时的64K。

Answer 3

从设计的角度来看，我认为很多可以使用＆gt; 64KB块建模问题的情况也可以转换为可以将这些块拆分为<64KB块的模型。而这通常是更好的设计选择。

E.g。如果你存储一个复杂的对象，你可以把它分成许多集合，每个集合都编码一个对象的各个方面。

这样，对于大型数据集，您可能会获得更好，更可预测的性能，因为查询任何大小的对象都将涉及定义数量的API调用，并且延迟时间上限较低，可预测。

很多时候，服务运营人员很难从系统中获得这种可预测性，以确保在90/95 / 99％的流量范围内给定延迟。 AWS只是选择在API中构建这个约束，因为它们可能已经为他们自己的网站和内部开发做了。

此外，当然从（AWS）实现和调优的角度来看，假设64KB的上限是非常舒服的，因为它允许可预测的内存分页输入/输出，网络往返的上限等。