71–77 of 77 posts
Earlier quoted context omitted.
You should, but B-tree is the most common data structure used for database indexes, and sequential order performs better than random order for index keys.
You often can't bottleneck the entire workload on the capacity of one cluster node and one storage device.
Earlier quoted context omitted.
Oh, 32-bits is enough for a lot of tables assuming you have a transactional ID allocator. The whole reason to have a UUID is so you don't have to serialize all your ID allocation. Agreed though that for some lower volume systems, 64-bits is likely enough to make collisions statistically unlikely.
May be I'm spoiled by postgres, but transactional ID allocator sounds like a problem solved in every database. Is there issues somewhere?
Earlier quoted context omitted.
You often can't bottleneck the entire workload on the capacity of one cluster node and one storage device.
I can't really understand what you said, could you elaborate? :)
Earlier quoted context omitted.
I can't really understand what you said, could you elaborate? :)
If one machine can only handle a hundred transactions per second, and you might ever receive more than that, you have to spread the work across several machines, probably by assigning primary keys that aren't (mostly) sequential.
Earlier quoted context omitted.
They’re only partially correct no matter what. The timestamp in a ULID has only has millisecond resolution, so two IDs generated in the same millisecond, even within the same process, will be randomly ordered. In practice though there are a lot of advantages to having approximately-time-ordered IDs, and I’ve found the pitfalls easy enough to avoid.
The ULID spec has the weird "first generate a random number and all successive calls within the same millisecond just increment the previous number by 1", which tries to solve this somewhat at the expense of now needing to lock, making ULID generation sequential within the same process.
Earlier quoted context omitted.
Great point, using a u16 is probably the best choice then. As it give locality within 65.53600 seconds (roughly a minute) without exposing sensitive timing information, and should cover most real world write scenarios.
A small additional improvement might be to also create a random 16bit salt at startup and then xor the timestamp with that, to leak even less information. That way entries will still have locality without leaking ms timestamp info.
Earlier quoted context omitted.
A small additional improvement might be to also create a random 16bit salt at startup and then xor the timestamp with that, to leak even less information. That way entries will still have locality without leaking ms timestamp info.
at this point, why not use the creation date (with all that you describe on top) as the primary component of the primary key?