architecture - Cassandra uuid 作为行键

Question

为什么在 Cassandra 中键通常定义为 UUID。看起来 key 是在客户端生成的，那么为什么不直接存储为字符串呢？专门存储为 UUID 有什么好处？

Answer 1

Cassandra 可能有任何键，键是 bytearray。如果客户想要拥有像“foobar”这样的键或任何其他任意长度的字符串，这没有什么问题。 Cassandra 客户端在传输到 Cassandra 服务器之前将其转换为字节数组。从技术上讲，它将在服务器端存储为“foobar”。

在决定 key 格式时还需要考虑其他事项:

• key 长度直接影响 Cassandra 的性能。使它们尽可能短，以便它们仍然可用于所需的数据访问。对数据访问无用的短键并不比具有更好获取/扫描属性的长键好。设计 key 时需要权衡取舍。如果您有长字符串作为键，最好将它们散列到 UUID 中。
• 请注意，您可以将 UUID 存储为人类可读的字符串，该字符串的 UUID 类似于“f5606950-98d1-11e3-a5e2-0800200c9a66”，但更好的方法是使用仅使用 16 个字节的内部数据类型来存储它。
• 您需要决定是否使用 OrderedPreservingPartitioner or RandomPartitioner预先，有许多权衡，但最重要的是它将如何影响整个集群的 key 分配。一个通常与 OrderedPreservingPartitioner 一起使用，因为它允许进行有意义的扫描，这取决于它们通常会导致热/冷 Cassandra 节点的键值。为了再次帮助解决这个问题，要么使用原始 key 的散列 - UUID，要么在一个真正的 key 前面加上一些 UUID - 。
• 你打算如何访问你的 key ，这从简单的 get 到 slice 和过度忽略的 delete，通常人们会发现UUID 是一个很好的折衷方案
• 您打算如何对数据进行负载平衡