Cassandra UUID與TimeUUID的優點和缺點

Question

考慮到TimeUUID可以輕鬆地在CQL中使用now()，是否有任何理由不會直接繼續並始終使用TimeUUID而不是普通的舊UUID？

Answer 1

UUID and TIMEUUID在Cassandra中的存儲方式相同，它們只代表兩種不同的排序實現。

TIMEUUID列可以通過時間的成分的第一排序，然後被其原始字節，而UUID列通過其版本第一排序，然後如果兩者都可以通過時間成分版本1，最後可以通過原始字節。奇怪的是，時間組件排序實現在Cassandra代碼中的UUIDType和TimeUUIDType之間重複，除了不同的格式。

我想到UUID與TIMEUUID主要作爲文檔的問題：如果您選擇TIMEUUID，則表示您按時間順序存儲事物，並且這些事件可能會同時發生，所以僅使用簡單的時間戳是不夠的。使用UUID表示您不關心訂單（即使在實踐中，如果您將版本1的UUID放入列中，列將按時間排序），您只需確保事物具有唯一的ID。

即使使用NOW()生成UUID值很方便，其他人閱讀您的代碼也很令人驚訝。

在事物的宏觀方案中，這可能並不重要，但排序非版本1 UUID比版本1快一點，所以如果你有一個UUID列並自己生成UUID，請轉到另一個版本。

Answer 2

​​一個是一個普通的舊UUID根據documentation。

A UUID只是一個128-bit value。認爲它是一個難以想象的大數目。

特定位可以通過幾種方法中的任何一種來確定。 original method涉及到計算機網絡硬件的MAC address，結合當前的日期和時間，再加上一個任意數字和一個隨機數。把所有這些都擠在一起得到一個幾乎獨一無二的號碼。後來，出於各種原因（安全性，隱私），在生成UUID值時發明了其他方法來組裝比特。這些其他方法省略了日期時間和/或MAC地址作爲成分。問題是：並非所有的UUID值都有嵌入的日期時間值。

Cassandra文檔錯誤地將其TimeUUID引用爲「類型1 UUID」。正確的術語是版本1 UUID。這個版本有時被稱爲「基於時間的版本」。

---

一些建議

卡桑德拉似乎識別UUID的該特定版本用於提取128比特的日期和時間部分的目的。從UUID中提取日期時間是不好主意。

首先，UUID從未打算用於這種歷史跟蹤。的確，UUID的規範特別認識到（a）計算機時鐘可以被重置，因此（b）稍後生成的UUID實際上可以記錄比先前的UUID更早的日期時間。不從UUID中提取日期時間的另一個原因是因爲您可能擁有不是由時間方法生成的UUID，因此您將根據實際上不代表日期時間的位構建數據時間值的創作。第三個原因是，當編程代碼稍後重構時，UUID可能會在與數據庫記錄不同的時間生成，因此使用UUID的日期時間會產生誤導。

如果您需要跟蹤日期時間歷史記錄，請明確執行。在您的數據中創建一個日期時間字段。順便說一句，在UTC追蹤日期時間，但這是另一個話題。