Microsoft Azure Essentials Fundamentals of Azure Second Edition e-optimized 5x11 pdf

Table storage 
Azure Table storage is a scalable NoSQL data store that enables you to store large volumes of semi-
structured, nonrelational data. It does not allow you to do complex joins, use foreign keys, or execute 
stored procedures. Each table has a single clustered index that can be used to query the data quickly. 
You also can access the data by using LINQ queries and Odata with the WCF Data Service .NET 
libraries. A common use of table storage is for diagnostics logging. 
To use table storage, you have to create a storage account. Once you have a storage account, you can 
create tables and fill them with data.  
A table stores entities (rows), each of which contains a set of key/value pairs. Each entity has three 
system properties: a partition key, a row key, and a timestamp. The partition key and row key 
combination must be unique; together they make up the primary key for the table. The PartitionKey 
property is used to shard (partition) the entities across different storage nodes, allowing for load 
balancing across storage nodes. All entities with the same PartitionKey are stored on the same storage 
node. The RowKey is used to provide uniqueness within a given partition.  
To get the best performance, you should give a lot of thought to the PrimaryKey and RowKey and 
how you need to retrieve the data. You don’t want all of your data to be in the same partition; nor do 
you want each entity to be in its own partition.  
The Azure Table service provides scalability targets for both storage account and partitions. The 
Timestamp property is maintained by Azure, and it represents the date and time the entity was last 
modified. Azure Table service uses this to support optimistic concurrency with Etags. 

---

106 
CHAPTER 4  |    Azure Storage 
 
In addition to the system properties, each entity has a collection of key/value pairs called properties. 
There is no schema, so the key/value pairs of each entity can contain values of different properties. 
For example, you could be doing logging, and one entity could contain a payload of {customer id, 
customer name, request date/time, request} and the next could have {customer id, order id, item 
count, date-time order filled}. You can store up to 252 key/value pairs in each table entity.  
The number of tables is unlimited, up to the size limit of a storage account. 
Tables can be managed by using the storage client library. The Table service also supports a REST API 
that implements the Odata protocol; tables are addressable with the Odata protocol using a URL in 
the following format: