How does it compare to ULID?
v3rmin opened this issue · comments
Spec for ulid: https://github.com/ulid/spec
ULID requires locking if you need to use it concurrently.
many years later, I think another major difference compare to ULID is xid is only up to 1 second precise, meaning sorting is only possible within the same second, whereas ULID is up to millisecond precise.
IDs from the same second have a local monotonic incrementing random inited counter, so they will still sort well when generated on the same machine/process.
xid seems relatively better if the priority is conciseness, indexing-performance and zero-configurability. But I am not too sure if the locking argument holds true @rs :
ULID requires locking if you need to use it concurrently.
According this comparison of Golang ID packages actually https://github.com/oklog/ulid also achieves fast lock-free concurrent ULID generation
Besides millisecond precision, ULID also enjoys broader support due backward compatibility with UUID columns e.g. Cockroach DB has a builtin function to generate ULIDs for PKs
For a distributed DB like Cockroach DB with xid generated in the application layer over distributed containers / serverless functions sharing a DB cluster, @rs are there any reasons you would still recommend xid over ULID all things considered, especially when there's no guarantee that the xid will be generated on the same machine/process?
For concurrency ULID requires a lock while xid uses an atomic counter as a workaround. Depending on the application, this can be a factor. Conciseness is another.