我想将以下数据属性存储在DynamoDB中作为统计信息:
deviceId, property, value, timestamp
value
属性变化非常频繁,每次更改时都需要保存在新项目中。
在检索时,我想查询上述表格:
value
和timestamp
给定的deviceId
和property
。property
,value
和timestamp
给定的deviceId
我需要经常检索这些统计数据。
deviceId
是独一无二的。
我应该如何创建我的架构?需要考虑什么? DynamoDB最适合这个吗?
如果DynamoDB最适合这个,我无法回答。
但是,您可以轻松设计一个表来支持这些查询。您可以使用deviceId
作为您的哈希键,并使用compound key属性+ timestamp作为您的范围键。
要获取deviceId的所有属性,时间戳和值,您的查询键条件表达式将为
deviceId = :deviceId
要获取deviceId和property的所有时间戳和值,它就是
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作为自己的顶级属性。
DynamoDB是存储大量数据的不错选择,您不确定如何存储它。但是当我们在关系数据库中谈论真正的大表关系时,它并不是最优的。
你应该问自己的第一个问题,你知道所有可能的属性吗?或者每个设备可以有10个以上的独特属性?
你可以制作两张桌子:
你也可以使这个连接数字,你也可以使用between
运算符查询,如果你想加快速度和节省存储成本。
这个解决方案可能比Matthew的答案便宜得多,但人类的可读性要低得多,而且调试和实现可能更难。所以,我建议你明智地考虑这两个选项。
此外,最近亚马逊发布了他们的DocumentDB。我对这个产品没有经验,但根据我对面向文档的数据库的经验,你可能应该检查一个很好的选择。一般的想法应该是每个设备的密钥,其中包含属性的子集合(我认为它称为嵌入式或嵌套文档)。如果您需要所有属性,则可以查询密钥的所有子集合,如果需要特定属性,则可以查询子集合。但同样,我没有使用DocumentDB的经验。但同样,这是一个新产品,我没有太多经验,只是指出它存在。