我想将以下数据属性存储在DynamoDB中作为统计信息：
deviceId, property, value, timestamp
value属性更改非常频繁，每次更改时都需要将其保存在新项目中。
在检索时，我想查询上述表到：
value和timestamp的所有deviceId和property。property的所有value，timestamp和deviceId 我需要经常检索这些统计信息。
deviceId是唯一的。
我应该如何创建架构？需要考虑什么？ DynamoDB是否最适合此？
答案 0 :(得分：1)
我无法回答DynamoDB是否最适合此操作。
但是，您可以轻松设计一个表来支持这些查询。您可以将deviceId用作哈希键，将compound key的property + timestamp用作范围键。
要获取deviceId的所有属性，时间戳和值，您的查询关键条件表达式应为
deviceId = :deviceId
要获取deviceId和属性的所有时间戳记和值，应为
deviceId = :deviceId AND begins_with(prop_timestamp, :propertyName)
如果您真的很担心空间，并且确定不需要任何其他查询，则可以选择仅具有三个属性，例如
deviceId | prop_timestamp | value
--------------------------------------------------------
38b518f5 | speed_2019-03-05T12:15:00Z | 25.3 m/s
38b518f5 | temp_2019-03-05T12:30:00Z | 65°F
如果您不确定100％不需要任何其他查询，那么除了作为复合范围键的一部分外，我建议将propertyName和timestamp作为其自身的顶级属性。
答案 1 :(得分：1)
DynamoDB是存储很多不确定如何存储数据的好选择。但是当我们谈论关系表中的关系非常大的表时，这并不是最佳选择。
您应该问自己的第一个问题，您知道所有可能的属性吗？还是每台设备可能有10多个独特属性？
您可以创建两个表：
设备：：具有一个主分区键设备ID（数字）和一个属性（不是预定义架构的一部分），该属性是代表字符串的所有属性的字符串列表设备。每个查询都必须从查询该表开始，但是应该非常快速地检索结果，并且存储价格和跳过“扫描”查询的能力应足够。
值：：具有主分区键，该键是设备ID和属性的串联。和时间戳的排序键。该值应该是一个属性。
如果您想加快处理速度并节省存储成本，还可以使此可疑数字成为数字，也可以使用between运算符进行查询。
此解决方案可能比Matthew的答案便宜得多，但人类可读性却低得多，并且可能更难调试和实现。因此，我建议您明智地考虑这两种选择。
此外，最近亚马逊发布了他们的DocumentDB。我没有使用该产品的经验，但是从我对面向文档的数据库的经验来看，这应该是一个不错的选择。一般的想法应该是针对每个设备使用密钥，其中包含属性的子集合（我认为它称为嵌入式或嵌套文档）。如果您需要所有属性，则可以查询键的所有子集合；如果需要特定属性，则可以查询该子集合。但是我仍然没有DocumentDB的经验。但这又是新产品，我没有太多经验，只是指出它存在。