在具有超过 500000 个不同值的 table 分区键上使用 DynamoDB 触发器的 Lambda

Lambda with DynamoDB Trigger on a table Partition Key with more than 500000 distinct values

我们目前正在设计一个 dynamodb table 来存储某些文件属性。有2个主要栏目

目前分区键是日期，排序键是文件名。我们预计每天大约有 500000 个具有不同文件名的文件（这会随着时间的推移而增加）。文件名每天都会重复，即典型的模式如下所示

日期文件名 20190617 abcd.json 20190618 abcd.json

我们有一系列基于 Date 和 dynamodb 触发器的查询。查询效果很好。目前我们正在观察的是并发 lambda 执行的数量限制为 2，因为我们是按日期分区的。在尝试提高 lambda 的并发性时，我们遇到了 2 个解决方案

1) 参考下面的link (https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-partition-key-sharding.html) ，一个想法是为日期字段添加固定数量的随机后缀，即（20190617.1 到 20190617.500）将数据拆分为 500 个分区每个有 1000 条记录。这将确保一定程度的并发性，并且对 query

的更改也将最少

2) 第二个选项是更改 table 的分区，如下所示分区键：- 文件名和排序键：- 日期。这将导致大约 500000 个分区（可以增加）。对于按日期查询，我们需要添加一个 GSI，但我们将在 Lambda 中实现更高的并发性

我们还没有创建具有 500000 个分区（可以增加）的 table。任何人都有这样的经历...如果有请评论

感谢任何帮助

如果您的访问模式是按日期查询，则按文件名分区没有多大意义。

相反，通过添加后缀来增加每个日期的分区数量的想法似乎不错。但是，与其添加随机后缀，不如考虑根据文件名添加稳定的后缀：

您可以使用文件名的第一个字母来获得大约 30 个分区 - 假设文件名是随机的。唯一的问题是有些字母可能比其他字母更常见，给出了倾斜的子分区

或者，您可以获取文件名的哈希值并将其用作分区键的后缀。散列函数可以是一个相对简单的散列函数，它会生成一个目标数值，该数值对应于您希望每个日期拥有的子分区数。

如果每个分区最终有大约 10000-50000 个项目，那可能会很棒。

希望对您有所帮助

你好像误以为分区键和分区是一一对应的。

事实并非如此。

分区数由 table 大小和 through-put 驱动。分区键由 DDB 散列，数据存储在特定分区中。

您可以有 10 万个分区键，而只有一个分区。

如果您正在推动 DDB 的极限，那么是的，您最终可能会在一个分区中只有一个分区键...但这并不常见。

DDB Whitepaper 提供了有关 DDB 工作原理的一些详细信息...