4 ms·
That's one reason you'd want this. A few others that I can think of: * No single point of failure if the id server goes down * Avoiding network round trip la
by dantiberian 12y ago
That's one reason you'd want this. A few others that I can think of:
* No single point of failure if the id server goes down
* Avoiding network round trip latency
* You have distributed servers across multiple data centres (though clock sync may be an issue)
If your service can tolerate k-ordered ids then I would pick this over a central server every time.
- swah 12y agoAnother alternative is using local UUIDs, right ? If you're just interested in generating a unique ID to shard and insert into one of your DB nodes.
- bagels 12y agoThe disadvantage a UUID has is that they're larger, Snowflake was something like 63 bits, UUID is 128, 2x as long.
- dantiberian 12y agoSnowflake was 63 bits due to some cleverness with resetting the epoch and coordinating unique worker ID's through Zookeeper. These Flakes relax those restrictions and are 128 bits. The benefit is that they don't require a central server to distribute worker ID's and the epoch is the standard Unix epoch. This holds as long as the MAC addresses on your machines are unique. As another commenter mentioned, this doesn't always happen.
- michaelmior 12y agoUUIDs also don't generally havea notion of ordering.
- dantiberian 12y agoUUID 1 contains time values but arranges the UUID parts in such a way that the k-ordering is lost. But certainly if you just need an opaque id then a UUID would be fine. https://en.wikipedia.org/wiki/Universally_Unique_Identifier#Version_1_.28MAC_address.29 https://en.wikipedia.org/wiki/Universally_Unique_Identifier#...