Amazon dynamodb JSON格式如何影响存储和容量单位

我有一个关于DynamoDb的基本问题——缩短属性名和删除空白是否值得，以节省吞吐量和存储

我计划存储数以百万计的类似以下内容的项目：

{
  "currency": "USD",
  "openPrice": 0.1,
  "closePrice": 0.1,
  "highPrice": 0.1,
  "lowPrice": 0.1
}

{"c":"USD","op":0.1,"cp":0.1,"hp":0.1,"lp":0.1}

如果我将此JSON片段重新格式化为如下所示：

{
  "currency": "USD",
  "openPrice": 0.1,
  "closePrice": 0.1,
  "highPrice": 0.1,
  "lowPrice": 0.1
}

{"c":"USD","op":0.1,"cp":0.1,"hp":0.1,"lp":0.1}

这种较短的JSON是否会因为较低的存储和较低的吞吐量单元而节省成本

---

谢谢。

是的，属性名称被分解到项目总大小中。这在以下两种情况之一中变得非常重要：

如果您的访问模式涉及扫描；或者查询，希望检索多个项目-因为在这些情况下，您将按聚合大小（即所有访问项目的总和）计费，因此小项目比大项目更有效地使用消耗的容量

如果您的项目具有许多属性，因此属性名称的大小及其值的大小会将项目总大小推过1KB边界-这一点很重要，因为写入容量是以1KB为增量计费的

---

我会在命名时使用常识：更喜欢简洁的命名，但尽量避免使用晦涩的名称（例如，

c

不是一个好名字，但

customerDataItemIdentifier

——更好的选择可能是

custId

）

是的，这样可以节省容量单位。但是，使用上述属性名称无法识别任何内容。如果是一次性的或寿命很短的解决方案，您可以继续使用。否则，将很难管理上述数据模型。DynamoDB中的最大项目大小是400KB，而不是1KB。这对于扫描和查询也很重要，还有另一个原因：每次调用返回的数据最多为1MB。@Dunedan是的，但容量的计费增量为1KB用于写入，4KB用于读取。因此，虽然一个项目的大小可能高达400KB，但相对而言，很难想象属性名称会起到多大作用。但是，属性名称可以很容易地将一个项推到1KB阈值以上，这将导致单个项消耗2个容量单位进行写入，而不是仅消耗一个容量单位。