cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serdar Irmak <sir...@protel.com.tr>
Subject RE: UUIDs whose alphanumeric order is the same as their chronological order
Date Fri, 25 Jun 2010 08:18:23 GMT
I think you have to use time in milliseconds + network card number (mac address) + a random
number to genererate a uuid as microsoft .net framework. Iy guarantees uniqueness in a cluster

Serdar

-------------------------------------------------------------
Thanks, Tatu! I'm going ahead with it. Now if something goes wrong I'll say: "But Tatu said..."
(just kidding).

I've replaced Random in the code above with SecureRandom, for that extra dose of randomness
(my biggest worry was that Random self-seeds with System.currentTimeMillis(), and there is
some infinitesimal chance that two servers could start up in the same clock tick). Any thoughts?
On Thu, Jun 24, 2010 at 8:31 PM, Tatu Saloranta <tsaloranta@gmail.com<mailto:tsaloranta@gmail.com>>
wrote:
On Wed, Jun 23, 2010 at 12:18 AM, David Boxenhorn <david@lookin2.com<mailto:david@lookin2.com>>
wrote:
> Tatu, I did read your comments - and I appreciate them very much!
>
> I want someone to argue with me (using good arguments) since what I'm doing
> *does* seem weird to me - because no one else is doing it.
>
> What I mean by readable is that the sort order of my UUIDs are obvious to
> humans.
>
> What I mean by "weird code" is mostly that it doesn't come with enough
> authority that I would trust it as a black-box more than my own code. For
> example, what happens when I want to port it to different kinds of machines?
Ok! It all makes sense -- honestly I just wanted to try to explain why
certain consensus builds, not to argue against your way of doing
things.
I don't think you are missing anything obvious, my suggestions are
really secondary arguments. I think you have good reasons and code
looked solid.

And yes, implementing time-based UUIDs leads to quite a few
complications, if one tries to address all oddities.
This is probably why JDK UUID is so limiting, I assume JDK authors did
not want to deal with such aspects.
And that is why I think that fundamentally random-based variant is
good for the main goal of achieving uniqueness.

> But another thing weird about it is the complexity (and I think low speed)
> of the algorithms I need in my *own* code to use it. Just look at it
> http://wiki.apache.org/cassandra/FAQ#working_with_timeuuid_in_java !
Yes, that is definitely overly complicated (IMO). Perhaps Cassandra
could add convenience methods for mundane things like converting
between java.util.UUID and byte[].
Or authors of nice extension/convenience libraries like Hector (and
others mentioned -- apologies for not listing I just worry I misspell
their names :) )

-+ Tatu +-




- Bu e-posta mesaji kisiye özel olup, gizli bilgiler içeriyor olabilir. Eger bu e-posta mesaji
size yanlislikla ulasmissa, e-posta mesajini kullaniciya hemen geri gönderiniz ve mesaj kutunuzdan
siliniz. Bu e-posta mesaji, hiç bir sekilde, herhangi bir amaç için çogaltilamaz, yayinlanamaz
ve para karsiligi satilamaz. Yollayici, bu e-posta mesajinin - virüs koruma sistemleri ile
kontrol ediliyor olsa bile - virüs içermedigini garanti etmez ve meydana gelebilecek zararlardan
dogacak hiçbir sorumlulugu kabul etmez.
- The information contained in this message is confidential, intended solely for the use of
the individual or entity to whom it is addressed and may be protected by professional secrecy.
You should not copy, disclose or distribute this information for any purpose. If you are not
the intended recipient of this message or you receive this mail in error, you should refrain
from making any use of the contents and from opening any attachment. In that case, please
notify the sender immediately and return the message to the sender, then, delete and destroy
all copies. This e-mail message has been swept by anti-virus systems for the presence of computer
viruses. In doing so, however, we cannot warrant that virus or other forms of data corruption
may not be present and we do not take any responsibility in any occurrence.
 



Mime
View raw message