AWS Cognito Identity ID 对 SQL 主键的适用性

Question

我正在一个平台上工作，其中唯一用户 ID 是来自 Amazon Cognito 身份池的身份 ID。看起来像这样：“us-east-1:128d0a74-c82f-4553-916d-90053e4a8b0f”

该平台有一个 MySQL 数据库，其中包含一个用户可以查看的项目表。我需要添加一个收藏夹表，其中包含每个用户的每个收藏项。该表可能会增长到数百万行。

“收藏夹”表的布局如下所示：

userID, itemID, dateAdded

其中 userID 和 itemID 一起是一个复合主键。

我的理解是，这种类型的用户 ID（实际上是扩展的 UUID，需要存储为 char 或 varchar）的索引性能很差。因此，不鼓励将其用作数百万行的键或索引。

我的问题是：我的理解是否正确，我是否应该因为这个键而担心以后的性能？我可以采取什么缓解措施来降低性能风险？

我的整体数据库知识不是那么好，所以如果这是一个大问题...将收藏列表移动到 NoSQL 表（其中 userID 作为键将允许恒定的访问时间），并检索一个数组在 SELECT...WHERE IN 查询中使用的收藏项 ID 是可接受的替代方案吗？

非常感谢！

Answer 1

关于 MySQL，如果您使用 UserID 和 CognitoID 组合作为主键，则会对查询性能产生负面影响，因此不建议将其用于大型数据集。

但是，除非您有复杂的查询，否则对 NoSQL DynamoDB 使用这个甚至是 UserID 更合适。您还可以通过 AWS DynamoDB fine-grained access control 与 Cognito 身份池连接来加强安全性。

Answer 2

好的，所以在这里我想说为什么这不好，替代方案以及应用程序的读/写工作流程。

为什么不：这不是一个好的架构，因为如果您的 Cognito 用户池出现问题，您无法为每个单独的用户重新填充相同的 id。此外，Cognito 现在正在更多地区提供；与去年相比。假设您的用户群在印度尼西亚，现在 Cognito 在新加坡可用；您想将您的用户池从东京转移到新加坡；因为延迟问题；不仅你有移动用户的问题；您有填充数据库的问题；因此您的方法缺乏可扩展性、可维护性，并违反了单一责任原则（更新 Cognito 需要您更新数据库，反之亦然）。

替代方案：将db索引留给db域；并使用 username 作为您的数据库和 Cognito 用户池之间的链接。所以：

读取工作流程将是：

1. 用户身份验证：用户进行身份验证并获取令牌。

2. 您的应用程序验证令牌，并从其有效负载中获取用户名。

3. 您的应用根据用户名联系数据库并获取用户信息。

4. 您的应用程序会将用户带到其页面并提供存储在数据库中的信息。

编写工作流程将是：

1. 您的应用使用令牌获取用户的写入请求。

2. 验证令牌。

3. 根据唯一的用户名写入数据库。