UUIDs are popular, but bad for performance (2019) • Hacker News Board

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

#31

Post by NicoJuicy » Sat, Jan 08, 2022, 10:37 AM UTC

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.

That's why the pattern is eventual consistency.

You receive a message "{entity}Created" and it contains the Id of the full object.

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

#32

Post by manuelabeledo » Sat, Jan 08, 2022, 10:37 AM UTC

gls2ro wrote: post #23

A lot of things that we do for security or privacy are bad for performance, but I think they are still good tradeoffs.

And for data safety as well.

In an environment where millions of events are processed every second, being able to uniquely identify them is a must, and temporal keys are not always an option.

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

#33

Post by bowmessage » Sat, Jan 08, 2022, 10:41 AM UTC

nielsole wrote: post #30

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.

Ugh really? Why would they not hash the whole filename for shard assignment?

Because the file name includes the "directory" prefix, i.e. each file's name stores the `/entire/bucket/dir/tree`, which can get large.

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

#34

Post by VWWHFSfQ » Sat, Jan 08, 2022, 10:42 AM UTC

NicoJuicy wrote: post #31

VWWHFSfQ wrote: post #19

Earlier quoted context omitted.

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.

That's why the pattern is eventual consistency. You receive a message "{entity}Created" and it contains the Id of the full object.

It's like, _maybe_ eventual consistency. Hopefully the client doesn't try to do anything important with the ID/new object

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

#35

Post by globular-toast » Sat, Jan 08, 2022, 10:44 AM UTC

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.

Well, you would have some kind of synchronisation protocol where the database confirms it has received that record and it now exists.

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

#36

Post by Borealid » Sat, Jan 08, 2022, 10:45 AM UTC

Aardwolf wrote: post #27

> The missing 4 bits is the version number used as a prefix to the time-hi field. Why would you use 4 bits for a version number in something that's supposed to be unique? What is the benefit of following this specification despite such cost, versus creating 128 unique bits based on time / random generators / machine IDs yourself?

The ability to mix different types of ID in one column or one business data store.

When you start with random UUIDs, and then decide you actually wanted per-host-namespaced ones halfway through, if you have allocated zero bits for the version ID you're up the creek.

You're trading off present-day efficiency for future-day flexibility. Whether that's wise for a particular case depends on that case.

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

#37

Post by [deleted] » Sat, Jan 08, 2022, 10:48 AM UTC

globular-toast wrote: post #35

VWWHFSfQ wrote: post #19

Earlier quoted context omitted.

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.

Well, you would have some kind of synchronisation protocol where the database confirms it has received that record and it now exists.

[deleted]

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

#38

Post by GordonS » Sat, Jan 08, 2022, 10:49 AM UTC

tticvs wrote: post #15

busymom0 wrote: post #2

Is this specific to MySQL or does it apply to Postgres too?

Postgres is somewhat different mainly because it doesn't use clustered index primary keys. So the row's position on disk is not related to the primary key index entry's position on disk. Additionally using the less cryptographically secure uuid v1 can be a performance optimization since it has implicit time based sorting.

Some years back (maybe 5-10?) I remember doing a test with UUIDs on Postgres, and found no speed difference between UUIDs and integer PKs.

I don't remember the parameters of the test, however.

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

#39

Post by hobs » Sat, Jan 08, 2022, 10:52 AM UTC

cerved wrote: post #22

radicalbyte wrote: post #5

Earlier quoted context omitted.

If you order the data based on the uuid and your uuid is randomly distributed, then you will almost always be writing the data in the middle of your table, physically. You can cut the impact somewhat by using spare tables (leaving lots of empty space) but eventually you'll be re-writing the data. SQL Server has a sequential uuid type which avoids exactly this problem.

> SQL Server has a sequential uuid type which avoids exactly this problem. you refer to the uuid generated by sql server?

Probably just https://docs.microsoft.com/en-us/sql/t-sql/functions/newsequ...

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

#40

Post by globular-toast » Sat, Jan 08, 2022, 10:55 AM UTC

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.