4 ms·
> The moral of the story is that data locality matters, and it can pop up in the most surprising of places. Using random is typically the worst thing you can do
by whack 3y ago
> The moral of the story is that data locality matters, and it can pop up in the most surprising of places. Using random is typically the worst thing you can do for locality, so if you want to use UUID’s, try to use a sequential variant. UUID v7 is a good option
The author isn't suggesting abandoning UUIDs, he is suggesting using something like UUIDv7 which preserves locality. For most use-cases, this seems like a very reasonable recommendation with no significant downsides I can think of.
- deleted 3y ago[deleted]
- fauigerzigerk 3y agoI agree that UUIDv7 will usually be the best choice. The one downside I can think of is that it may sometimes be necessary to let people know the identity of a thing without also telling them exactly when that thing was created.
- pkilgore 3y agoCOMB UUIDs can help here.
- fauigerzigerk 3y agoWhy do COMB UUIDs not have this problem? Do they not contain a timestamp?
- pkilgore 3y agoIt just orders ids based on a monotonic clock that wraps after a certain time -- it's enough to get a lot of of the performance benefit of ordered keys without directly exposing the unix wall clock time they were created (absent a dedicated attacker with the ability to create ids without you picking up on it for a timing attack, I suppose). Whether that tradeoff makes sense probably depends.
- remram 3y agoEncrypt it. Block ciphers are bijective so they will turn sequential IDs into unique random IDs in a way you can easily reverse. You can also do that to get opaque identifiers from an auto-increment primary key.
- fauigerzigerk 3y agoSeems awfully complicated to me.