Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nanosecond timestamp collisions are common

evanjones.ca

Post reply on HN
Print view View original

91–100 of 291 posts

Re: Nanosecond timestamp collisions are common

#91

Post by danbruc »

qwerty456127 wrote: post #86
eru wrote: post #48

Earlier quoted context omitted.

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.

More importantly if you have an index on purely random IDs, then each insert will go to some random position into the tree whereas having IDs that increase with time will make all new IDs end up at the end of the tree which reduces index fragmentation.

Re: Nanosecond timestamp collisions are common

#93

Post by 3cats-in-a-coat »

pravus wrote: post #83
3cats-in-a-coat wrote: post #54

Earlier quoted context omitted.

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 name…

When you get used to this basic principle of when you create something, the creator slaps a name on it, it stops being considered a hassle or confusing.

More specifically:

1. When you create something, the creator names it.

2. When you bring something you created outside your scope, you prepend your name to it.

It's kind of what we do with (actual) children if you think, slightly less structured, but the idea was always there. Just add recursion to complete the principle.

Re: Nanosecond timestamp collisions are common

#95

Post by beefield »

p-e-w wrote: post #21

If 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.

Knowing nothing about UUID v4 generation, I have likely a stupid question. What makes you so confident that all implementations and their entropy sources are flawless enough to make actual collision probability close enough to theory?

Re: Nanosecond timestamp collisions are common

#96

Post by aaron695 »

qwerty456127 wrote: post #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 use…

[dead]

Re: Nanosecond timestamp collisions are common

#97

Post by EGreg »

danbruc wrote: post #91
qwerty456127 wrote: post #86

Earlier quoted context omitted.

> 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.

More importantly if you have an index on purely random IDs, then each insert will go to some random position into the tree whereas having IDs that increase with time will make all new IDs end up at the end of the tree which reduces index fragmentation.

Or, you could use a graph database and stop having frustrating relational impedance mismatch, nonlocality etc. You can have O(1) lookups instead of O(log N) for almost everything

Re: Nanosecond timestamp collisions are common

#98

Post by Rapzid »

godelski wrote: post #60

Despite the resolution being nanoseconds, what is the actual precision of computer clocks? I can't imagine it is actually nanoseconds. Takes me back to teaching physics labs where I had to hound students to remember that the accuracy of their measuring device is not identical to the smallest number it displays...

> I can't imagine it is actually nanoseconds

It's nanoseconds.

Re: Nanosecond timestamp collisions are common

#99

Post by EGreg »

madsbuch wrote: post #58
eru wrote: post #48

Earlier quoted context omitted.

Why do you need the time component anyway? It's just eating up bits in your UUID without contributing much entropy.

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 dont know why people use relational databases other than they were first and “that’s the way it’s always been done”.

Why not use a graph database? O(1) lookups instead of O(N). Why need indices if you can just point to the data. Why use JOINs when map-reduce querying is far more flexible?

Re: Nanosecond timestamp collisions are common

#100

Post by rocho »

donatj wrote: post #94

Slacks API uses straight nanoseconds for the IDs of their messages which I always found very curious but figured they must have some sort of way on the backend of resolving collisions.

A message ID only needs to be unique per workspace, in which case you'd expect very few collisions to begin with, and you could even retry on insert failure with a new timestamp. I don't think that would cause significant performance penalties.
Post reply on HN