361–370 of 376 posts
> 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?
Incremented serial numbers can leak things like eg. volume of sales in your shop.
Earlier quoted context omitted.
If it is the same database system, you may as well use a SERIAL or similar synchronized datatype. The point of using UUIDs is that any participant in a distributed system should be able to generate them, without having to rely on a centralized authority. If the use is purely local then UUIDs would be pointless. If you have 74 bits of entropy, the birthday paradox says that after 2^37 keys you will hit a 50% risk of a…
But the uuid collision chance only matters if there is even a possibility of colliding writes and lookups. So what if your microblogging platform's tweet uuid happens to collide with my cocktail recipe generator's ingredient uuid? The likelihood that any one device will ever be running our apps at the same time and trying to read data from one into the other is even smaller than the 1-in-38000000000000000000000000000…
Earlier quoted context omitted.
What benefice over uuid4 ?
Reading their docs: No real benefits, just misconceptions. 1. Collision resistance / "weak" PRGNs used to generate UUIDv4. Firstly, these are properties of the implementation , not the spec. Secondly, the source for calling the browser `Crypto.getRandomValues()` insecure is an issue that has been fixed back in 2016. I would not trust the developers of this implementation to do a better job than current browsers. 2. "…
From the article. I'd like a lot more exposition on that, since it goes against some of what used to motivate UUID use in the first place. Sequential ordering across distributed nodes isn't a fun thing to do, and even if you navigate the coding, the network agreement makes it really slow.
Do they mean "sequential enough" but some locality of the node that generated it? And I guess that prng can sometimes have some performance bottlenecks, but compared to doing locks on a single incremented integer?
Yeah, I don't really get this, lots of usual "better" "faster" etc without actual numbers to back it up or detailed algorithmic discussions.
As you basically said, wake me up if it's good enough to get into the standard vetted libraries of UUID generation.
Earlier quoted context omitted.
I like the idea, but I think it's not possible to rotate the key with that approach, without introducing a breaking change. Eternal secrets are usually a very bad idea, because at some point they are going to be leaked.
Sure you can, just prefix the encrypted identifier with a version number. https://app.example.org/file/1:abcdef12345 -> decrypt abcdef12345 with key "1" to yield UUIDv7 key of file (no matter what the latest key is)
I think there is no good alternative to random external identifiers.
Earlier quoted context omitted.
But the uuid collision chance only matters if there is even a possibility of colliding writes and lookups. So what if your microblogging platform's tweet uuid happens to collide with my cocktail recipe generator's ingredient uuid? The likelihood that any one device will ever be running our apps at the same time and trying to read data from one into the other is even smaller than the 1-in-38000000000000000000000000000…
You're right, but why would either of us be using UUIDs for that purpose, when an auto-incrementing integer would suffice?
Applications use uuids to avoid colliding with themselves. Uuids exist so that web-apps can create objects client-side without waiting for a database CREATE, applications can be built with multi-node dbms, operating systems can name hardware compenents.
Earlier quoted context omitted.
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 resolut…
> 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. This would generate 2^127.8 UUIDs. First, no, the collision would be expected in less than one year, approximately after exhausting square root of the available space (2^64 generated UUIDs): https://en.wikipedia.org/wiki/Birthday_problem Second, no, the UUIDv…
In the real world, we do not spend 100% of our entire species's computing capacity generating uuids and doing nothing else. In the real world, we aren't burning through uuids at a rate of 2 billion per millisecond, and even if we were it wouldn't matter because the true denominator is the scope of the data system the uuid will be referenced in: if your hard drive partition and my webapp user entry happen to get the same uuid, we will never know, and if for some reason it does matter, then we can use uuidv1 or uuidv7 which guarantee no collisions for thousands of years by embedding a timestamp.
Earlier quoted context omitted.
Years ago I wrote a library that would exaggerate sequential IDs to make our SaaS platform appear more popular than it actually was to anyone trying to pay attention. Not sure if I’m proud of the hack or embarrassed. But of both I suppose.
but UUIDv7 isn’t sequential (unless I’m getting it mixed up). There’s just a time-based component which can make sorting really nice & some random bits at the end. If you don’t let an attacker iterate your data, all they can tell is when the ID was created.
It’s 2023. Why aren’t we using more characters from the utf-8 keyspace to make things like UUIDs use less characters?
You could, if you are only optimizing for display size. UUIDs are very infrequently presented as user-facing data, and pretty much every sensible system will be storing them as a 128-bit value, not the ASCII representation you see. So really, what are you trying to optimize?
They're also often used as part of a URL parameter:
" rel="nofollow noreferrer">http://myservice/orders/ etc etc
It’s 2023. Why aren’t we using more characters from the utf-8 keyspace to make things like UUIDs use less characters?
UUIDs are 128 bits, or 16 bytes. They have infinitely many possible string representations. Those strings are not the value, they're a transformation of the value.
When you take that UUID and go start sniffing around internal systems you're going to copy the UTF-8 string representation.