5 ms·

I appreciate where you're coming from, but as it says in the article, UUIDs are really unnecessarily long for no good reason. The traditional hex encoding is a

I appreciate where you're coming from, but as it says in the article, UUIDs are really unnecessarily long for no good reason. The traditional hex encoding is also much longer than it needs to be. In any case, the article exists to help you decide how long you need to make your ids for you to be comfortable. If you decide you aren't comfortable with a 1 in a million chance, the math is there for you to figure out what does work for you.

jacques_chester 12y ago
> UUIDs are really unnecessarily long for no good reason. Their purpose is to be universally unique, presumably indefinitely. The practical choice is to align on a power of 2. When UUIDs were invented, they were based on a MAC address plus a timestamp. MAC addresses are 48 bits, leaving 16 bits. Of these, between 1 and 3 are used up giving the variant code and another four bits are used giving the version code. If they'd used 64 bits, there'd be between 8 and 11 bits left for a unique timestamp. Which is OK, but not a very strong guarantee for a "unique" scheme. As it happens the length has made it possible to create multiple versions of UUIDs that are generated in different ways. UUID has been successful at separating the concerns of the structure of the ID from how it is generated. Most alternative schemes are effectively implementation-defined.
- zackbloom 12y ago
  This is all true, and I'm not here to say the original implementers did anything wrong. As you say though, UUIDs are a general solution, which means they're not going to be optimal for every problem.
  - JoeAltmaier 12y ago
    UUIDs are optimal for every problem, in that they are unique and fairly fast to generate. There can be no better solution than that, except maybe to save a few bits. And we're only talking about 16 bytes here; not much to complain about. They're cheap at the price.
    - JoeAltmaier 12y ago
      Yeah its hard to get folks to come into the modern age of computering. FOr some reason there's tremendous resistance to abandoning the old crusty buggy solutions (indexes and handles that collide and need remapping) and using stuff that just works (identifying everything immutable with a uuid). Folks say 'its too many bits' and 'it takes too long'. Then they proceed to write megabytes worth of patchy code to try and save 64 bits worth of identifier.
      - JoeAltmaier 12y ago
        As for database efficiency, that's a problem. But its a problem with the database - certainly no comfort for the user. But databases could do better, and I think they will one day come to handle uuids with less grief to the developer.
        jacques_chester 12y ago
        They already do. Postgres and SQL Server have UUID types.
        wtbob 12y ago
        Yeah, exactly. Building weakness into one's protocol because of an unhealthy attachment to saving a few bits and an even more unhealthy attachment to MySQL just seems foolish.
    - jayvanguard 12y ago
      If you work with large amounts of data it hugely matters. 16 bytes times 1 billion records ends up being way more than 16GB of data, indexes, foreign keys, hot backup, etc. to manage and query.
      - JoeAltmaier 12y ago
        Even that is a small amount of memory. I have that much RAM on my computer. See, its an obsolete conversation, yet folks raised in an ecology of scarcity can't get past it.
  - jacques_chester 12y ago
    No, but I think most people overoptimise on the shiny stuff ("oooooh, I saved some bits!") over the important stuff (nasty surprises, several years from now).
    - ed0 12y ago
      Yeah, but sometimes "saving some bits" is really important. It's also really inconvenient to work with UUIDS, like in writing SQL queries etc. The solution these guys came up with obviously works for them.
      - scardine 12y ago
        Precisely the argument from Dilbert's Y2K episode: http://www.tv.com/shows/dilbert/y2k-12015/ http://www.tv.com/shows/dilbert/y2k-12015/
      - lmm 12y ago
        How are these eager.io IDs any easier to work with in SQL queries etc.?
      - wtbob 12y ago
        > It's also really inconvenient to work with UUIDS, like in writing SQL queries etc. http://www.postgresql.org/docs/8.3/static/datatype-uuid.html http://www.postgresql.org/docs/8.3/static/datatype-uuid.html makes it look pretty easy…
- tracker1 12y ago
  UUIDs are 128-bits...
  - jacques_chester 12y ago
    > If they'd used 64 bits
