我有一个用例，我想在Dynamo DB中存储大于64kb的对象。如果实现一种"分页"功能，将对象划分为更小的块，并将它们存储为键的多个值，这看起来相对容易实现。
这让我思考。为什么亚马逊没有在他们的SDK中实现这一点?存储大于64kb的对象是不是一个坏主意?如果是，什么是"正确的"基础设施?
在我看来，这是DynamoDB做出的一个可以理解的权衡。为了实现高可用性和冗余性，它们需要复制数据。为了获得超低延迟，他们允许不一致的读取。我不确定他们的内部实现，但我猜这个64KB上限越高，您的不一致读取可能与项目的实际当前状态过时的时间就越长。在超低延迟的系统中，毫秒可能很重要。
这将不一致查询返回块1和块2(但还不是块3)的问题推到了客户端。
根据问题评论，如果您想存储更大的数据，我建议存储在S3中，并从DynamoDB中项目的属性引用S3位置。
根据记录，DynamoDB中的最大项目大小现在是400K，而不是问问题时的64K。
从设计的角度来看，我认为许多可以用>64KB块建模问题的情况也可以转换为可以将这些块拆分为<64KB块的模型。这样做通常是更好的设计选择。
。如果您存储一个复杂的对象，您可能会将其分成许多集合，每个集合编码对象的一个不同方面。
这样，对于大型数据集，您可能会获得更好，更可预测的性能，因为查询任何大小的对象将涉及定义数量的API调用，并且延迟的上限较低，可预测。
服务运营人员经常努力从系统中获得这种可预测性，以保证给定的延迟在流量的90/95/99%。AWS只是选择将此约束构建到API中，因为他们可能已经在自己的网站和内部开发中这样做了。
当然，从(AWS)实现和调优的角度来看，假设64KB上限是非常合适的，因为它允许可预测的内存分页进/出、网络往返的上限等。