Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

UUIDs are popular, but bad for performance (2019)

percona.com

Post reply on HN
Print view View original

91–100 of 246 posts

Re: UUIDs are popular, but bad for performance (2019)

#91

Post by ris »

smoyer wrote: post #67
drenei wrote: post #7

Bad for performance as primary keys . But, still provide strong value as a unique identifier which is what makes them popular. I’ve used integers as primary keys, with UUIDs as alternate keys for external-to-the-data-store queries.

"Bad for performance as primary keys" -> "Bad for performance as primary keys in MySQL". This isn't an issue in PostgreSQL and perhaps the lesson here is that as you scale, you need to understand more about the internals of the DB system you've chosen. This isn't limited to RDBMS as it's pretty easy to show trade-offs in choosing a NoSQL as well.

They are still generally found to be slower to use than sequential primary keys in postgresql.

Re: UUIDs are popular, but bad for performance (2019)

#92

Post by henrydark »

sterwill wrote: post #56
ummonk wrote: post #17

Earlier quoted context omitted.

Yeah S3 has similar performance issues where accessing objects with the same prefixes has lower throughput because they get sharded onto the same server. It's very counterintuitive when you're used to how performance works on single computers where you want to optimize for cache-locality.

This used to be the case, but it's not true any more. For example, previously Amazon S3 performance guidelines recommended randomizing prefix naming with hashed characters to optimize performance for frequent data retrievals. You no longer have to randomize prefix naming for performance, and can use sequential date-based naming for your prefixes. https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimi...

The doc is talking about how the full prefix is now part of the sharding, in contrast to previous times when only the few characters mattered.

But if you put many files with the exact same prefix - even sequential dates - then you hit the threshold the doc says, about 5000 ops/sec.

Re: UUIDs are popular, but bad for performance (2019)

#93

Post by 9wzYQbTYsAIc »

globular-toast wrote: post #79
jitl wrote: post #74

Earlier quoted context omitted.

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.

What? Really? Naïve in this context means a general purpose solution that doesn't "know" about your use case. Have people never heard of a naïve algorithm or solution? Distributed relational databases aren't naïve in this context. MySQL is.

Naive is an emotionally loaded word outside of academic communities.

Re: UUIDs are popular, but bad for performance (2019)

#94

Post by yellowbeard »

qalmakka wrote: post #48

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.

That helps with storage, but still is larger than a bigint, and doesn't help with the random distribution of data. I believe newer versions of MySQL have a data type for this.

Re: UUIDs are popular, but bad for performance (2019)

#95

Post by JimDabell »

globular-toast wrote: post #40
drenei wrote: post #7

Bad for performance as primary keys . But, still provide strong value as a unique identifier which is what makes them popular. I’ve used integers as primary keys, with UUIDs as alternate keys for external-to-the-data-store queries.

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.

> You can't just expect a relational database to magically become a distributed system just by using UUIDs.

Nobody thinks this, do they?

Re: UUIDs are popular, but bad for performance (2019)

#96

Post by nijave »

VWWHFSfQ wrote: post #19
NicoJuicy wrote: post #16

I think the author is missing an overall picture, eg. Event driven scenario's. Where you don't have to check collisions with a db. He mentioned generating the pk's on remote client, but that doesn't capture the interesting bits. You generate the newly created object with the guid. You send it to the API/Microservices and it's generated, fire-and-forget style. And the remote client has an Id of the newly created objec…

But now the remote client has an ID of something that may or may not exist the next time they try to use it depending on whether or not it actually made its way into the database. I've seen this kind of architecture before. It sounds nice but is loaded with consistency problems.

There's patterns for implementing it. It's not really any different than using more than 1 database which is unavoidable in many scenarios (interacting with 3rd parties)

https://chrisrichardson.net/post/sagas/2019/08/04/developing...

Re: UUIDs are popular, but bad for performance (2019)

#97

Post by ryanbrunner »

globular-toast wrote: post #40
drenei wrote: post #7

Bad for performance as primary keys . But, still provide strong value as a unique identifier which is what makes them popular. I’ve used integers as primary keys, with UUIDs as alternate keys for external-to-the-data-store queries.

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.

People use UUIDs for more reasons than just making things distributed. You can generate them client side if that's advantageous, you prevent leaking information about how many records there are in the system and prevent guessing of other potential PKs and potential unauthorized access, and there's some optimization strategies that benefit from not relying on a serial PK.

Re: UUIDs are popular, but bad for performance (2019)

#98

Post by nijave »

VWWHFSfQ wrote: post #47
nchi3 wrote: post #44

Earlier quoted context omitted.

If you get a "Created" back, it is possible for it to be guaranteed that it'll be created eventually.

I don't think you would ever get a 201 Created in an eventual consistency scenario. You would get a 202 Accepted. Unless the API is lying to the clients.

Created can mean different things to different people. Maybe an ecommerce order is created in the sense it's been updated in the inventory database and a record added to some sort of fulfilment system but there's still outstanding data warehouse sync jobs, some order analysis/product recommender job, and some anti fraud jobs (that just need to complete before the order picking in the warehouse begins)

Re: UUIDs are popular, but bad for performance (2019)

#100

Post by sterwill »

henrydark wrote: post #92
sterwill wrote: post #56

Earlier quoted context omitted.

This used to be the case, but it's not true any more. For example, previously Amazon S3 performance guidelines recommended randomizing prefix naming with hashed characters to optimize performance for frequent data retrievals. You no longer have to randomize prefix naming for performance, and can use sequential date-based naming for your prefixes. https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimi...

The doc is talking about how the full prefix is now part of the sharding, in contrast to previous times when only the few characters mattered. But if you put many files with the exact same prefix - even sequential dates - then you hit the threshold the doc says, about 5000 ops/sec.

I re-read your comment and you do say "same" prefixes (I think I read it as "shared"), which AWS hasn't changed the behavior of (AFAIK). You're right that objects with the exact same prefix are still routed to the same shard (set?) and have that throughput limit.

P.S.: In a few projects I've built prefixes using timestamps, but not at the very beginning, and worried that they weren't getting sharded out. The change I linked to fixes that problem.

Post reply on HN