在 DynamoDB 中使用紧凑属性的存储成本/可支持性/性能权衡

Question

我正在研究生成代表业务实体的唯一/不透明令牌的大规模组件。 随着时间的推移，这些记录将有数十亿条，但我们预计第一年的增长不会超过 20 亿条（可能少于 5 亿条）。

系统本身是水平扩展的，但需要代币生成是幂等的； 通过使用包含但相当复杂的事务写入与嵌入式条件表达式和独立条件检查写入项的组合来维护数据完整性。

令牌本身是 UUID，并且“高效”作为二进制属性值（16 字节）而不是字符串表示形式（36 字节）持久化，但缺点是数据在查询控制台中不能很好地可视化，因此很难支持我们遇到任何错误和/或损坏的数据。 请注意，没有额外的代码复杂性，因为我们实现了attributevalue.Marshaler接口来将UUID （语言）类型绑定到 DynamoDB 二进制属性，并且类似地对任何复合属性执行相同的操作。

我的问题与（主要）数据大小/保存有关。 由于令牌是分区键，并且一些映射列是[token] -> [other token composite attributes] ，例如两个 UUID 连接在一起成为 32 个字节。

我想严格控制存储成本，因为我知道随着时间的推移，我们每个月将为此花费约 0.25 美元/GB。 我的问题实际上是三个部分：

1. PK/SK 索引大小是否“保留”（即填充），因此如果我们将整体字段大小压缩到可能的最小大小，它对存储成本没有任何影响？ （...我在某处读到通常保留 100 个字节。

如果它们被填充，则数据的成本节省将相当高，因为每个（树）索引节点几乎与被映射的数据一样大。 （我假设一旦散列 PK 将查询路由到正确的服务器节点/磁盘等，就会使用树索引。）

2. 将 36 个字节压缩为 16 个字节（除了通过网络节省几个字节之外）是否有任何可观察到的查询时间性能优势？ 即，如果 Dynamo 必须读取更少的页面，它会工作得更快，但实际上我们最多只能说微秒吗？

这是次要问题，但如果对数据有大量并发访问，则值得考虑。 UUID 将分配分区，但不可避免地有时我们会拥有一些比其他分区更活跃的分区。

3. 是否有任何工具可以将字节解析回人类可读的 UUID（或者我们自定义以注入行为来执行此操作）？

这是值得关注的，因为让事情变得更小更高效是可以的，但是如果没有大量的工具投资，支持和解决数据问题将很困难，而且（不出所料）DynamoDB 控制台、DynamoDB IntelliJ 插件和 AWS NoSQL Workbench 都会将二进制文件乱码成不可读的字符。

Answer 1

不，不填充 PK/SK 类型。 每个存储的项目有 100 字节的开销。

发送更少的数据肯定不会影响您的性能。 不过不要指望有明显的改善。 如果较短的值可以使您的项目保持在 1,024 字节而不是 1,025 字节，那么您在保存期间为自己保存了一个写入单元。

对于“乱码”二进制值，我假设您正在查看 base64 编码值，这是一种标准二进制编码标准，可以通过许多工具来反转（现在您知道它的名称）。