local UUID vs network unique counter id

Question

Which one will you choose as your surrogate key implementation ?

• Local UUID
  • That is generated locally in the application, no network trip to retrieve it
  • But the length is long, and can affect the size of your storage size usage
  • Lengthy URL with the long UUID
  • The tiniest fear that UUID collision will happen
• Or .. Network-unique-counter id (not sure on what is the proper term for this)
  • I imagine a remote Redis with the atomic INC or Mongo with $inc
  • The cost of network trip
  • Is much shorter, takes up less space and resulting in much shorter URL
  • No fear on collision, even on clustered applications

Answer 1

You can combine both approaches. Have a look for twitter's SnowFlake algorithm. The algorithm will produce global unique integers (64bit) but without any coordination, a pure local algortim.

Answer 2

If you are using MongoDB, you should look into using BSON ObjectIDs:

http://www.mongodb.org/display/DOCS/Object+IDs

They are created by default as the _id field unless you specify otherwise and create the _id field yourself (which can also be an ObjectID, just created by you). No fear of collision, and you could get a natively supported ID type in the DB that you can also use in your application. Seems like a win-win, as long as you use MongoDB of course ;)

Answer 3

For a low concurrency app, you can probably use network counter id. But except for url, there is no interest for low concurrency (= not a lot of data).

In case of heavy concurrency access, so a lot of data, so a lot of clusters, you redis engine + associated network will be probably to slow for this solution.

In conclusion : - network counter seems to be sexy but useless, in my opinion, with MongoDB.

On MongoDB collision, due to the creation algorithm, the collision is near zero. I explain, a part of the uuid is build with the machine address, which should be unique and you can get this address before putting your cluster in production.