AWS DynamoDB 分区键设计
AWS DynamoDB Partition Key Design
我读了 ，它澄清了很多事情，但我仍然对应该如何设计我的主键感到困惑。
首先我想澄清一下 WCU 的概念。
我知道 WCU 是每秒最大 1kb 的写入容量。这是否意味着如果写入一条数据需要 0.25 秒，我需要其中 4 条才能支付 1 WCU 的费用？或者每次我写东西它消耗 1 WCU，但我也可以在 1 秒内写 X 次并且仍然被计费 1 WCU？
用法
我想创建一个 table 来存储一组健身房的表单数据（95% 将是豁免，其余将是事件报告）。
大多数时候，每个表单都将通过其唯一 ID 直接访问。我还想按日期、表单、userId等查询表单..
我们可以假设每个健身房平均有 5 万份表格
选项
第一个选项很简单：将 formId 作为分区键。
我不喜欢这个选项的是扫描操作总是会过滤掉 90% 的数据（即来自其他健身房的表格），这对 RCU 不利。
第二个选项是我将 gymId 作为分区键，并为日期、formId、userId 添加排序键。要实施此选项，我需要更多地了解在一个分区键上拥有 50k 条记录的含义。
第三个选项是每个健身房有一个 table，并将 formId 作为分区键。这似乎是目前最好的选择，但我真的不喜欢让大量 table 在我的帐户中做同样的事情。
还有别的选择吗？这三个哪个更好？
编辑：
我假设另一个选项是 SimpleDB?
为你的PK设计。当用户要查找表单时，应用程序有哪些数据？它有 GymID、userID 和 formID 吗？如果是这样，也许可以为 PK 制作一个复合键？所以你的 PK 可能看起来像：
234455::53894302::245
其中23445为GymID，53894302为用户ID，245为表单ID。您甚至可以将表单 ID 移至排序键并连同日期，您可以获得 form::245:: 的 SK。然后，您可以轻松获得该用户的所有表单类型项目，或该用户的所有表单 245。或该用户在 2020 年的所有表格 245，方法是在您的 QUERY 中使用 begins_with() 表达式。
这可能不完全是您应该做的，但请尝试一下，看看您会想到什么选项。需要考虑的一件事是当用户移动健身房时会发生什么？也许在这种罕见的情况下，您会使用新的 gymID 重写数据库中的所有项目。可能你没有PK中的gymID。没有更多信息，很难说。希望这足以让您细细琢磨，以便找到解决方案。
写入 DDB 的每个调用至少消耗 1 个（标准）或 2 个（事务）WCU。假设您的项目小于 1KB。
Item sizes for writes are rounded up to the next 1 KB multiple. For
example, writing a 500-byte item consumes the same throughput as
writing a 1 KB item.
所以一秒写4条需要4个WCU。但是 "burst" 模式意味着您可能暂时能够在仅为 2 WCU 提供的 table 中短时间内每秒写入 4 个项目。
就您提出的选项而言。这取决于。您提到了一些一般访问模式，但没有具体说明，也没有提到这些是否是您唯一需要的。
在 RDBMS 中，您必须提前知道要如何存储数据。但是访问该数据非常灵活。
在DDB中，你必须知道你需要如何访问数据，但是存储结构是灵活的。
一些一般反馈：
- Scan() 是不得已而为之的操作，如果需要的话，应该非常非常少地使用它。
- 分区键的 50K 条记录不是什么大问题。重要的（但比以前少）是您对每个分区键的访问分布情况。理想情况下，您希望在所有分区键之间统一分配访问权限。
- 每个健身房一个 table 是有效的 multi-tenant strategy。但是有 management/overhead 成本。
假设您实际上有多个租户，即。每个健身房都是一个单独的客户。然后我倾向于让 gymid 成为哈希键，这样我就可以利用 article.
中概述的通过 IAM 角色强制执行租户隔离的优势
警告：如果租户 NOT 的大小大致相同，这可能会有问题。但是，less of a problem than it originally was.
我读了
首先我想澄清一下 WCU 的概念。 我知道 WCU 是每秒最大 1kb 的写入容量。这是否意味着如果写入一条数据需要 0.25 秒，我需要其中 4 条才能支付 1 WCU 的费用？或者每次我写东西它消耗 1 WCU，但我也可以在 1 秒内写 X 次并且仍然被计费 1 WCU？
用法
我想创建一个 table 来存储一组健身房的表单数据（95% 将是豁免，其余将是事件报告）。 大多数时候，每个表单都将通过其唯一 ID 直接访问。我还想按日期、表单、userId等查询表单..
我们可以假设每个健身房平均有 5 万份表格
选项
第一个选项很简单：将 formId 作为分区键。 我不喜欢这个选项的是扫描操作总是会过滤掉 90% 的数据（即来自其他健身房的表格），这对 RCU 不利。
第二个选项是我将 gymId 作为分区键，并为日期、formId、userId 添加排序键。要实施此选项，我需要更多地了解在一个分区键上拥有 50k 条记录的含义。
第三个选项是每个健身房有一个 table，并将 formId 作为分区键。这似乎是目前最好的选择，但我真的不喜欢让大量 table 在我的帐户中做同样的事情。
还有别的选择吗？这三个哪个更好？
编辑： 我假设另一个选项是 SimpleDB?
为你的PK设计。当用户要查找表单时，应用程序有哪些数据？它有 GymID、userID 和 formID 吗？如果是这样，也许可以为 PK 制作一个复合键？所以你的 PK 可能看起来像：
234455::53894302::245
其中23445为GymID，53894302为用户ID，245为表单ID。您甚至可以将表单 ID 移至排序键并连同日期，您可以获得 form::245:: 的 SK。然后，您可以轻松获得该用户的所有表单类型项目，或该用户的所有表单 245。或该用户在 2020 年的所有表格 245，方法是在您的 QUERY 中使用 begins_with() 表达式。
这可能不完全是您应该做的，但请尝试一下，看看您会想到什么选项。需要考虑的一件事是当用户移动健身房时会发生什么？也许在这种罕见的情况下，您会使用新的 gymID 重写数据库中的所有项目。可能你没有PK中的gymID。没有更多信息，很难说。希望这足以让您细细琢磨，以便找到解决方案。
写入 DDB 的每个调用至少消耗 1 个（标准）或 2 个（事务）WCU。假设您的项目小于 1KB。
Item sizes for writes are rounded up to the next 1 KB multiple. For example, writing a 500-byte item consumes the same throughput as writing a 1 KB item.
所以一秒写4条需要4个WCU。但是 "burst" 模式意味着您可能暂时能够在仅为 2 WCU 提供的 table 中短时间内每秒写入 4 个项目。
就您提出的选项而言。这取决于。您提到了一些一般访问模式，但没有具体说明，也没有提到这些是否是您唯一需要的。
在 RDBMS 中，您必须提前知道要如何存储数据。但是访问该数据非常灵活。
在DDB中，你必须知道你需要如何访问数据，但是存储结构是灵活的。
一些一般反馈：
- Scan() 是不得已而为之的操作，如果需要的话，应该非常非常少地使用它。
- 分区键的 50K 条记录不是什么大问题。重要的（但比以前少）是您对每个分区键的访问分布情况。理想情况下，您希望在所有分区键之间统一分配访问权限。
- 每个健身房一个 table 是有效的 multi-tenant strategy。但是有 management/overhead 成本。
假设您实际上有多个租户，即。每个健身房都是一个单独的客户。然后我倾向于让 gymid 成为哈希键，这样我就可以利用 article.
中概述的通过 IAM 角色强制执行租户隔离的优势
警告：如果租户 NOT 的大小大致相同，这可能会有问题。但是，less of a problem than it originally was.