Amazon web services 使用图像时DynamoDB与S3

说到图像，每个人都说使用S3。我知道不同的工具是为不同的目的而构建的，可以理解S3是默认的。但出于教育目的，我很好奇什么时候使用DDB而不是S3会更好

比如说，对于tinder这样的应用程序，您不能将主配置文件图像（比如说image1）存储在具有最高读写容量的ImageTable1中，并将其余5个左右的图像存储在具有低读写容量设置的相应表中。这些表中的每一个都只需要一个哈希键，而不需要排序键

还是这个设计仍然是个坏主意？由于S3的定价与get put请求的数量成正比，而DynamoDB的定价基于预设的读写容量，所以这种设计的成本不是比使用S3低吗

是的，我非常清楚DDB的单个项目大小限制为400kb。因此，对于这个参数，我们假设每个图像都是DDB，不允许大小大于400kb的单个记录。如果您喜欢存储高分辨率图像。使用DDB可能不是最好的方案

DynamoDB中的最大项目大小为400 KB，其中包括 属性名称二进制长度UTF-8长度和属性值 长度再次为二进制长度。属性名称将计入 大小限制

已编辑-考虑到每个图像有100万用户，这会对内存资源提出不必要的加载请求

单个BatchGetItem操作最多可以检索100个项目。 检索到的所有项目的总大小不能超过16 MB

---

任何东西都可以工作，但是S3肯定会是存储图像的首选方法。IMO为此目的使用DDB将是愚蠢的——即使它有效

---

S3非常便宜、冗余，并且具有11 9的可靠性—更不用说您可以将其与cloudfront CDN配对，并在全球范围内将您的图像/内容更靠近您的客户以减少延迟—所有这些都只需点击几下鼠标。

DynamoDB是一个便宜的数据库，但价格比您想象的要贵

我们需要澄清DynamoDB的容量单位到底代表了什么。截至2016年5月，数据以4KB的数据块读取，并以1KB的数据块写入。这意味着单个大对象可能会消耗多个容量单位，而多个小对象在一起查询时可能会消耗单个容量单位

因此，一个100KB的图像需要25个RCU。为了维持每小时50k的图像请求，或~14个请求/秒=14*25=350个RCU，在美国东部，成本为386.59美元/月，远高于S3 14.55美元/月

参考：

其他优点：

浏览器可以通过预先签名的URL直接获取S3对象，这在DynamoDB中是可能的，但通常需要服务器处理； 对象更容易缓存； S3的成本是您消耗的，而不是配置的容量

---

11.9的可靠性也适用于DDB。S3 for 10000 GET req的成本是$0.0004，这对我来说有点意味着它希望您将其用于少量大型项目，但您没有意识到您不能在S3上运行批处理GET请求，对吗？您只能下载一个带有单个get req的对象。S3支持并发。因此，您可以并行工作。因此，一个请求就足以满足整个需求。为了论证起见，每月免费获取请求的数量限制为10k。那么，您是说，由于启用了并发性，每个月可以免费下载超过10k的图像对象？我怀疑这是真的，谢谢。我现在明白了！我不相信当一起查询是正确的时，您的多个微小对象可能会消耗单个容量单位。当阅读你的答案时，听起来好像你在引用多个DynamoDB项目。如果我查询80个1 KB大小的项目，我会消耗80个RCU，而不是20个80个项目*1 KB。@mkobit如果你说的是80个单独的查询，你是对的。请参考我上面提供的参考链接。啊，我想我误解了您对查询的使用，并将其等同于BatchGetItem类型的操作。对于我使用BatchGetItemAPI描述的案例，您将使用80个RCU。对于我使用查询API描述的案例，您将得到20个RCU。