cassandra - Cassandra UUID 与 TimeUUID 的优缺点

Question

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

Answer 1

UUID并且TIMEUUID在 Cassandra 中以相同的方式存储，它们仅代表两种不同的排序实现。

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

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

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

从总体上看，这可能并不重要，但是对非版本 1 UUID 进行排序比版本 1 快一点，所以如果您有一个UUID列并自己生成 UUID，请选择另一个版本。

Answer 2

根据文档， ATimeUUID 是一个普通的旧版本。UUID

UUID只是一个128位的值。把它想象成一个难以想象的大数字。

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

后来，出于各种原因（安全、隐私），人们发明了其他方法来在生成 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 仍然比使用时间戳本身更好。如果 uuid 随机性很重要，那么使用 Version/Level 4 UUID 是一个更好的选择，几乎不可能发生冲突。

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

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