【问题标题】:How to deal with limit size when reached at AWS DynamoDB?在 AWS DynamoDB 达到限制大小时如何处理?
【发布时间】:2019-08-18 10:50:04
【问题描述】:

我们正在尝试利用 AWSDynamoDBNoSQL >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 对象目前的长度不同,并且将来可能会有所不同,因此很难引入计算项目大小的数学方法。

我们还开始考虑每台设备每隔一两个月(理论上因为我们加速设备)创建项目。但是,不确定。

【问题讨论】:

  • 错误代码400 与内存无关。当访问被拒绝时引发。
  • Item size to update has exceeded the maximum allowed size (Service: AmazonDynamoDBv2; Status Code: 400; Error Code: ValidationException; Request ID: AKQESTATUSCODEFROMDYNAMODBEZ)
  • 最大项目大小为 400KB,相当大。通常在该大小下,您处理的是 JSON 文件,而不是项目,并且可以将其保存到 S3。如果你真的需要这么大的项目,那么可能会沿着事件类型进一步划分它们,例如分区键可以是 uuid-soil、uuid-湿度。
  • 确实@jamod,并且正在考虑该选项,但押注于正确使用 NoSQL。

标签: python amazon-web-services aws-lambda amazon-dynamodb aws-iot


【解决方案1】:

每个设备在其内部增长一个项目,其中包含按密钥名称分类的 JSON 事件数组。

如果我理解以上内容,以及代码示例...

我会说你做错了。反复更新一些记录不是一个好主意。除了您似乎认识到的项目空间不足之外,您还需要为所需的 I/O 支付两倍的费用(1 次读取 + 1 次写入)。不知道你的想法是从哪里来的..

对于物联网设备,好像你在处理时间序列数据,所以一定要了解Best Practices for Handling Time-Series Data in DynamoDB

也许只用两台设备就有点过头了……但假设你要大幅扩大规模……

我的第一遍是 Partition-Key:“deviceName#date”,排序键:“time”

在这种情况下,“日期”可以是完整的日期,YYYY-MM-DD,或者只是 YYYY-MM,甚至是 YYYY。将剩余的日期部分移动到排序键。一切都取决于您期望的数据量。需要考虑的是给定的分区(键)只能存储 10GB 的数据。

如果您可以将设备的数据保留限制在 10GB 以下,我只会使用设备作为分区键,将日期移动到排序键。

编辑
重点

  1. 了解将生成(写入)多少数据
  2. 了解您的应用如何将这些数据呈现给用户
  3. 一个分区提供 10GB 的数据存储和 3000 个 RCU/1000 个 WCU
  4. 您只能查询()给定的分区。 (PartitionKey == "某事")

2 非常重要,假设您选择给定时间段(过去 24 小时、上周等),您是否要处理给定设备的所有事件、某种类型的所有事件、所有设备的所有事件,或 ....

并不是说您不能做到以上所有,但主要访问权限是什么?

“永远给我所有数据”每次都是 Scan()...当然不是一种经济高效的访问方法。

【讨论】:

  • 好的,它建议每个时间序列完成创建一个新表,比如工作一年左右。但这变得令人困惑,因为 NoSQL 的建议是利用 NoSQL 的优点来利用表的数量和它们之间的交叉引用。因此,我们目前正在分析您在一张桌子上建议的第一关。在选择适合这种情况的排序键格式时变得很棘手。
  • @jon "one table" 并不总是意味着单个物理表......而是将其视为单个逻辑表;物理表之间没有“关系”。在时间序列数据的情况下,考虑到场景的预期工作负载,多个物理表只是一种节省成本的措施。如果一张实体桌子适合你,那么一定要走那条路。
  • 如果您可以删除旧表而不是删除内容,则每个间隔创建一个新表会很有帮助。 TTL 功能允许您在不消耗写入容量的情况下删除旧记录,因此现在不太需要滚动表。
  • @Charles,我正在阅读 AWS 文档,在 AWSYoutube 上观看设计教程。对于这些情况,他们确实推荐了时间序列表。 [aws.amazon.com/blogs/database/… 解释说,尽管 NoSQL 存在反模式,但它可以节省成本。所以,这就产生了一个问题。是否建议每种类型的事件有一个表,比方说,每年每个设备都有一个分区键?为了避免多表?还是以设备 uuid 作为分区键的每年每个事件的表?
  • @jon 没有一个正确的答案,如果您需要永远保持数据可用,那就这样做吧。在 DDB 或其他东西中,例如 S3。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-02-05
  • 2013-03-17
  • 2021-03-27
  • 1970-01-01
  • 2022-11-23
相关资源
最近更新 更多