71–80 of 246 posts
Isn'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.
I might be misunderstanding something here but if your random seed is based on time, under high-concurrency, doesn't this risk collisions? I can't see any thread-safety guarantees in the documentation.[1]
[1] https://dev.mysql.com/doc/refman/8.0/en/mathematical-functio...
Earlier quoted context omitted.
Yeah. The main problem is people using them as primary keys in naïve systems like relational databases. You can't just expect a relational database to magically become a distributed system just by using UUIDs. There is a bit more work to do than that.
Is it too much to ask people to explain what's wrong with this well-written and on-topic comment instead of downvoting it?
I use UUIDs but I don’t know why they would magically make my Postgres a distributed system. I like them because the client can generate them offline.
Often 32 bit integers are anyway not long enough as a primary key, so you need at least 64 bit keys. UUID is just double the size then.
Earlier quoted context omitted.
> Additionally using the less cryptographically secure uuid v1 can be a performance optimization since it has implicit time based sorting. Except the way the fields are laid out basically defeats the point: UUIDv1 lays a 60 bits timestamp starting from the lower 32 bits, so it only sorts within a 7 minutes (2*32 * 100ns) bucket. Hence the proposal for UUIDv6, which lays the exact same timestamp in reverse order (star…
Huh, you're right. I guess I gotta message an old coworker and tell them their "perf optimization" didn't work. Lesson learned, thanks!
Alternatively, it's possible that they created pseudo-UUIDv1 by hand putting data in UUIDv6.
Is this specific to MySQL or does it apply to Postgres too?
As far as I can gather from this post and looking at the data type documentation, MySQL does not have a specific UUID type, but Postgres does.[0] I'll assume that Postgres has some internal optimisations to UUID that MySQL thus lacks. Addendum: I also realise this is anecdotal, but someone on Stackoverflow mentions a significant speed up from changing `text` to `uuid` in Postgres.[1] But this also fits with what I've…
Earlier quoted context omitted.
Yeah. The main problem is people using them as primary keys in naïve systems like relational databases. You can't just expect a relational database to magically become a distributed system just by using UUIDs. There is a bit more work to do than that.
Is it too much to ask people to explain what's wrong with this well-written and on-topic comment instead of downvoting it?
Nobody is assuming simply adding a UUID transforms a system into a distributed one.
The parent comment is about exposing UUIDs probably in order to not expose the sort order of the database.
Earlier quoted context omitted.
Is it too much to ask people to explain what's wrong with this well-written and on-topic comment instead of downvoting it?
Calling relational databases (HN’s preferred storage system) naive probably sounds like trolling to most people. There are also plenty of distributed relational databases. People downvote comments that sounds like trolling or flamebait. I use UUIDs but I don’t know why they would magically make my Postgres a distributed system. I like them because the client can generate them offline.
Distributed relational databases aren't naïve in this context. MySQL is.