mongodb - Collision probability of ObjectId vs UUID in a large distributed system -
considering uuid rfc 4122 (16 bytes) larger mongodb objectid (12 bytes), trying find out how collision probability compare.
i know around quite unlikely, in case ids generated within large number of mobile clients, not within limited set of servers. i wonder if in case, there justified concern.
compared normal case ids generated small number of clients:
- it might take months detect collision since document creation
- ids generated larger client base
- each client has lower id generation rate
in case ids generated within large number of mobile clients, not within limited set of servers. wonder if in case, there justified concern.
that sounds bad architecture me. using two-tier architecture? why mobile clients have direct access db? want rely on network-based security?
anyway, deliberations collision probability:
neither uuid nor objectid rely on sheer size, i.e. both not random numbers, follow scheme tries systematically reduce collision probability. in case of objectids, structure is:
- 4 byte seconds since unix epoch
- 3 byte machine id
- 2 byte process id
- 3 byte counter
this means that, contrary uuids, objectids monotonic (except within single second), important property. monotonic indexes cause b-tree filled more efficiently, allows paging id , allows 'default sort' id make cursors stable, , of course, carry easy-to-extract timestamp. these optimizations should aware of, , can huge.
as can see structure of other 3 components, collisions become if you're doing > 1k inserts/s on single process (not possible, not server), or if number of machines grows past 10 (see birthday problem), or if number of processes on single machine grows large (then again, aren't random numbers, unique on machine, must shortened 2 bytes).
naturally, collision occur, must match in all these aspects, if 2 machines have same machine hash, it'd still require client insert same counter value in exact same second , same process id, yes, these values collide.
Comments
Post a Comment