二进制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位，因此我必须执行一些技巧，例如粘贴版本位，但是对于我的应用程序来说好。看到 How many bits of integer data can be stored in a DynamoDB attribute of type Number?了解更多信息。

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

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

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

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

顺便说一句，这个问题是一个已有4年历史的问题（UUID data type in DynamoDB）的续集，但是4年是在一个快速发展的空间中的一次漫长的时光，所以我认为值得再次提出来。

Answer 1

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