4 ms·
If you don't have a natural primary key (the usual use case for UUIDs in distributed systems such that you can have a unique value) how do you handle that with
by outside1234 1y ago
If you don't have a natural primary key (the usual use case for UUIDs in distributed systems such that you can have a unique value) how do you handle that with bigints? Do you just use a random value and hope for no collisions?
- hellojesus 1y agoWouldn't you just have an autoincrementing bigint as a surrogate key in your dimension table? Or you could preload a table of autoincremented bigints and then atomically grab the next value from there where you need a surrogate key like in a distributed system with no natural pk.
- outside1234 1y agoYes, if you have one database. For a distributed system though with many databases sharing data, I don't see a way around a UUID unless collisions (the random approach) are not costly.
- tbrownaw 1y agoPeel off a few bits at one end, and assign a value per instance.
- hellojesus 1y agoYes. This is the way so long as you can guarantee you wont grow past the bits. Otherwise you can still use the pregenerated autoincrements. You just need to check out blocks of values for each node in your distributed system from the central source before you would need them: N1 requests 100k values, N2 requests 100k values, etc. Then when you've allocated some amount, say 66%, request another chunk. That eay you have time to recover from a central manager going offline before it's critical. I have no problem with using uuids but there are ways around it if you want to stick with integers.
- benwilber0 1y agoYou use a regular bigint/bigserial for internal table relations and a UUID as an application-level identifier and natural key.