How does one Azure table storage table with many partition keys compare to many tables with fewer partition keys?

Question

I have a Windows Azure application in which all read queries in TableA are executed on separate sections for a series of rows. Partition classes that facilitate this storage scheme actually smooth out the names of objects in the hierarchy, so the partition key is formatted as {root}_{child1}_{child2}_{leaf} . I can understand how it would be useful to split this large table A into many tables using the root dimension of the partition keys in the table name (so the partition key will become {child1}_{child2}_{leaf} ).

What I want to do is to provide quick access to this data, as far as I can, from the total number of connections at the same time. It would also be unbelievable if I could understand what these limitations are or should be.

More specific questions about my proposed changes:

• Will it matter in scalability, i.e. the number of concurrent data access requests that can be served without a significant performance improvement? Served at the same time?
• Will it matter in average performance? Potential performance?

Answer 1

If each query indicates a partition key, it does not matter how many tables are partitioned. In other words, the following equivalents: one table with a thousand partitions versus a thousand tables with one partition.

The main reason I can think of splitting into multiple tables is because you can delete the entire table in one operation / transaction, while you cannot do this with a range of partitions in one table. This means that for things like magazines, where you might want to delete the old ones after a while, it is often better to have different tables for different time ranges.

Answer 2

+1 for Steve's answer.

Some things to add

• It might be worth considering the option of using multiple accounts — since this is currently a vault account, which is a unit of scalability — each vault account is officially targeted at about 5,000 entities / transactions per second, so if you want it to be higher than you need to use multiple accounts.
• There are some subtle details in performance about how you request your data - if the items are not in the same section, then it is usually faster to execute separate parallel requests instead of executing a single request with a complex where parameter.
• you can find blog posts on the storage team blog especially useful - http://blogs.msdn.com/b/windowsazurestorage/archive/2010/11/06/how-to-get-most-out-of-windows-azure- tables.aspx and http://blogs.msdn.com/b/windowsazurestorage/archive/2010/05/10/windows-azure-storage-abstractions-and-their-scalability-targets.aspx
• you may also need to know the cost — about $ 1 per million hits.