Cassandra UUID 与 TimeUUID 的优缺点

Question

鉴于 TimeUUID 允许您轻松地在 CQL 中使用 now()，您是否有任何理由不继续使用 TimeUUID 而不是普通的旧 UUID？

Answer 1

UUID和TIMEUUID在Cassandra中的存储方式相同，它们只是真正代表了两种不同的排序实现。

TIMEUUID 列首先按其时间分量排序，然后按其原始字节排序，而 UUID 列首先按其版本排序，然后如果两者都是版本 1，则按其时间分量排序，最后按其原始字节排序字节。奇怪的是，Cassandra 代码中的时间分量排序实现在 UUIDType 和 TimeUUIDType 之间重复，但格式不同。

我认为UUID 与TIMEUUID 的问题主要是文档：如果您选择TIMEUUID，您是在说您按时间顺序存储内容，并且这些内容可以同时发生，所以一个简单的时间戳是不够的。使用 UUID 表示您不关心顺序（即使在实践中，如果您将版本 1 UUID 放入其中，列将按时间排序），您只想确保事物具有唯一的 ID。

即使使用NOW() 生成UUID 值很方便，但阅读您的代码的其他人也很惊讶。

在总体方案中可能无关紧要，但是对非版本 1 UUID 进行排序比版本 1 快一点，所以如果您有一个 UUID 列并自己生成 UUID，请选择另一个版本.

Answer 2

TimeUUID 是根据documentation，一个普通的旧UUID。

UUID 只是一个128-bit value。 将其视为一个难以想象的大数字。

可以通过几种方法中的任何一种来确定特定位。 original method 涉及获取计算机网络硬件的MAC address，结合当前日期和时间，加上任意数字和随机数字。将所有这些压缩在一起以获得几乎唯一的数字。

后来，出于各种原因（安全、隐私），人们发明了其他方法来在生成 UUID 值时组装这些位。这些其他方法省略了日期时间和/或 MAC 地址作为成分。重点是：并非所有 UUID 值都具有嵌入的日期时间值。

Cassandra 文档错误地将其 TimeUUID 称为“Type 1 UUID”。正确的术语是版本 1 UUID。这个版本有时被称为“基于时间的版本”。

---

一点建议

Cassandra 似乎识别出这个特定版本的 UUID 是为了提取 128 位的日期和时间部分。从 UUID 中提取日期时间是一个坏主意。

一方面，UUID 从未打算用于此类历史跟踪。实际上，UUID 的规范特别认识到 (a) 计算机时钟可以重置，因此 (b) 稍后生成的 UUID 可能实际上记录了比以前的 UUID 更早的日期时间。不从 UUID 中提取日期时间的另一个原因是，您很可能拥有不是由 time 方法生成的 UUID，因此您将基于实际上不代表日期时间的位构建数据时间值的创造。第三个原因是，当以后重构编程代码时，UUID 的生成时间可能与数据库记录不同，因此使用 UUID 的日期时间会产生误导。

如果您需要跟踪日期时间历史记录，请明确执行。在您的数据中创建一个日期时间字段。顺便说一句，在 UTC 中跟踪那个日期时间，但这是另一个话题。

Answer 3

总而言之，你需要产生一些来相信它们。 Timeuuids 是版本/级别 1 UUID 似乎只随机化前 8 个字符，如下所示，因此，存在一些冲突的可能性，但仍然是 timeuuid is better than using timestamp 本身。如果 uuid 随机性很重要，使用版本/级别 4 UUID 是一个更好的选择，几乎是improbable collision。

因此，如果您不关心分区之间的唯一性，并且您的分区是具有高写入量的宽行时间序列数据，并且每个事件（时间）需要一些唯一标识符，那么它是一个不错的选择，它还具有聚类、分页等的好处。

insert into test_tuuid(1, now())
insert into test_tuuid(1, now())
insert into test_tuuid(1, now())
insert into test_tuuid(1, now())

49cbda60-961b-11e8-9854-134d5b3f9cf8
49d1a6c1-961b-11e8-9854-134d5b3f9cf8
49d59e61-961b-11e8-9854-134d5b3f9cf8
49d8d2b1-961b-11e8-9854-134d5b3f9cf8