Identity alternative for SQL Azure Federation : are Azure Queues or Service Bus Queues a good choice?

Question

As many of developers, I'm looking for a way to integrate my existing app to SQL Azure Federations, and replacing the Identity columns (the primary keys of my tables) is a big problem.

For many reasons, I do NOT want to use GUID for my primary keys (please don't open the debate about the GUID or not, it's not my question : i just don't want a GUID, period).

So I need to build a key provider to replace the "identity" feature of a standard SQL database. I'm using Entity Framework, so I can easily find one place to set the Id value just before the insert (by overriding the SaveChanges method of my ObjectContext class). I just need to find a "not too complicated" implementation for getting the current Id, which is "farm-ready".

I've read this SO post : "ID Generation for Sharded Database (Azure Federated Database)" and "Synchronizing Multiple Nodes in Windows Azure from MSDN Magazine", but this solution sounds a bit complicated for me.

I'm thinking about creating (automatically) one azure queue for each SQL table, which contain a pre-loaded list of consecutive integer. When I want an Id value, I just have to get a message from the queue (which becomes invisible and is deleted on the way), which give me the current available Id.

About the choice between "Windows Azure Queues" and "Windows Azure Service Bus Queues", I prefere "Windows Azure Queues", due to the "high" latency of Service Bus Queues. I don't think that the lack of "ordering garantee" of Azure Queues is a problem.

What do you think about that idea of using Azure Queues to provide Id values ? Do you see any argument to give up that idea ? Do you have a better idea, or even a good practice, to provider integer ids in SQL Azure Federation databases ? Thanks.

EDIT :

Astaykov suggested SnowMaker. I've finally done a fork of SnowMaker to have a full compatibility with the v2 of the Azure Storage lib.

EDIT 2

Please note that Azure SQL Federation will be retired September 2015 with web and business tiers, as explained here. But this question remains valid for custom sharding solutions.

Answer 1

SnowMaker

Never tried it in production though, but seems to be quite reasonable and reliable.

UPDATE

Two things: you may safely reference Azure Storage Client 1.7.XX alongside with Azure.Storage 2.X to make SnowMaker work. Or fix it to work with Storage 2 like you do.

As a side note, I personally think that identity does not solve any problems, it even introduces such (but still I use it). And don't think that lack of identity is disadvantage of Federations, given the power and scale it gives us. In order to thing Big, we have to get rid of conventional thinking of auto-generated by something numbers.

Unfortunately I don't have real world project experience with Federations yet, but I'm really eager to give it a try. I know there are large application deployments that use Federations and are massively scalable.

Answer 2

Another option is the RustFlakes project. It provides a way to generate unique, sequential IDs across distributed systems without colliding with one another. They are the same size as a GUID (128-bit) but because they are sequential they won't cause all of the page splits, indexing, and associated issues you would have w/ GUIDs.

Answer 3

Not sure if this will be useful to you since it's not C#, but I've ported Snowmaker to Nodejs, using the 0.3.3 version of the Nodejs Azure Storage SDK.

You can install it using npm:

npm install snowmaker

The Github repository is https://github.com/johnhamm/node-snowmaker