Earlier quoted context omitted.
> If you need more than second precision then millisecond doesn't get you much further. It gets you precisely 100x further.
*1000x
Oops, yes, this one.
Goodbye integers, hello UUIDv7
311–320 of 376 posts
Re: Goodbye integers, hello UUIDv7
#312Earlier quoted context omitted.
The problem they describe is not about sorting: it’s about data locality. And for the latter, clock skew should not be a problem. Even with significant clock skew, data will end up clustered anyway, much better than with a random spread.
You get index locality with an autoincrement also, and it will actually reflect insert order. My point is that a timestamp won't do that, and worse, it will appear to most of the time. The failure can be fairly spectacular, a Unix clock can be set to any time at all, and it's good when the resulting bugs are limited to time. Having an actual insert order can be a real boon to figuring out what happened. I hold to the…
[deleted]
Re: Goodbye integers, hello UUIDv7
#313Earlier quoted context omitted.
As someone who only cares about v4, I periodically wonder why don't I just use fully random 128-bit identifiers instead (without the version information).
UUID v4 isn't large enough to prevent collisions, that is why segment.io created https://github.com/segmentio/ksuid which is 160bit vs the 128bit of a UUIDv4.
I think you vastly overestimate the likelihood of collisions. If all of the 2 billion computers in the world produced a new uuidv4 every millisecond, we still wouldn't expect a collision for the next 5 quintillion years.
Or if the same number of bits are used in a more structured manner, like uuidv1 which combines a 48 bit MAC address, 60 bit 100-nanosecond timestamp, and a 14 bit uniquifier with an effective resolution of 6.5 femtoseconds, you could have 300 quadrillion computers make 160 billion uuidv1s per second with guaranteed zero collisions until the year 3400 (plus an extra 500 or so years because the timestamp is referenced to 1542 for some silly reason), after which point any collisions that do happen will be completely irrelevant because they're guaranteed to be colliding with db entries created over 2000 years prior.
Re: Goodbye integers, hello UUIDv7
#314> the random nature of standard non-time-ordered UUIDs (such as v4) can create database performance problems when used as primary keys. This problem is often referred to as poor database index locality.
Couldn't that be solved with incremented serial numbers, rather than leaking time data?
Re: Goodbye integers, hello UUIDv7
#315Earlier quoted context omitted.
Inadvertently leaking private information is not an arbitrary argument.
Sure but what are cases where knowing when a random GUID was created is actually an issue of privacy? Every platform I've seen using Snowflakes that exact same data is publicly available.
It’s a case by case thing. I don’t disagree that in the vast majority of cases it won’t matter at all. But once it becomes the norm/default it’s inevitable that it’ll lead to inadvertent leaks.
Re: Goodbye integers, hello UUIDv7
#316> the random nature of standard non-time-ordered UUIDs (such as v4) can create database performance problems when used as primary keys. This problem is often referred to as poor database index locality. Couldn't that be solved with incremented serial numbers, rather than leaking time data?
Yes. But I think part of the design requirements is minimizing coordination required among distributed nodes.
This solution attempts to solve the sort-ability issue of current uuids by moving the timestamp to the most significant bits.
Re: Goodbye integers, hello UUIDv7
#317Earlier quoted context omitted.
Unless you have specific needs, the only type of UUID you should care about is v4. v1: mac address + time + random v4: completely random v5: input + seed (consistent, derived from input) v7: time + random (distributed sortable ids)
As someone who only cares about v4, I periodically wonder why don't I just use fully random 128-bit identifiers instead (without the version information).
Because the rest of the world uses uuidv4 and the extra couple bits doesn’t really buy you anything
Re: Goodbye integers, hello UUIDv7
#318Is there some reason new versions of UUID keep appearing? It seems like the desired properties are never quite achieved so new ones appear later. Is there a table with UUID version across the top and characteristics down the side, so I can see the differences and pick one that fits my needs? That might also help to explain why there are so many variants.
[deleted]
Re: Goodbye integers, hello UUIDv7
#319Earlier quoted context omitted.
As someone who only cares about v4, I periodically wonder why don't I just use fully random 128-bit identifiers instead (without the version information).
UUID v4 isn't large enough to prevent collisions, that is why segment.io created https://github.com/segmentio/ksuid which is 160bit vs the 128bit of a UUIDv4.
No number of bits is large enough to _prevent_ collisions.
Re: Goodbye integers, hello UUIDv7
#320Earlier quoted context omitted.
> Moderate amount of well implemented obscurity is helpful. You're getting that wrong: Everything else being equal, the more obscure system will always be the safer one. It's just that obscurity can easily be lost, so your system should, if in any way possible, still be secure even if fully known. In the end, however, no system is 100% secure, but more obscurity will make it harder to find the inevitably existing iss…
I think the counter argument is, that all else is not equal when obscurity is a goal of security, because it adds a maintenance burden to some greater or lesser degree, and that maintenance burden becomes time taken away from proper security practices, or other value providing work.
I think the main argument is that security by obscurity can easily be circumvented, be it via sidechannel, secret leak, source code leak or a surprisingly small search space (for example the whole range of IPv4 being scanned by now). It's easy to assume something is secure and spend a lot of time on obscurity, which completely falls apart thanks to a small sidechannel attack. It's (usually) just a weak defense overall. Yes, it can also be a maintenance overhead and therefore risk via proxy, but it can actually be easier in other situations.
For a personal anecdote, I used to work in a small webshop and our software was horrible, to the point where minimal effort would have been able to compromise our servers, which were running software roughly as old as I was at the time (I want to note that I worked on improving the situation while I was there). Still, the only time we had a problem was when we took over a Joomla-hosted site, as we were small enough to not get any individual attention and your off-the-shelf WordPress or Joomla-scripts did not work on our home-brewed software.
In the end, I fully agree that security by obscurity is a weak concept and the usual wisdom of not relying on it is completely correct. Still, it's important to acknowledge that obscurity can and does help security and bring actual reasons on why you should not rely on it. Just saying "it's obviously bad" leads to an easily refuted argument and will not convince some developers, leading to worse software overall.