我们正尝试通过 AWS 的 DynamoDB 的 NoSQL > IoT 的东西,但是我们不确定关于物品长度或物品插入的最佳实践。
顺其自然,每个设备都可以读取环境数据,具体取决于捕获的数据类型,设备会将“事件的” JSON
消息发送到 IoT 经纪人,然后转到 Lambda 函数,以映射该有效负载,对其进行处理并写入 DynamoDB 表。
然后,每种捕获的事件类型都有一个表,每个从设备接收到的事件消息都有一个表。 但是我们已经意识到那只是另一种伪关系方法。
阅读文档,并只将一张表作为最佳实践,然后将每台设备中的一个项放入其中,并按密钥名称对这些JSON
事件进行分类。
类似的东西:
{
"partition":"<str_an_id>"",
"range":<uint_maybe_a_timestamp>,
"event_soil":[
{<<object with variable length #0},
{<<object with variable length #1}
...
{<<object with variable length #n}
],
"event_humidity":[
{<<object with variable length #0},
{<<object with variable length #1}
...
{<<object with variable length #n}
],
"event_light":[
{<<object with variable length #0},
{<<object with variable length #1}
...
{<<object with variable length #n}
],
"event_temperature":[
{<<object with variable length #0},
{<<object with variable length #1}
...
{<<object with variable length #n}
]
}
当前我们有两个设备,因此随着设备中JSON
负载的增加,我们期望有两个项目在增长。但是,在某个时候,内存阈值已达到,并且来自 DynamoDB 的400
错误代码出现。
这种方法正确吗?还是完全错误?
有什么方法可以知道何时达到该极限?像是某种分页之类的东西?
很难计算出项目大小,因为JSON
对象当前的长度是变化的,并且将来可能会变化。
我们还开始考虑每台设备每隔一到两个月(从理论上讲,我们会加速设备)创建项目。但是,不确定。
答案 0 :(得分:2)
每个设备内部都有一个物品,其中包含一系列按密钥名称分类的JSON事件。
如果我了解上述内容以及代码示例...
我会说你做错了。反复更新一些记录不是一个好主意。除了您似乎认识到的项目空间不足外,您还需要为所需的I / O支付两倍的费用(1读+ 1写)。不知道你是从哪儿得到这个主意的。
对于IoT设备,您似乎正在处理时间序列数据,因此请务必了解Best Practices for Handling Time-Series Data in DynamoDB
也许仅用两种设备就算是过分的了...但是假设您要将该比例大幅提高...
我的第一遍是Partition-Key:“ deviceName#date”,排序键:“ time”
在这种情况下,“日期”可以是完整日期,YYYY-MM-DD,或者仅仅是YYYY-MM,甚至YYYY。将剩余的日期部分移至排序键。一切取决于您期望的数据量。要考虑的是,给定的分区(键)只能存储10GB的数据。
如果您可以将设备的数据保留量限制在10GB以内,那么我将使用设备作为分区键,将日期移至排序键。
修改
重点
2非常重要,假设您选择了给定时间段(过去24小时,上周等),您将要处理给定设备的所有事件,特定类型的所有事件,所有设备的所有事件,或...。
不是您不能完成上述所有操作,但是主要访问权限是什么?
“每次都给我所有数据”每次都是Scan()...肯定不是一种经济有效的访问方法。