Flake: A Decentralized, K-Ordered Unique ID Generator in Erlang(blog.boundary.com) |
Flake: A Decentralized, K-Ordered Unique ID Generator in Erlang(blog.boundary.com) |
- Why [time, node id, seq] and not [time, seq, node id]? That would improve ordering if you have approximately equal load on each box.
- Isn't a 16 bit seq number overkill? Handing some of those bits to the unique ID would have made unique ID assignment easier. Duplicate MACs can and do exist (especially if you buy a lot of hardware from the same vendors).
- The quality of the ordering is going to be restricted by the quality of time synchronization within the cluster. Relying on NTP for this is OK, but experience suggests that a secondary monitoring system will be needed. Similarly, relying on monotonic time needs some care in system administration - care that could potentially be avoided with a different unique host ID assignment scheme.
Would you rely on sub-millisecond synchronization between nodes _and_ an almost exact load amount?
In other words for a particular millisecond seq order is only relevant on that particular node, so node should come first.
It still seems to me that T_0,0,A (issued by node A at T_0 with seq number 0) would tend to come before T_0,1,B so putting the sequence number first does add some value. On the other hand, the ordering T_0,A,0 < T_0,A,1 < T_0,B,0 < T_0,B,1 is arbitrary.
> Would you rely on sub-millisecond synchronization between nodes _and_ an almost exact load amount?
Not rely on. Absolutely not. Maybe it's better to go further, and make it more explicit that the IDs are K ordered. Say you could synchronize your host clocks reliably to a maximum delta of 512 ms, then you could chose a scheme like:
[ milliseconds >> 9, host id, milliseconds & 0x1ff, seq id ]
The value here is that you make it much harder for consumer of the IDs to make incorrect assumptions about the precision of their ordering. Basically taking away the temptation to make statements about their ordering with false precision, by making a simple sort only provide a meaningful ordering within the real available precision.
In information theory terms, the node ids are carrying log2(number of nodes) bits of information, whereas the node ids are carrying something more like log2(maximum seq id). The latter is almost certainly larger than the former, and at 16 computer-bits allocated for the sequence number overflow would be a real concern of mine, if not on this year's hardware than in a few more years.
http://instagram-engineering.tumblr.com/post/10853187575/sha...
http://www.mongodb.org/display/DOCS/Object+IDs#ObjectIDs-BSO...
Still don't see it. We are already making the assumption that the millisecond part is the same T_0. So then seq will depend strictly on the count of previous such IDs issued by that node only (would you agree with that?). So that is why I said that it doesn't make sense to compare seq number from A -- (0) and a seq number of B -- (1) before considering the identity of A & B. You would effectively order by relative load between all your machines at that particular time, at that time frame it would be things like disk access, cache states and so on.
EDIT:
In addition. Ordering T_0,A,0 < T_0,A,1 < T_0,B,0 < T_0,B,1 will be stable though, machine A,B mac addresses don't change. For any particular millisecond you will get all the results for a particular machine then those results will be sorted by sequence # so you would even get some kind of a relative load measurement.
Let's look at a longer example:
T_0,A,0
T_0,A,1
T_0,B,0
T_0,B,1
T_0,B,2
T_0,B,3
T_0,C,1
T_0,C,2
T_0,C,3
T_0,D,0
I think is a lot better order than
T_0,0,A
T_0,0,B
T_0,0,C
T_0,0,D
T_0,1,A
T_0,1,B
T_0,1,C
T_0,2,B,
T_0,2,C
T_0,3,B
T_0,3,C