wodenokoto 12y ago
Actually I think that is the biggest problem with the article. It gives you no way to asses which probability is good enough.
- zackbloom 12y ago
  I think thats a business decision, not a technical one. You have to decide what odds you are willing to accept, based on how many records you anticipate, how hard it will be to increase the length if that estimation is wrong, and how bad it would be if there was a collision. In any case though, there are certainly many bad things which could happen to your company which are more likely than 1 in a million.

jacques_chester 12y ago

> UUIDs are really unnecessarily long for no good reason. Their purpose is to be universally unique, presumably indefinitely. The practical choice is to align on a power of 2. When UUIDs were invented, they were based on a MAC address plus a timestamp. MAC addresses are 48 bits, leaving 16 bits. Of these, between 1 and 3 are used up giving the variant code and another four bits are used giving the version code. If they'd used 64 bits, there'd be between 8 and 11 bits left for a unique timestamp. Which is OK, but not a very strong guarantee for a "unique" scheme. As it happens the length has made it possible to create multiple versions of UUIDs that are generated in different ways. UUID has been successful at separating the concerns of the structure of the ID from how it is generated. Most alternative schemes are effectively implementation-defined.

zackbloom 12y ago
This is all true, and I'm not here to say the original implementers did anything wrong. As you say though, UUIDs are a general solution, which means they're not going to be optimal for every problem.
- JoeAltmaier 12y ago
  UUIDs are optimal for every problem, in that they are unique and fairly fast to generate. There can be no better solution than that, except maybe to save a few bits. And we're only talking about 16 bytes here; not much to complain about. They're cheap at the price.
  - JoeAltmaier 12y ago
    Yeah its hard to get folks to come into the modern age of computering. FOr some reason there's tremendous resistance to abandoning the old crusty buggy solutions (indexes and handles that collide and need remapping) and using stuff that just works (identifying everything immutable with a uuid). Folks say 'its too many bits' and 'it takes too long'. Then they proceed to write megabytes worth of patchy code to try and save 64 bits worth of identifier.
    - JoeAltmaier 12y ago
      As for database efficiency, that's a problem. But its a problem with the database - certainly no comfort for the user. But databases could do better, and I think they will one day come to handle uuids with less grief to the developer.
      - jacques_chester 12y ago
        They already do. Postgres and SQL Server have UUID types.
        wtbob 12y ago
        Yeah, exactly. Building weakness into one's protocol because of an unhealthy attachment to saving a few bits and an even more unhealthy attachment to MySQL just seems foolish.
  - jayvanguard 12y ago
    If you work with large amounts of data it hugely matters. 16 bytes times 1 billion records ends up being way more than 16GB of data, indexes, foreign keys, hot backup, etc. to manage and query.
    - JoeAltmaier 12y ago
      Even that is a small amount of memory. I have that much RAM on my computer. See, its an obsolete conversation, yet folks raised in an ecology of scarcity can't get past it.
- jacques_chester 12y ago
  No, but I think most people overoptimise on the shiny stuff ("oooooh, I saved some bits!") over the important stuff (nasty surprises, several years from now).
  - ed0 12y ago
    Yeah, but sometimes "saving some bits" is really important. It's also really inconvenient to work with UUIDS, like in writing SQL queries etc. The solution these guys came up with obviously works for them.
    - scardine 12y ago
      Precisely the argument from Dilbert's Y2K episode: http://www.tv.com/shows/dilbert/y2k-12015/ http://www.tv.com/shows/dilbert/y2k-12015/
    - lmm 12y ago
      How are these eager.io IDs any easier to work with in SQL queries etc.?
    - wtbob 12y ago
      > It's also really inconvenient to work with UUIDS, like in writing SQL queries etc. http://www.postgresql.org/docs/8.3/static/datatype-uuid.html http://www.postgresql.org/docs/8.3/static/datatype-uuid.html makes it look pretty easy…
tracker1 12y ago
UUIDs are 128-bits...
- jacques_chester 12y ago
  > If they'd used 64 bits

wodenokoto 12y ago

Actually I think that is the biggest problem with the article. It gives you no way to asses which probability is good enough.

zackbloom 12y ago
I think thats a business decision, not a technical one. You have to decide what odds you are willing to accept, based on how many records you anticipate, how hard it will be to increase the length if that estimation is wrong, and how bad it would be if there was a collision. In any case though, there are certainly many bad things which could happen to your company which are more likely than 1 in a million.