5 ms·

Very nice. This is based on Boundary's Erlang Flake ID service, more details of which are at http://boundary.com/blog/2012/01/12/flake-a-decentralized-k-ordered

Very nice. This is based on Boundary's Erlang Flake ID service, more details of which are at http://boundary.com/blog/2012/01/12/flake-a-decentralized-k-ordered-unique-id-generator-in-erlang/ http://boundary.com/blog/2012/01/12/flake-a-decentralized-k-.... One thing I had to look up again was the definition of k-ordering: K-ordering gives roughly time-ordered id's down to the millisecond when sorted lexicographically. This is usually fine for most purposes but keep in mind it doesn't allow you to reason about causality between timestamps from different machines. This also relies on your servers clocks to be in sync (something that should be happening anyway).

swah 12y ago
So, one would only use this when the powerful server that is responsible for just generating IDs is saturated, right?
- 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 ago
    Another 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 ago
      The disadvantage a UUID has is that they're larger, Snowflake was something like 63 bits, UUID is 128, 2x as long.
      - dantiberian 12y ago
        Snowflake 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 ago
      UUIDs also don't generally havea notion of ordering.
    - dantiberian 12y ago
      UUID 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#...

swah 12y ago

So, one would only use this when the powerful server that is responsible for just generating IDs is saturated, right?

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 ago
  Another 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 ago
    The disadvantage a UUID has is that they're larger, Snowflake was something like 63 bits, UUID is 128, 2x as long.
    - dantiberian 12y ago
      Snowflake 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 ago
    UUIDs also don't generally havea notion of ordering.
  - dantiberian 12y ago
    UUID 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#...