Cassandra uuid 作为行键答案

【问题标题】：Cassandra uuid as row keyCassandra uuid 作为行键
【发布时间】：2014-02-18 18:31:04
【问题描述】：

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

【问题讨论】：

【解决方案1】：

Cassandra 可能有任何密钥，无论如何，密钥都是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 是一个很好的折衷方案
您打算如何对数据进行负载平衡

【讨论】：

【解决方案2】：

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

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

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

【讨论】：

【解决方案3】：

当有大量行时，这可以节省磁盘空间。

当存在大量 if 行时，通过减少从磁盘获取的数据量来提高性能。

【讨论】：