cassandra - Cassandra UUID と TimeUUID の利点と欠点

Question

TimeUUIDnow()を CQL で簡単に使用できることを考えると、単純な古い UUID の代わりに常に TimeUUID を使用しない理由はありますか?

Answer 1

documentationによると、 ATimeUUID は普通の古いものです。UUID

UUIDは単純に128 ビットの値です。想像を絶する大きな数と考えてください。

特定のビットは、いくつかの方法のいずれかによって決定することができる。元の方法では、コンピュータのネットワーク ハードウェアのMAC アドレスを取得し、現在の日付と時刻に加えて、任意の数値と乱数を組み合わせていました。これらすべてをまとめて、実質的に一意の番号を取得します。

その後、さまざまな理由 (セキュリティ、プライバシー) から、UUID 値を生成するときにビットを組み立てるための別の方法が考案されました。これらの他の方法では、日時や MAC アドレスが要素として省略されています。要点: すべての UUID 値に日時値が埋め込まれているわけではありません。

Cassandra のドキュメントでは、その TimeUUID が「タイプ 1 UUID」であると誤って言及されています。正しい用語はバージョン 1 UUIDです。このバージョンは「時間ベース バージョン」と呼ばれることもあります。

---

ちょっとしたアドバイス

Cassandra は、128 ビットの日付と時刻の部分を抽出する目的で、この特定のバージョンの UUID を識別しているようです。UUID から日時を抽出することは、悪い考えです。

1 つには、UUID は、このような履歴追跡に使用されることを意図したものではありませんでした。実際、UUID の仕様は、(a) コンピューターの時計をリセットできるため、(b) 後で生成された UUID が実際には以前の UUID よりも早い日時を記録する可能性があることを明確に認識しています。UUID から日時を抽出しないもう 1 つの理由は、時間メソッドによって生成されなかった UUID が存在する可能性があるためです。したがって、実際には日時を表していないビットに基づいてデータ時間値を構築することになります。創造の。3 つ目の理由は、プログラミング コードが後でリファクタリングされるときに、UUID がデータベース レコードとは異なる時点で生成される可能性があるため、UUID の日時を使用すると誤解を招く可能性があるためです。

日時の履歴を追跡する必要がある場合は、明示的に行ってください。データに日時フィールドを作成します。ところで、その日時をUTCで追跡しますが、それは別のトピックです。