Programming Table Storage in Azure…Choosing your Keys!!

Azure holds a lot of promise for applications with

1. Spikes in usage

2. Requirement for low set up cost

3.Huge storage requirements

Out of these 3 major benefits, most applications will exploit the 1st and the 3rd potential of Azure!..While Spikes in Usage is more related to how the application is architected etc(we’ll talk about it in another post), huge storage requirements is a pretty interesting topic…the potential here is enormous..

You want to learn more on Silverlight 4, won’t it be cool if you could just see what articles people have read and which ones they found useful and why?? I am sure it will help you make more out of your time by helping you weed out the “not so useful” articles….but who would take the onus of storing such HUGE data?? Well something like Table Storage in Azure could be the answer to is a scalable, extensible and inexpensive storage medium to store just this type of data…

While just having fun with Azure, we made this small app which allows a user add a weblink onto the Azure table storage…


he can then also search the entire table for weblinks of his interest based on categories..


One can take this forward to search by submitter, or Category+ rating etc etc..

The entire application is uploaded here…its a rough sample (so no commenting etc etc )but it will give you a idea..if you have any issues with it…its!!!

There are lots of samples out there so i don’t want to focus on “how to program” this….i am more interested in the most important aspect of using the Table Storage in Azure….How to select you Keys!!(Partition + Row Key)

Basically your partition key should be the most commonly used filtering criteria for your application….so basically you need to realize the main purpose of the application and in what way it is going to be used, what kind of queries are going to be most frequent…one tip here is that the you should be able to use your partition key in the where clause of almost all your queries..

Lets see what kind of querying makes sense for this simple application

1. Get me all weblinks in CategoryX

2. Get me all weblinks in CategoryX with Rating Y

3. Get me all weblinks submitted by User T

4. Get me all weblinks submitted by User T in Category X

etc, etc

If you notice most querying is going to involve the “Category”, so we should be able to use Category in the where clause!!….so the partition key becomes category!!

You must use Category as a condition in most of your queries


Now for the Row Keythe rule here says that if there are 2 frequently used keys, use the most freq as the partition key and the other one as the Row Key…so if you see the querying, you will be tempted to use the “SubmittedBy” as the row key…but there is a problem…PartitionKey+RowKey should be unique for every row in the table…so if you use SubmittedBy as the Row key, a user will be able to submit a weblink for a category only once…makes no sense!!

For applications such as this…it makes sense to use Guid.NewGuid as the row key to allow multiple entries and still maintain uniqueness…

Like i said, let me know if you want the source code…will be happy to load it somewhere for you!!…Azure table storage has huge potential as long as the keys are selected properly!!!



Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>