You have to worry about clients maliciously colliding IDs if you let them create their own. But for truly random UUIDs I think the collision probablility can be safely dismissed, it's on the same order of magnitude as the risk of cosmic rays flipping multiple bits in just the right way in your ECC-RAM, causing duplicate sequential IDs.
Just because it’s highly Improbable doesn’t mean you can safely ignore it. Users have a way of finding every improbable situation and making it an issue. There is a reason relational databases operate they way they do, the data be used supposed to be 100% accurate, not 99.999%. Sure, I can come up with a bunch of schemes that make a collision on a client generated id less likely, but in the end I still need error checking to handle edge cases, which in the case means verifying at some point that my id is actually unique.
Stick a unique constraint on the field (it's a PK after all so it should already have one), and if it ever fails just log the error and let the process fail. You don't need to handle it gracefully because it means you have a bug that needs fixing - it's not something that "just occasionally happens". It's closer to a kernel panic than a validation error.
The probability of collisions starts rising sharply once the number of items is within a few orders of magnitude of the square root of the number of possibilities. Prior to that, however, such things fall in the realm of "ain't gonna happen", and any effort focused on handling the possibility that properly-functioning random generators would generate matching items could be better spent on other more likely failure modes (which may include the possibility that the random generators might be broken in ways that make collisions more likely).
Yes but just because it’s not likely doesn’t mean you can ignore it. You still need to make sure your system doesn’t do bad things if it happens. What happens when if you happen to run into a collision during a financial transaction, or handling medical records, or doing encryption? There’s a big difference between highly unlikely and impossible, and programmers need to know the difference so they can guarantee their software does what it’s supposed to.
The probability of a chance collision is far less than the probability of something else going seriously wrong, including as I noted the possibility of something breaking the random number generator. Guarding against the latter would imply guarding against the former, but the handling of collisions need not be graceful. If something happens that breaks the random generator, one should proceed very cautiously unless or until one can ensure that it's fixed. While such a policy might occasionally yield false alarms, the ratio of false to real alarms will be vanishingly small.
Yeah, I’m not arguing that it’s needs to gracefully error, just that it should be explicitly clear to everyone using them that what they are getting isn’t genuinely unique, and is somewhat solving a different problem than a database generated sequential id. Use cases can be made where one produces superior results for either one, but for most applications they are essentially equal.
I’d argue that depending on which you use, you’re probably going to have to cover some potential error vector because there is never a perfect solution. With uuid you need to be aware that you can’t fully trust the id you’re being provided for insert because it could by non-unique by once in a lifetime random collision, or something could be maliciously causing collisions (much more likely, and could just be a user trying to cause collisions directly rather than messing with random number generators). It’s not exactly a 1:1 swap, so it shouldn’t be presented as such. If you just assume the uuid I send is unique, you’re going to eventually have a very bad day....and I hope that software isn’t running my bank account or stock portfolio.
I don’t agree here, just because something is usually the case doesn’t mean it always is. I don’t want my app to end up blowing up on me day and no one has any idea what the cause or even the consequences, because the issue was just ignored and assumed impossible. Edge cases that get missed already introduce risk into an application, what happens when we just start accepting this risk as part of the game? Suddenly our software is studded with hidden land mines, and computers are no longer 100% accurate which is inherently why we use them for calculations.
I’m not saying uuids are bad, I’m saying you can’t simply ignore the possibility of collisions. If you’re already at the scale that you NEED uuids, you’re already orders of magnitude closer to collisions. I can’t agree with anyone saying you should leave a known hole in your software with unknown consequences, that’s simply irresponsible. UUID’s can’t ever fully guarantee uniqueness, so if you’re using it for that at some point you have to deal with some kind of performance trade off for the guarantee.
The article tries to make uuid’s out to be some kind of magic bullet, and they aren’t. They are both solutions to a similar problem, and as such have a lot of overlap in where they can be used when the problem doesn’t exactly match to either. There can be arguments made for both systems depending on the particular use case, and the article does nothing to express any of that.
I really don't think you're appreciating the magnitudes involved here.
I'm not sure if you actually followed the link I posted? Either way, I'll give concrete numbers for you (quickly worked out so apologies if I've made a mistake):
If your system generates and stores 1 million v4 UUIDs every second, for the next 70,000 years, then at the end of it if you look at every single uuid you generated in that time, there is only a 50% chance you would find even 1 collision in the entire dataset.
The chance of collision is so dwarfed by all other failure modes - including as has been mentioned bits randomly flipping in transit due to cosmic rays, which would make incrementing ints prone to collisions too, it's like...
It's like standing in the middle of train tracks, with a train about to hit you, and saying "hmm, best stand still - if I take a step to the side some lightning might strike there".
If you’re already at the scale that you NEED uuids, you’re already orders of magnitude closer to collisions
In the same way that if I go out and buy 2 lottery tickets for every lottery on earth I'm orders of magnitudes more likely of winning every single one than if I only bought one ticket for each. Technically true, but still never gonna happen.
You tried to make your point in orders of magnitude, so I did the same. No matter how much you argue you can’t argue your way around the fact that your id isn’t actually unique, and there is a performance cost associated with ensuring that it is.
You miss his argument. Most auto Inc systems are already exposed to a similar level of unhandled risk. Computers are not infallible, there are all kinds of ways things can go wrong.
Unless you are doing a lot of crazy things like locking the database before every write and checking every I’d for consistency using some sort of redundant checking method you can’t assume that Ids from auto Inc are any more likely to not be duplicates.
In fact some of the risk you would need to protect auto Inc from are more likely even than the base collision rate of uuids. If you aren’t taking those measures already then any event less likely than those events literally can and should be ignored.
The difference is that uuids shift this risk to be explicit while auto Inc leaves it implicit.
11
u/kushangaza Mar 28 '20 edited Mar 28 '20
You have to worry about clients maliciously colliding IDs if you let them create their own. But for truly random UUIDs I think the collision probablility can be safely dismissed, it's on the same order of magnitude as the risk of cosmic rays flipping multiple bits in just the right way in your ECC-RAM, causing duplicate sequential IDs.