Choosing a PartitionKey

In order to store the massive amount of data and quickly return queries against this data, tables may be partitioned across thousands of nodes. This is where the partition key fits into the storage scheme – all entities with the same partition key will be kept together. Different entities from the same table may be served from different nodes, but every entity with the same partition key will be served from the same node. In our Contacts example we have seen earlier, all the BillGates records will be kept together, and all of the SteveJobs records would be kept together, which may be a different node than the BillGates records.

The Azure Fabric constantly monitors traffic to our partitions, and replicates active partitions to multiple nodes in order to satisfy traffic demands. Selecting a partition key becomes an important balance between query performance and response time. The smaller our partitions, the more nodes our table can be spread over. However, if we split...