Cassandra UUID与TimeUUID的优点和缺点

Jac*_*cob 43 uuid cql cassandra cql3 timeuuid

鉴于TimeUUID方便地允许您now()在CQL中使用,是否有任何理由您不会继续使用TimeUUID而不是普通的旧UUID?

The*_*heo 61

UUID并且TIMEUUID以相同的方式存储在Cassandra中,它们实际上只代表两种不同的排序实现.

TIMEUUID列首先按其时间组件排序,然后按原始字节UUID排序,而列首先按其版本排序,然后按时间组件排序为版本1,最后按原始字节排序.奇怪的是,时间组件排序实现在Cassandra代码之间UUIDType和之间重复TimeUUIDType,除了不同的格式.

我认为UUIDvs TIMEUUID问题主要是作为文档:如果你选择TIMEUUID你说你按时间顺序存储东西,并且这些东西可以同时发生,那么一个简单的时间戳是不够的.使用UUID说您不关心订单(即使在实践中,如果您将版本1 UUID放入其中,列将按时间排序),您只需要确保具有唯一ID.

即使使用NOW()生成UUID值很方便,其他人阅读您的代码也会非常令人惊讶.

在宏观方案中它可能并不重要,但是对非版本1 UUID进行排序比版本1快一些,所以如果你有一个UUID列并自己生成UUID,那么去另一个版本.

  • UUID的内容与排序算法的性能无关.非版本1在Cassandra_中更快地排序_因为没有将字节解压缩到时间戳中.这是一个非常非常小的差异,我只是觉得它很有趣. (3认同)

Bas*_*que 24

根据文档, A TimeUUID 一个普通的老.UUID

UUID是一个简单的128位的值.把它想象成一个难以想象的大数字.

特定比特可以通过几种方法中的任何一种来确定.在原始的方法包括采取的MAC地址的计算机的网络硬件,结合当前的日期和时间,再加上任意号码和一个随机数.将所有这些组合在一起以获得几乎唯一的数字.

后来,由于各种原因(安全性,隐私性),在生成UUID值时发明了其他方法来组装比特.这些其他方法省略了日期时间和/或MAC地址作为成分.重点是:并非所有UUID值都具有嵌入的日期时间值.

Cassandra doc错误地将其TimeUUID称为"Type 1 UUID".正确的术语是版本1 UUID.此版本有时称为"基于时间的版本".


一点忠告

Cassandra似乎确定了这个特定版本的UUID,目的是提取128位的日期和时间部分.从UUID中提取日期时间是个坏主意.

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

如果需要跟踪日期时间历史记录,请明确执行此操作.在数据中创建日期时间字段.顺便说一句,跟踪UTC中的日期时间,但这是另一个主题.

  • 同意使用UTC.但是要解决您的其他问题:1)时间戳也会受到时钟漂移的影响,因此在时间序列数据方面,它们并不比TimeUUID好.2)在使用TimeUUID数据类型的CQL3和Cassandra模式的上下文中,期望这些列中的所有UUID都是时间编码的,类型1 UUID是合理的.3)在CQL3中,您可以使用NOW()或特定的日期时间在插入时创建TimeUUID.因此,处理旧数据仍然可以在Cassandra表中产生历史上正确的TimeUUID. (12认同)
  • 为了记录,Cassandra doc明确建议使用ntp来跨所有节点同步系统时间.http://www.datastax.com/documentation/cassandra/1.2/webhelp/cassandra/install/installRecommendSettings.html (3认同)
  • Cassandra 中的 TimeUUID 类型是元数据(与任何 Cassandra 类型一样),允许 Cassandra 知道解释数据(例如获取日期并基于日期或现在创建 UUID)。如果您需要直接访问一行并列出按日期排序的行,则使用它的好处是可以防止数据重复。它仅作为复合键才有意义。如果您有 2 个字段(日期和唯一 id),您将有一个表,先是日期,后是 id(在复合键中)进行排序,第二个是先有 id,后有日期(用于直接访问)。 (3认同)
  • @platforms 将两个不同的目的合并为一个值在原则上是一个坏主意,一个不好的做法。在这种情况下,1. 日期时间历史跟踪和 2. 主键标识符。当您想与其他系统/源/接收器导出或导入数据的那一天到来时,您会后悔的。为了进一步证明不必要的混乱,同时**一无所获**,重新阅读本页的问题! (2认同)
  • 到目前为止,在一个生产系统上一年多没有遗憾,包括数据出口和进口.但我理解你的原则性论点,并同意那种可能影响你意见的关注点分离概念.实际上,为了在Cassandra上索引时间序列数据,我发现使用TimeUUID非常有用.但是,原则上,我会选择任何形式的UUID作为存储时间值的最佳方式吗?没有. (2认同)