I was a little surprised they mentioned KSUID but not Snowflake or Flake which are how a lot of teams learned about k-ordered ids originally. Perhaps I’m just old. I re-implemented flake in Haskell for fun awhile back.
Doesn’t talk about the motivations for k-ordering or sortability as it pertains to database indexes either. UUIDv4 has a habit of spraying btree indexes in unpleasant ways. This summarizes the motivations for Flake’s design: http://yellerapp.com/posts/2015-02-09-flake-ids.html
A long time ago I found a site for the UUID Preservation Society, encouraging all programmers to limit their use of UUIDs lest they run out. This seems like something they would get behind.
So you are blaming poor logging or error handling on the type of an identifier used? Sorry but this point is nonsensical enough that I stopped reading right at the beginning of an article.
Depends on what you mean by “hierarchical”, but likely no. The closest you could come is a UUIDv1 which contains the MAC of the generating node; so long as all your UUIDs are v1 and generated by the same node, they’d have that in common.
For other versions, not really. A v4 UUID is random. And v3 or v5 UUID is just a UUID of a hash of a namespace+name combination (the difference being the hash algorithm – MD5 for v3, SHA-1 for v5), where the desirable property is that the same combination of namespace+name produces the same output every time. For example, no matter what language or system you use, as long as it’s RFC4122-compliant, would give the output UUIDv3 9073926b-929f-31c2-abc9-fad77ae3e8eb for the domain name example.com. But v3 and v5 UUIDs don’t have a way to recover the input namespace or name from the output UUID.
I was a little surprised they mentioned KSUID but not Snowflake or Flake which are how a lot of teams learned about k-ordered ids originally. Perhaps I’m just old. I re-implemented
flakein Haskell for fun awhile back.Doesn’t talk about the motivations for k-ordering or sortability as it pertains to database indexes either. UUIDv4 has a habit of spraying btree indexes in unpleasant ways. This summarizes the motivations for Flake’s design: http://yellerapp.com/posts/2015-02-09-flake-ids.html
there is also ULID [1]
a comparasing with KSUID [2]
[1] https://github.com/ulid/spec
[2]https://github.com/segmentio/ksuid/issues/8
A long time ago I found a site for the UUID Preservation Society, encouraging all programmers to limit their use of UUIDs lest they run out. This seems like something they would get behind.
So you are blaming poor logging or error handling on the type of an identifier used? Sorry but this point is nonsensical enough that I stopped reading right at the beginning of an article.
Are there any hierarchical UUIDs out there? That is, given two UUIDs, I can quickly check if they might be related, without looking at a database?
Depends on what you mean by “hierarchical”, but likely no. The closest you could come is a UUIDv1 which contains the MAC of the generating node; so long as all your UUIDs are v1 and generated by the same node, they’d have that in common.
For other versions, not really. A v4 UUID is random. And v3 or v5 UUID is just a UUID of a hash of a namespace+name combination (the difference being the hash algorithm – MD5 for v3, SHA-1 for v5), where the desirable property is that the same combination of namespace+name produces the same output every time. For example, no matter what language or system you use, as long as it’s RFC4122-compliant, would give the output UUIDv3
9073926b-929f-31c2-abc9-fad77ae3e8ebfor the domain nameexample.com. But v3 and v5 UUIDs don’t have a way to recover the input namespace or name from the output UUID.