Cassandra UUID与TimeUUID的优缺点

Question

既然TimeUUID允许你在CQL中使用now()，你有什么理由不直接使用TimeUUID而不是普通的旧UUID呢？

Answer 1

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

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

我认为UUID与TIMEUUID的问题主要是文档:如果您选择TIMEUUID，则表示您将按时间顺序存储数据，并且这些数据可以同时发生，因此简单的时间戳是不够的。使用UUID表示您不关心顺序(即使在实践中，如果您将版本1的UUID放入列中，列将按时间排序)，您只想确保事物具有惟一的ID。

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

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

Answer 2

根据documentation的说法，TimeUUID是一种普通的老式UUID。

A is a .把它想象成一个难以想象的大数字。

特定比特可以通过几种方法中的任何一种来确定。original method包括获取计算机网络硬件的MAC address，将当前日期和时间加上一个任意数和一个随机数。把所有这些放在一起，得到一个几乎唯一的数字。

后来，出于各种原因(安全性、私密性)，发明了其他方法来在生成UUID值时组合这些位。这些其他方法省略了日期-时间和/或MAC地址作为一个组成部分。问题是:并不是所有的UUID值都嵌入了日期-时间值。

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

A Bit Of Advice

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

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

如果需要跟踪日期-时间历史记录，请显式执行。在数据中创建日期-时间字段。顺便说一下，在UTC中跟踪该日期-时间，但这是另一个主题。

Answer 3

总而言之，你需要生成一些来相信它们。Timeuuid是版本/级别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