Re:SCRU128: Sortable, Clock and Random number-based Unique i...
by aseipp on Thursday April 21, 2022 @02:53PM
(#31113700)
The intent of these IDs is to be used e.g. as primary keys in a database, and the timestamp improves sortability, helping the database engine pack tuples that are related "in time" into the same pages, which decreases the need for seeks. You can't split the ID and timestamp fields apart; the intent is that they are spatially and temporally related.
Re:SCRU128: Sortable, Clock and Random number-based Unique i...
by j-pb on Thursday April 21, 2022 @04:15PM
(#31114645)
> and to make DB indices happy.
You can do both, use a low precision timestamp with overflows in the ID to keep the index happy, and add a proper timestamp field for analytics.
The 32 + 96 split is what postgres uses for example. I'd say that's a pretty good endorsement.
If you have an overflow condition you want to encounter (i.e. test) it often.
32bit miliseconds + 96 bit of real entropy is brute force resistant, and has a ~50 day overflow period.
That's plenty for eyeball statistics and to make DB indices happy.
Any more sophisticated analytics will require larger precision and timezoning anyways, so don't cram it into the ID and give it it's own field.
Also don't muck with entropy. All these smart counter schemes are potential attack vectors and have a much higher collision probability.
You're more likely to get a collision due to but flips in such a counting scheme than from two randomly colliding full entropy bitstrings.