4 ms·

I am inexperienced, so please correct me if I am wrong - but conceptually this way doesn't seem much more effective or different than UUIDs if the purpose is a

I am inexperienced, so please correct me if I am wrong - but conceptually this way doesn't seem much more effective or different than UUIDs if the purpose is a non-consecutive unique identifier. Also, could you please explain what you mean by "...which are resereved as batches from a global id service"?

manigandham 9y ago
Does it matter if it's consecutive? If you want 0% chance of collisions and/or using numbers then they will be increasing in some way. ID generation scheme: Key "counter" => value "123" Server N starts, asks for 100 ids by incrementing counter, gets the new number 223, now it has numbers from 124->223 to use for ids. Server N+1 starts, does the same thing, and you can keep incrementing the counter to get the next batch of numbers. Anything that supports atomic increments works. Design for whatever availability you need. Add in some random increments if you don't want perfectly sequential numbers. 64-bit numbers pretty much guarantee you'll never run out of space, while being much nicer to handle than UUIDs (which are 128-bit numbers but usually stored as bytes or strings). If you want completely random IDs then UUID is the way to do it, but if it's just for load balancing or partitioning then you can always hash the numbers to get some random strings which work well enough.
- AdieuToLogic 9y ago
  There is also a pattern referred to as "high/low keys"[0] and works quite well so long as the architecture guarantees access to the master when a new high key is needed. Of course, this can be mitigated by allocating small batches of high keys as well if connectivity to the master is unreliable. However, having a 32 bit low range implies the need for batch high key allocation is negligible for all but the most pathological situations. 0 - https://stackoverflow.com/questions/282099/whats-the-hi-lo-algorithm/282113#282113 https://stackoverflow.com/questions/282099/whats-the-hi-lo-a... EDIT: Re-read your original description and realized you described a related, but different, approach of directly reserving key ranges.
  - manigandham 9y ago
    Yes, we reserve the actual number range which is simpler and avoids errors. I havent come across a standard name for this scheme though. We reserve millions of numbers at a time and it works perfectly, and the batch can easily be adjusted to account for usage factor and potential downtime buffering.

manigandham 9y ago

Does it matter if it's consecutive? If you want 0% chance of collisions and/or using numbers then they will be increasing in some way. ID generation scheme: Key "counter" => value "123" Server N starts, asks for 100 ids by incrementing counter, gets the new number 223, now it has numbers from 124->223 to use for ids. Server N+1 starts, does the same thing, and you can keep incrementing the counter to get the next batch of numbers. Anything that supports atomic increments works. Design for whatever availability you need. Add in some random increments if you don't want perfectly sequential numbers. 64-bit numbers pretty much guarantee you'll never run out of space, while being much nicer to handle than UUIDs (which are 128-bit numbers but usually stored as bytes or strings). If you want completely random IDs then UUID is the way to do it, but if it's just for load balancing or partitioning then you can always hash the numbers to get some random strings which work well enough.

AdieuToLogic 9y ago
There is also a pattern referred to as "high/low keys"[0] and works quite well so long as the architecture guarantees access to the master when a new high key is needed. Of course, this can be mitigated by allocating small batches of high keys as well if connectivity to the master is unreliable. However, having a 32 bit low range implies the need for batch high key allocation is negligible for all but the most pathological situations. 0 - https://stackoverflow.com/questions/282099/whats-the-hi-lo-algorithm/282113#282113 https://stackoverflow.com/questions/282099/whats-the-hi-lo-a... EDIT: Re-read your original description and realized you described a related, but different, approach of directly reserving key ranges.
- manigandham 9y ago
  Yes, we reserve the actual number range which is simpler and avoids errors. I havent come across a standard name for this scheme though. We reserve millions of numbers at a time and it works perfectly, and the batch can easily be adjusted to account for usage factor and potential downtime buffering.