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