二进制vs.字符串vs.数字，用于在DynamoDB分区键中存储UUID？

Question

我正在尝试确定对DynamoDB表的分区键使用二进制，数字还是字符串。我的应用程序是React.js / Node.js社交事件管理应用程序，其中存储在DynamoDB中的数据量的一半将用于存储项目和属性与其他项目和属性之间的关系。例如：用户的朋友，活动的参加者等。

因为架构是如此繁琐，并且由于DynamoDB项的最大大小只有400KB，并且出于性能和成本的原因，我担心密钥占用太多空间。就是说，我想使用UUID作为分区键。有众所周知的原因，对于多个节点分发新密钥的分布式无服务器应用程序，他们更喜欢UUID（或类似的熵级别，并且发生碰撞的可能性很小）。

因此，我认为我的选择是：

1. 使用十六进制编码的UUID（删除破折号后将存储32个字节）
2. 使用base64（22个字节）编码UUID
3. 使用z85（20个字节）对UUID进行编码
4. 对密钥使用二进制类型的属性（16个字节）
5. 对键使用数字类型的属性（16-18字节吗？）-数字类型只能容纳127位，因此我不得不执行一些技巧，例如剥离版本位，但是对于我的应用程序来说可能还可以。请参阅 在Number类型的DynamoDB属性中可以存储多少位整数数据？有关更多信息。

显然，开发人员的经验需要权衡。使用十六进制字符串最清晰，但最大。编码的字符串较小，但在日志记录，调试等过程中更难处理。Binary和Number比字符串更难，但最小。

我确定我不是第一个考虑这些折衷的人。是否有众所周知的最佳实践或启发式方法来确定应如何在DynamoDB中存储UUID密钥？

如果不是，那么我倾向于使用Binary类型，因为它是最小的存储，并且因为它的本机表示形式（作为base64编码的字符串）可以在人类需要查看和推理键的任何地方使用，包括查询，日志记录，和客户端代码。除了必须从一个转换到/ Buffer如果我使用DocumentClient，我错过了一些问题，在上面的列表中的其他选项之一的二进制类型或优势？

如果有问题，我正计划通过Lambda API进行对DynamoDB的所有访问，因此，即使需要进行转换或编组，也可以，因为我可以在我的API中进行操作。

顺便说一句，这个问题是一个已有 4年历史的问题（DynamoDB中的UUID数据类型）的续集，但是4年是一个快速发展的空间中的一个漫长的时间，因此我认为值得再次提出。

Answer 1

我遇到了类似的问题，并得出结论，密钥的大小并不重要，因为我所有的选择都将是小而轻的，只有很小的权衡。我决定采用一种对程序员友好的方式，即我，使用“sub”，即 cognito 为每个唯一用户创建的数字。这样，所有发生的碰撞问题也将由 Cognito 处理。然后我可以编码或不编码。因此，无论用户如何登录，他们最终都会得到“sub”，然后我将其与 dynamodb 的哈希键中的记录进行匹配，这会立即授予他们仅访问其数据的细粒度访问权限。三年后，我发现这是一个非常可靠的方法。