header logo

Azure Table Storage

Azure Table Storage

Microsoft Windows Azure table storage is part of the Windows Azure system. Cloud storage is a booming technology and used by a myriad of different services. This article discusses how to leverage Azure table storage for your Azure application’s storage requirements.

There are two fundamental options open to you for an Azure application’s storage needs: Azure SQL Database (formerly known as SQL Azure) and Azure table storage. Although there is local storage available on each Azure instance, this must be considered transient at best. Local storage is intended only to serve the basic needs of the service running on the Azure instance.

Azure SQL Database is a very capable database solution built upon Microsoft SQL Server. If your application has needs for a complex relational database model, then Azure SQL Database is really the way to go. However if your application’s data requirements are simpler then Azure table storage may be sufficient.

The main benefit for using Azure table storage is that it is extremely cheap. The cost per transaction is so cheap as to be virtually unmeasurable for small applications and the cost for storage volume is also very low compared to Azure SQL Database.

The main drawbacks for Azure table storage are that it is non-relational and can only have the one index. Secondary indices are not supported and the primary index is the row key that you assign to each row. In addition, there is no sorting available on the primary index so the rows can only be retrieved in the order that they are stored.

All this aside though, there are solutions to the problems above for some applications. The non-relational aspect is not a massive problem if you are prepared to manage this aspect yourself. For example, a “person” record may be required to have a photograph attached to it. In a SQL Server database you may store this in a related blob table residing on a different partition. Using Azure table storage, the picture can be stored in Azure blob storage with a GUID as the filename. This GUID can then be stored in the person record in the table storage. Deletions would therefore be a manual process of making sure both items of data were removed, but if this is something your application can live with, there are big cost savings to be made.

The lack of secondary indices is not an insurmountable problem. Clever usage of row keys can make sure the data is stored in an order that is least likely to cause performance issues. Also, depending on your application, it could retrieve a small number of columns from all the items in the table at start-up. The row key retrieved with these items can then be used to retrieve the full row as and when it is needed during the application’s life cycle.

In summary, before opting for an expensive Azure SQL Database solution, re-examine your application’s requirements and see if any of the facilities of Azure table storage can be used instead.