Cassandra uuid作为行键

Question

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

Answer 1

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

但是，为什么你会使用UUID在一个字符串：

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

Answer 2

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

还有其他的事情之一需要考虑的关键方式决定时：

• 密钥长度对Cassandra的性能直接影响。保持它们尽可能短，以便它们对于所需的数据访问仍然有用。对数据访问无用的短密钥并不比具有更好获取/扫描属性的更长密钥更好。设计钥匙时需要权衡。如果你有很长的字符串作为键，那么把它们散列成UUID可能是个好主意。
您可以存储UUID为具有UUID像“f5606950-98d1-11e3-a5e2-0800200c9a66”而是一种更好的主意人类可读的字符串
• 注意是使用，只需占用16个字节来存储它的内部数据类型。
• 你需要做出决定是否使用OrderedPreservingPartitioner or RandomPartitioner前期，有取舍的数量，但什么是最重要的是它将如何影响整个集群密钥分发。通常使用OrderedPreservingPartitioner，因为它允许进行有意义的扫描，具体取决于它通常导致热/冷Cassandra节点的关键值。为了再次提供帮助，要么使用原始密钥的散列 - UUID，要么使用某个UUID预先输入一个真正的密钥。
• 你打算如何来访问你的钥匙，这正好从简单get，以slice和过于忽略delete，人们往往发现，UUID是一个很好的妥协
• 你打算如何进行负载均衡数据

Answer 3

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

当行数较多时，通过减少取出磁盘的数据量来降低性能。