Azure Tables are for Squares in the Cloud
The third aspect of Azure storage is the table structure. BLOBs answer how to manage unstructured data in your cloud application, and tables answer how to manage your structured date.
Tables, like the rest of Azure, are designed to be super scalable. You can easily store billions of rows, and terabytes of data, and still get great performance. Because the tables are part of Azure, the table data is always available, and triple replicated for reliability.
Accessing tables is easy using ADO.NET Data Services, which should be familiar to most .NET developers. ADO.NET DS uses normal .NET classes and LINQ to access your data. If you don’t want to access sit with ADO.NET, you can easily use REST, so any platform can make queries and calls into the data.
Each account can have many tables of data. Each table contains entities, which are like rows in a traditional database. Each entity is indentified with a composite key. The first half is the partition key, which identities which partition the entity lives in. Partitions are how the table data structures scale so well. Which entities go into which partitions are left up to the application and the developer to decide, simply by assigning the key appropriately. You could have a partition in your customers table for each state, based on which state the customer lives in. Azure will move partitions around to balance performance and traffic to a specific data server. If two partitions are very active, one will be moved to a different server.
The second half of the primary key is the RowKey which is used to identify the entity within the partition, and is very similar to your trusty old unique row id.
Both PartitionKey and RowKey are strings, and must be less than 64KB in size.
Queries that reference a partition key in the constraints will be much faster, because the engine can constrain the table scan to the same partition.
Each entity can have up to 255 properties, including the partition key, and the row key. Azure does not enforce a schema. Schema enforcement is left to the application. This gives you the flexibility to vary the shape of the entity based on the scenario, instead of building more and more tables. This is very handy when you are deploying customizations for customers in a multi-tenant scenario.
It is easy to create and destroy tables. It is common to check for the table existence, and create it if it isn’t found on application startup. This makes it easy to deploy your application. No more struggling with complex setup SQL scripts. This code can also be moved into a separate tool for use in deploying your application. Each account has a table called Tables, that tracks which tables have been created.
To access a table with REST, you can easily use the URI:
POST .table.core.windows.net/http://<ACCOUNT NAME>.table.core.windows.net/<TABLE NAME>
Using a POST verb will save an object to the table. The object would be stored in the Atom envelope in the REST call. Querying, updating, and deleting records is just as simple. A sample query would look like:
GET .table.core.windows.net/?$filter">http://<ACCOUNT>.table.core.windows.net/<TABLE>?$filter= cost eq 45
Comments