This seems to be just about using UUIDs as indexes in a DB, not using UUIDs in general as an ID for things which I'm not seeing any reason not to continue doing.
UUIDs are popular, but bad for performance (2019)
221–230 of 246 posts
Re: UUIDs are popular, but bad for performance (2019)
#222This seems to be just about using UUIDs as indexes in a DB, not using UUIDs in general as an ID for things which I'm not seeing any reason not to continue doing.
Sure, as long as you never want to look things up or reference them by ID, then there's no reason to worry. Otherwise, yes, you'll have the exact same problems laid out in the article
Re: UUIDs are popular, but bad for performance (2019)
#223This article talks about random IDs leading to page thrashing, and MySQL b-tree indexes not handling them well. They are bad for _MySQL performance_. It doesn't talk about NoSQL or sharding, where random IDs usually perform much better than sequential due to a lack of hot shards. If you distribute your reads and writes at random across N machines you can get ~Nx performance vs one machine. If you make your writes seq…
Sure, but each individual machine still has to do the same slow random lookups, right? Generally you want some deterministic component (for caching) and some random component (for sharding). Snowflakes work well for this, since you can use the upper bits for predictable caching and the lower bits for random entropy.
Re: UUIDs are popular, but bad for performance (2019)
#224People should have a look as k-sortable unique identifiers (KSUID). Binary they are represented by 20 bytes and their string representation has 27 characters, which is shorter than UUIDs since the use a base62 encoding. They are sortable since the 20 bytes start with a 32 bit UNIX timestamp followed by random 128 bits. They should be very efficient for clustered indexes / B+-Trees. Note also that as long as you have…
Sounds like a ULID that doesn't fit in a UUID column - https://github.com/ulid/spec
Re: UUIDs are popular, but bad for performance (2019)
#225Re: UUIDs are popular, but bad for performance (2019)
#226Isn't this easily solved by supporting 128 bit keys and using UUIDs as intended, i.e. as integers and not in their string serialization? This is as nonsensical as storing IPv4 as strings instead of 32 bit integers.
You know what's nonsensical? Assuming one rule of thumb applies everywhere. I will stand by that rule of thumb until I'm cold and in the ground.
Re: UUIDs are popular, but bad for performance (2019)
#227Isn't this easily solved by supporting 128 bit keys and using UUIDs as intended, i.e. as integers and not in their string serialization? This is as nonsensical as storing IPv4 as strings instead of 32 bit integers.
Length isn't the primary issue. Locality is. UUIDs are generally generated randomly. This results in terrible insert performance into B+tree-based indexes, and terrible (= no) lookup locality with basically any database. In a large table, successive entries ends up in separate disk pages. Even with time-based UUIDs, the time fields are ordered backward, which produces the same issue. One way to fix this (beside the m…
there is new uuid versions (draft) that solves the locality problem: https://datatracker.ietf.org/doc/html/draft-peabody-dispatch... (one of the new ones, cant remember which exactly)
Re: UUIDs are popular, but bad for performance (2019)
#228Why would anyone use a random value as a primary key? I haven’t done databases in a long time but isn’t it standard practice to use a sequential incrementing value for the primary key?
reasons are:
1. no need for coordination in distributed system, no need to check what is the next available id.
2. if userid is visible to users, sequential userid gives away information about the amount of users and allows guessing other valid userids.
Re: UUIDs are popular, but bad for performance (2019)
#229Earlier quoted context omitted.
That is…not what universally unique means.
From RFC4122: "A UUID is an identifier that is unique across both space and time, with respect to the space of all UUIDs." Hard to achieve if everyone starts from 00000000-0000-0000-0000-000000000000.
Sequential UUIDs don’t start at 0. They are a 128-bit composite of two integers; a temporal component in the high order bits and a random component in the low order bits.
Re: UUIDs are popular, but bad for performance (2019)
#230Earlier quoted context omitted.
If you're worried about clarity over the phone, you should look into the NATO phonetic alphabet: https://en.wikipedia.org/wiki/NATO_phonetic_alphabet
I prefer to use Aeon, Bdellium, Czar, Djinn, Eye, etc.
The bomb defusal scene in Archer was an absolute classic for this. https://youtu.be/_4jxLxZrMfs