Cassandra uuid作为行键

Question

为什么Cassandra键通常被定义为UUID。看起来密钥是在客户端生成的，所以为什么不只是存储为字符串？专门存储为UUID有什么好处？

Answer 1

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

在决定关键格式时还需要考虑其他事项：

• 密钥长度对Cassandra性能有直接影响。保持它们尽可能短，以便它们仍然可用于所需的数据访问。对数据访问无用的短键并不比具有更好的get / scan属性的更长键更好。设计密钥时需要权衡。如果您将长字符串作为键，那么将它们哈希到UUID可能是个好主意。
• 请注意，您可以将UUID存储为具有UUID的人类可读字符串，例如“f5606950-98d1-11e3-a5e2-0800200c9a66”，但更好的方法是使用仅使用16个字节存储它的内部数据类型。
• 您需要先决定是否使用OrderedPreservingPartitioner or RandomPartitioner，有多少权衡取舍，但最重要的是它将如何影响群集中的密钥分配。一个通常使用OrderedPreservingPartitioner，因为它允许进行有意义的扫描，具体取决于它们通常导致热/冷Cassandra节点的键值。为了再次帮助，可以使用原始密钥的哈希值 - UUID，或者使用一些UUID预先添加一个真实的密钥 - 。
• 您打算如何访问密钥，这从简单的get变为slice并过度忽略delete，通常人们会发现UUID是一个很好的妥协
• 您打算如何对数据进行负载均衡

Answer 2

Cassandra Keys可以定义为任何类型（或其组合），因此您不限于UUID。

但至于为什么要在字符串上使用UUID：

UUID是128位。字符串是可变长度，UUID的字符串十六进制表示将需要32个字符。如果您使用的是16位unicode字符，则表示每个密钥需要512位或4倍的空间。

Answer 3

当存在大量行时，这会节省磁盘空间。

如果行数很多，则通过减少从磁盘获取的数据量来提高性能。