5
votes

My understanding is that in an Azure table, each entity has a composite key made up of the partition key and row key, and the partition key should be used as a category which entities are grouped by, with the row key being a unique id for a particular entity within a category.

However, I want to store a table of extremely simple entities which have just one simple key, and I'm not sure of what roles the partition key and row key should play for such an entity.

for example

part : { id: '00001',
         name: 'wotsit',
         weight: '50kg' }

Semantically, it feels most correct to store id as the row key and use the same, probably blank, partition key for all entities (i.e. they're all in the same, default category). However I'm far more interested in getting maximum lookup performance than table semantics. I can easily abstract this away in the code.

So my question is, how should I use partition key / row key when entities have only one simple key to get maximum lookup performance?

My guess is that storing id as the partition key, and using a blank row key for every entity, would be best as the partition key is looked up first in queries?

1

1 Answers

2
votes

One way to look at Azure tables it to recognize that really there is only one composite key, split into partition and row sub-keys, to support a user determined scalability strategy.

So, you could arbitrary split you single key in to the 2 sub keys based on how they would scale best, determined by the nature of the data.

In your example you could split the id into Partition Key = "00" and Row Key = "001". This may not appear to be useful in your key range but for longer keys may make more sense.