8 ms·

I have some complaints about UUIDs. Why not just combining time + random number without the ceremony of UUID versioning. And for when locality doesn't matter, j

I have some complaints about UUIDs. Why not just combining time + random number without the ceremony of UUID versioning. And for when locality doesn't matter, just use a 128bit random number directly. And in my experience most people somehow think a UUID must be stored into the human friendly hex representation, dashes included. Wasting so much space in database, network, memory.

hot_gril 3y ago
The only worthwhile UUID standard IMO is v4 (simple random), and I still don't get why it needs dashes. The other ones don't really accomplish anything.
stronglikedan 3y ago
> combining time + random number You can't guarantee that this will be globally unique.
- ceejayoz 3y ago
  No identifier can guarantee that. We just get close enough to be acceptable. Per Wikipedia, the probability to find a duplicate within 103 trillion version-4 UUIDs is one in a billion. so-youre-saying-theres-a-chance.gif
  - duped 3y ago
    A billion is not that big of a number for UUIDs
    - ceejayoz 3y ago
      Re-read. You'd have to generate 103 trillion to have a one billionth chance of a collision. A billion isn't that big a number, but 103 trillion is.
      - jandrewrogers 3y ago
        I think you made a mistake in your math. The Birthday Collision probability of just a trillion random UUID is much higher than that.
        ceejayoz 3y ago
        Feel free to update https://en.wikipedia.org/wiki/Universally_unique_identifier#Collisions https://en.wikipedia.org/wiki/Universally_unique_identifier#..., but it does note "This probability can be computed precisely based on analysis of the birthday problem". It does show the formula used.
        deathanatos 3y ago
        Wikipedia is correct, AFAICT. The probability of 1 trillion UUIDs having a collision is, def birthday_collision(n, m): return 1 - math.e ** (-((n -1) * n) / (2 * m)) In : birthday_collision(1_000_000_000_000, 2 ** 122) Out: 9.403589018575076e-14 That number is roughly the approximation given in Wikipedia. I.e., at 1T UUIDs, it hasn't happened. For comparison, the odds of being struck by lighting (over a lifetime) is many orders of magnitude greater: 6.535947712418301e-05
  - jandrewrogers 3y ago
    I have single datasets with trillions of UUID. Collision probability becomes a thing. That aside, UUIDv4 is banned in many orgs because there have been several instances in the wild where the “random” number wasn’t nearly as random as advertised from some sources for a variety of reasons, leading to collisions. It is relatively easy to screw this up so many orgs don’t risk it.
    - vore 3y ago
      A 1 in a billion collision probability?
  - deleted 3y ago
    [deleted]
rjh29 3y ago
Many people had the same idea. For example ULID https://github.com/ulid/spec https://github.com/ulid/spec is more compact and stores the time so it is lexically ordered.
jerf 3y ago
While this isn't the worst area I see this in, there does seem to be a tendency in the UUID space to speak as if one use case stands for all and therefore there is a best UUID format. The reality is that it is just like any other engineering situation. Sit down, write down your requirements, and see what, if anything, solves it. Reading about the advantages of various formats is very helpful in helping you skip learning about certain things the hard way and use somebody else's experience of learning them the hard way instead. From that point of view I recommend at least glancing through them all. Sortability and time-based locality is one that you may not naturally think about, and if you need it, you will appreciate not learning that the hard way four years into a project after you threw that data away and then realizing you needed it. And some UUID formats actually managed to introduce small security issues into themselves (thinking MAC address leak from UUID v1 here), nice to avoid those too. If you have a use case where there's an existing solution then, hey, great, go ahead and use it. Maybe if anyone ever needs that but in another language they can pull a library there too. But if not, don't sweat it. The biggest use of UUIDs I personally have I specified as "just send me a unique string, use a UUID library of your choice if it makes you feel better". I think I've got a unique format per source of data in this system and it's fine. I don't have volume problems, it's tens of thousands of things per day. I don't have any need to sort on the UUID, they're not really the "identifier", they're just a unique token generated for a particular message by the originator of the message so we can detect duplicate arrivals downstream in a heterogenous system where I can't just defer that task to the queue itself since we have multiple. I don't even need them to be globally unique, I just need them unique within a rather small shard, and in principle I wouldn't even mind if they get repeated after a certain amount of time (though I left the system enforcing across all time anyhow for simplicity). In this particular case, I do indeed generate my own UUIDs for the stuff I'm originating by just grabbing some stuff from /dev/urandom and encoding it base64, with a size selected such that base64 doesn't end the encoding with ==. Even that's just for aesthetic's sake rather than any actual problem it would cause.
deepsun 3y ago
The worst thing about dashes is you cannot easily double-click it whole to copy-paste.

