Dynamo DB 分区键设计：很少有不同的分区键，但始终是唯一的排序键

Question

我是 DynamoDB 的新手，我正在努力设计一个好的分区键。 我读到一个好的 DynamoDB 使用具有几乎不同值的分区键。 尽管如此，我想知道如果我总是能够使用排序键作为唯一标识符（eq 不是开头），我是否可以使用只有约 10 个（不同）值的 DynamoDB 作为分区键。我会遇到这种方法的问题吗？

我的问题如下所示：

1。 假设我想可视化几所房子的房间。每个房间都有物联网设备，这些设备应该在一种“房间地图”中可见。 可视化已完成并以 json 格式存储在本地。我想将此配置存储在 DynamoDB 中。我的 partition key 将是 houses 而 sort key 将是 roomMap_ 的前缀，后跟房间名称（对于当然）

| partition key | sort key            | room map json |
|---------------|---------------------|---------------|
|        House1 | roomMap_livingRoom1 |         {...} |
|        House1 | roomMap_livingRoom2 |         {...} |
|        House1 | roomMap_kitchen     |         {...} |
|        House2 | roomMap_livingRoom1 |         {...} |

2。 现在我还想在 DynamoDB 中存储 IoT 设备的仪表板。 DeviceIds 对于一个 House 来说是唯一的（根据设计），但在其他 House 中可以是相同的。例如。一个设备“fridgeSensor”可能存在于不止 1 个房子里。仪表板配置也存储为 json。

| partition key              | dashboard config json |
|----------------------------|-----------------------|
| House1::fridgeSensor       |                 {...} |
| House1::temperatureSensor1 |                 {...} |
| House2::fridgeSensor       |                 {...} |

---

当我读到良好的 DynamoDB 设计只使用一个表时，我想到了以下表，通过使用第一个表设计的 PartitionKey 并调整排序键：

| partition key | sort key            | room map json | dashboard config json |
|---------------|---------------------|---------------|-----------------------|
|        House1 | roomMap_livingRoom1 |         {...} | null            
|        House1 | roomMap_livingRoom2 |         {...} | null
|        House1 | roomMap_kitchen     |         {...} | null
|        House2 | roomMap_livingRoom1 |         {...} | null
|        House1 | device_fridgeSensor |          null | {...}
|        House2 | device_fridgeSensor |          null | {...}

现在我会经常读取相同的分区键。 这是一个糟糕的设计吗？ 如果是的话，我怎么能做得更好？

Answer 1

您希望为分区键设置许多不同的值有几个原因。

例如，每个分区键被限制为一个最大大小为 10 GB 的存储分区（因此得名）。这意味着如果某个键有很多排序键，导致它需要超过 10 GB 的存储空间，您就会遇到麻烦。

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Limits.html

另外，如果您只有几个分区键并且其中一个非常流行并因此被调用很多，那么您就有一个“热”分区。而且由于您的读/写容量在所有分区上平均分配，您要么付出太多（如果您将 R/W 设置得足够高，给热分区足够的 R/W 和其他分区太多），或者您将受到限制。

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-partition-key-uniform-load.html

请注意，AWS 在 re:Invent 2018 等多个场合表示，他们会自动尝试补偿热分区，而不会给客户带来任何额外费用。但不要指望太多。

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-partition-key-design.html#bp-partition-key-throughput-bursting

但在您的情况下，除非一所房子将拥有数千个设备/房间，或者一所或几所房子的数据非常受欢迎，否则我并没有真正看到问题。

需要注意的一点是 json 文件的大小（房间地图、仪表板配置）。如果这些文件变得太大，AWS 中的常规方法是将它们存储在 S3 中，并将它们的位置/ID 添加到 DynamoDB 中。在这种情况下，如果您需要这些文件，您可以获取 id 并转到 S3 来查找它。