A Simple Approach to Using Microsoft Azure Table Storage

Introduction

Microsoft Azure has several different storage options. These include blobs, for storing files, queues for passing messages around, and tables for highly scalable, hierarchical data. Microsoft Azure also provides relational data storage, using traditional mechanics with SQL Azure.

In this article we are going to cover a simple way to start using Azure tables for easy data storage.

Azure Tables store data in the cloud for us, making that data available to applications running in Azure, or applications running anywhere else. Azure Tables are built on the REST protocol, which makes it easy for any platform to connect and use the data in your Table. Most .NET developers will use the Client Storage Library that is provided with the Microsoft Azure SDK.

Before we get too far along, let’s briefly look at how tables work. When you create an Azure Subscription account you will be able to log in to your Azure portal, and be able to create a storage account. A storage account is a storage container attached to your account. You can hold several types of storage within one storage account.

Tables can be easily created and destroyed in the cloud. This is one key advantage over traditional databases. You won’t have any delays or overhead in creating the tables you need. This also makes it easy for your application to self-provision itself when it starts up. During startup you can have it look to see if the tables it needs are created, and if not, create them on the fly, potentially even deploying default data to that table.

Each table is really a collection of entities, which are basically the same as the entity objects you might be using in your application. Each entity has its own set of properties and values. This means that each entity can have its own schema. This is great news; this gives you a great degree of flexibility during both design time and run time. This is the biggest difference from traditional relational data servers (such as SQL Server) you will probably run into.

We are going to build an Azure table, and then some code to work with it. While the table can run locally in our local development storage fabric, we will eventually move it to the cloud so it can run in production. The code we are going to write will be a simple command line program, so we can focus on the core code needed to interact with the table. You will notice that while we have one line of code to create the table itself, we never run any code that creates columns, stored procedures, or indexes of any kind.

We are going to build a small application that tracks parking tickets issued by a parking lot attendant. We are going to start with our entity class, the class in our code that contains the plain old data our system will need to track for each ticket. Here is our definition.


  public class ParkingTicket
   {
       public string LotID { get; set; }
       public string TicketID { get; set; }
       public DateTime DateIssued { get; set; }
       public int AttendentID { get; set; }
       public string CarTagNumber { get; set; }
       public string FineAmount { get; set; }
       public string CauseForTicket { get; set; }
   }

This is a simple entity class. Its only job will be to hold the data that we need to work with for a parking ticket. It has several properties, each defined as autoproperities in C# programming. This means that the compiler will create and manage the hidden private fields we need to back these public properties, a common short cut in defining properties in C#.

This entity is what we will store in our Azure Table. The table will have a property for each property of this entity. Azure Tables all have to have three specific properties in each entity. These required properties help Azure scale and manage your data. They are as follows:


  1. PartitionKey – The scale group the entity belongs to.

  2. RowKey – The unique id for this entity (when combined with the PartitionKey).

  3. DateTimeStamp – The last time this entity was updated.

The PartitionKey and the RowKey, when combined logically, create a sort of composite primary key for the entity. The PartitionKey is used by itself to help Azure scale your data. All of the entities in your table with the same PartitionKey will be managed together as a group. These partitions are used to dynamically scale up the system.

As an example, let’s pretend your table has millions of rows, and thousands of partitions. As the load on your system increases, some of those partitions are going to carry a greater load than other partitions. Perhaps, in our sample, there is a lot of load on a particular parking lot. As that partition becomes busy, or heats up, it is moved by itself, to a separate storage server. This gives the partition more available hardware (CPU and memory) to respond to queries, resulting in better performance. As the load on partitions change, they are moved around the storage servers so that they always have enough hardware to respond to their queries. As a partition cools off, it collapses back down to the old server with the other cold partitions.

A PartitionKey is any string that you want to pick. The trick with partitions is to choose a strategy for your key that will match the vector of scale and common queries. In our example we are going to put the parking lot id in the PartitionKey property, since we are likely to want to group by the parking lot the ticket was written in.

The RowKey is any string you want to assign to it. When combined, the PartitionKey and the RowKey must be unique in your entire Azure Table. We don’t want to hard code these three specific properties into our entity class because they have nothing to do with our class. This would be mingling our data, and create some hard coupling between our class and the use of Azure Tables. To get around this our entity class needs to inherit from TableServiceEntity. To upgrade our code we need to reference in two Azure assemblies, Microsoft.WindowsAzure.ServiceRuntime and Microsoft.WindowsAzure.StorageClient. Add some usings to your code, and then update your class to inherit from TableServiceEntity.

We are then going to update our definitions for LotID and TicketID so they are tracked as the PartitionKey and RowKey respectively. We do this by updating their set methods. Because we are doing something special we can’t use autoproperties for these two properties.


  public class ParkingTicket : TableServiceEntity
   {
       private string _lotID;
       public string LotID
       {
           get { return _lotID; }
           set
           {
               _lotID = value;
               PartitionKey = value.ToLower();
           }
       }

       private string _ticketID;
       public string TicketID
       {
           get { return _ticketID; }
           set
           {
               _ticketID = value;
               RowKey = value.ToLower();
           }
       }

       public DateTime DateIssued { get; set; }
       public int AttendentID { get; set; }
       public string CarTagNumber { get; set; }
       public string FineAmount { get; set; }
       public string CauseForTicket { get; set; }
   }


After making these changes our entity class is ready to be stored in an Azure Table. Notice we haven’t hard coded what the name of the table is, or how to connect to it. The entity class only represents the data, not the behavior or configuration.

More by Author

Must Read