hot_gril 3y ago

The only worthwhile UUID standard IMO is v4 (simple random), and I still don't get why it needs dashes. The other ones don't really accomplish anything.

stronglikedan 3y ago

> combining time + random number You can't guarantee that this will be globally unique.

ceejayoz 3y ago
No identifier can guarantee that. We just get close enough to be acceptable. Per Wikipedia, the probability to find a duplicate within 103 trillion version-4 UUIDs is one in a billion. so-youre-saying-theres-a-chance.gif
- duped 3y ago
  A billion is not that big of a number for UUIDs
  - ceejayoz 3y ago
    Re-read. You'd have to generate 103 trillion to have a one billionth chance of a collision. A billion isn't that big a number, but 103 trillion is.
    - jandrewrogers 3y ago
      I think you made a mistake in your math. The Birthday Collision probability of just a trillion random UUID is much higher than that.
      - ceejayoz 3y ago
        Feel free to update https://en.wikipedia.org/wiki/Universally_unique_identifier#Collisions https://en.wikipedia.org/wiki/Universally_unique_identifier#..., but it does note "This probability can be computed precisely based on analysis of the birthday problem". It does show the formula used.
      - deathanatos 3y ago
        Wikipedia is correct, AFAICT. The probability of 1 trillion UUIDs having a collision is, def birthday_collision(n, m): return 1 - math.e ** (-((n -1) * n) / (2 * m)) In : birthday_collision(1_000_000_000_000, 2 ** 122) Out: 9.403589018575076e-14 That number is roughly the approximation given in Wikipedia. I.e., at 1T UUIDs, it hasn't happened. For comparison, the odds of being struck by lighting (over a lifetime) is many orders of magnitude greater: 6.535947712418301e-05
- jandrewrogers 3y ago
  I have single datasets with trillions of UUID. Collision probability becomes a thing. That aside, UUIDv4 is banned in many orgs because there have been several instances in the wild where the “random” number wasn’t nearly as random as advertised from some sources for a variety of reasons, leading to collisions. It is relatively easy to screw this up so many orgs don’t risk it.
  - vore 3y ago
    A 1 in a billion collision probability?
- deleted 3y ago
  [deleted]

rjh29 3y ago

Many people had the same idea. For example ULID https://github.com/ulid/spec https://github.com/ulid/spec is more compact and stores the time so it is lexically ordered.

jerf 3y ago

While this isn't the worst area I see this in, there does seem to be a tendency in the UUID space to speak as if one use case stands for all and therefore there is a best UUID format. The reality is that it is just like any other engineering situation. Sit down, write down your requirements, and see what, if anything, solves it. Reading about the advantages of various formats is very helpful in helping you skip learning about certain things the hard way and use somebody else's experience of learning them the hard way instead. From that point of view I recommend at least glancing through them all. Sortability and time-based locality is one that you may not naturally think about, and if you need it, you will appreciate not learning that the hard way four years into a project after you threw that data away and then realizing you needed it. And some UUID formats actually managed to introduce small security issues into themselves (thinking MAC address leak from UUID v1 here), nice to avoid those too. If you have a use case where there's an existing solution then, hey, great, go ahead and use it. Maybe if anyone ever needs that but in another language they can pull a library there too. But if not, don't sweat it. The biggest use of UUIDs I personally have I specified as "just send me a unique string, use a UUID library of your choice if it makes you feel better". I think I've got a unique format per source of data in this system and it's fine. I don't have volume problems, it's tens of thousands of things per day. I don't have any need to sort on the UUID, they're not really the "identifier", they're just a unique token generated for a particular message by the originator of the message so we can detect duplicate arrivals downstream in a heterogenous system where I can't just defer that task to the queue itself since we have multiple. I don't even need them to be globally unique, I just need them unique within a rather small shard, and in principle I wouldn't even mind if they get repeated after a certain amount of time (though I left the system enforcing across all time anyhow for simplicity). In this particular case, I do indeed generate my own UUIDs for the stuff I'm originating by just grabbing some stuff from /dev/urandom and encoding it base64, with a size selected such that base64 doesn't end the encoding with ==. Even that's just for aesthetic's sake rather than any actual problem it would cause.

deepsun 3y ago

The worst thing about dashes is you cannot easily double-click it whole to copy-paste.