Another case of precision but not accuracy.
Nanosecond timestamp collisions are common
81–90 of 291 posts
Re: Nanosecond timestamp collisions are common
#82Earlier quoted context omitted.
You need it to make database indices perform better. If you don't need that, but just need a random UUID, UUIDv4 is better.
I feel like v7 is almost a strictly better v4. Assuming you can generate a v7 (you have a time source), what are the disadvantages?
Entropy. You loose bits to a known source, which reduce entropy of the UUID.
Re: Nanosecond timestamp collisions are common
#83Earlier quoted context omitted.
> We can have registrars for global ids, and we can nest local ids inside them, we can have a hierarchy, and we can have local compact ids, 32, 64 or 128 bit, which will never collide, and be locally cohesive. We have this. It's called OID (Object Identifier) and is used in X.509, LDAP, SNMP, and many other technologies. A global registry exists (I have an entry) and it's a giant tree. > So why aren't we doing this?…
My point was, let's start with that large OID tree, for example. And continue this concept downward. Except when it's inside your org, you're the registrar of your namespace's sub-OIDs, and so on. And there's precisely no reason not to have hierarchical sequential ids for everything. You need to generate ids on 100 servers? Good, give each server a namespace. You need to do that in a 100 processes on each server? Goo…
I'll also have the need to make namespaces dynamic and centrally coordinate their lifecycle along with the rest of my infrastructure as I stand up anything that needs some sort of coordinated ID. So I've just moved this issue to an even larger scope with even more complexity.
What do I gain for this? UUIDs solve all of this because the chance of creating a duplicate is so low it can effectively be ignored. I can namespace UUIDS and create chains of them if needed.
This is the reason both exist. We need both. We can use both.
Re: Nanosecond timestamp collisions are common
#84> it is unsafe to assume that a raw nanosecond timestamp is a unique identifier
It is reasonable to assume that a raw nanosecond timestamp is a unique identifier in cases when you can reasonably expect such identifiers are not generated too offten.
I.e. this is Ok (and even redundant) for identifying manual interactions a single user would pdosuce. It probably is also Ok for labelling manual interactions multiple users would produce if that's a small team.
Re: Nanosecond timestamp collisions are common
#85If you want unique identifiers, use version 4 (random) UUIDs. Problem solved. The probability of a collision is roughly the same as the probability of a fully grown dinosaur spontaneously manifesting in your bedroom due to quantum fluctuations.
the dinosaur is now on my bed, what next?
Enjoy the non heat-death of the universe
Re: Nanosecond timestamp collisions are common
#86This is why you should use ids that combine both a time component and a sequence. Eg UUIDv7 has a milliseconds time component and then a field that increments for each event in the same millisecond, and then enough random bits to make collisions between ids generated on different machines astronomically unlikely. Of course there are only so many bits so you might generate too many events in the same time slice so the…
Why do you need the time component anyway? It's just eating up bits in your UUID without contributing much entropy.
> Why do you need the time component anyway?
To sort or filter the records by time. Sure, you can just add an extra column if you need this, but there are cases when this is not convenient to do. E.g. when you want to be able to export the records info files, naming the files with the IDs and still be able to sort them.
Re: Nanosecond timestamp collisions are common
#87This is why you should use ids that combine both a time component and a sequence. Eg UUIDv7 has a milliseconds time component and then a field that increments for each event in the same millisecond, and then enough random bits to make collisions between ids generated on different machines astronomically unlikely. Of course there are only so many bits so you might generate too many events in the same time slice so the…
The problem with UUIDs is they are completely unreadable. Not just you can't understand them, it is prohibitively hard to even distinguish between them visually. This is why identifiers which would not include any bit of information (or noise) beyond the necessary minimum are useful in some cases.
Re: Nanosecond timestamp collisions are common
#88Earlier quoted context omitted.
You need it to make database indices perform better. If you don't need that, but just need a random UUID, UUIDv4 is better.
I feel like v7 is almost a strictly better v4. Assuming you can generate a v7 (you have a time source), what are the disadvantages?
You can hand out uuidv4 to clients without revealing anything.
Re: Nanosecond timestamp collisions are common
#89Earlier quoted context omitted.
But shouldn't that be a separate field then?
The logistics of combining fields in indexes and identifiers is relatively complex, while the logistics of indexing a single field is comparatively trivial. This is also why you don't ship timestamps using separate fields for second/minute/hour/day/month/year, but a single ISO-string or UNIX timestamp as representation: it makes querying and interpreting the value more consistent.
Create a new column with an MD5 hash of the other columns. Easy.
/s
Re: Nanosecond timestamp collisions are common
#90Earlier quoted context omitted.
The problem is achieving locality in cohesion/meaning, which usually involves locality in time, which provokes using timestamps as part of the id at the very least. But it's a chain of very lazy thinking IMHO and it's like a peek at the house of cards some large systems are built like.
Why do you want this kind of locality anyway?
Database indices.