0

I am building a web application using a distrbuted NoSQL DB. However, for generating Ids for the new entities, I am using MySQL as Flickr's ticket server

I just stuck across an idea of keeping the stock of Ids at the application layer, so that newer entities may be easily allotted ids in a fast manner, without the need for fetching from DB, one by one, for each of them. Instead I can just pull a stock of Ids from the DB say around 1000, and use them uptil stack reaches a certain limit of remaining Ids, when I'll pull more of Ids from DB to fill the stack again.

Your ideas and thoughts upon this appreciated.

Rajat Gupta
  • 25,853
  • 63
  • 179
  • 294

2 Answers2

2

That's a good idea unless you need your ids to be sequential, and that it is ok that some ids are never used.

e.g. the SAP ERP does this (configurably) for what it calls "number ranges" when they have no ordering requirement and can have "holes". Each application server will request a set of keys rather than just one, and serve them out of this cache. It refills its cache whenever necessary. This saves quite some round trips and locking on the DB.

If an app server goes down (or the system is stopped), whatever ids that were present in the cache but not yet handed out are lost (i.e. will never be used). This is sometimes fine if all you need is a unique id. Not fine at all if you can't have holes in the sequences (which happens for business document numbers (like invoice numbers for example) in some countries).

Mat
  • 202,337
  • 40
  • 393
  • 406
  • Thanks. you exactly understood my point..! Also why even there is a need of a stack, it could be just a static counter perhaps, since the stock of Ids is sequential.. – Rajat Gupta Mar 12 '11 at 09:37
  • Well the ids need to be globally unique. So you need to make sure that whatever implementation you use is thread-safe at least, and consistent globally. A "static counter" doesn't sound so good because they're often not thread safe (depends on language, context, atomicity guarantees or absence thereof...). But there are lots of ways of implementing it that don't require a complex queue or stack-type structure. (And you might not be in a threaded environment.) – Mat Mar 12 '11 at 09:43
0

While this will work, you're probably adding unnecessary complexity.

Universally Unique IDs are designed for exactly this case. A previous answer here on SO contains a pure-PHP UUIDv4 generator, if you don't feel like using the UUID PECL extension.

The major downside of UUIDs is that they're ugly, though they can be represented in other forms that are merely freakishly long.

Community
  • 1
  • 1
Charles
  • 50,943
  • 13
  • 104
  • 142
  • good suggestion but the reason why I am trying to avoid UUIDs is because my DB is heavily denormalized & morever I want to cache my DB rows which contain these Ids as columns, I would like to prefer something much smaller than 128 bits, perhaps i32 ids. – Rajat Gupta Mar 13 '11 at 07:13