Azure table storage: Partitioning strategy and performance targets

Viewed 94

I am trying to come up with partitioning strategy for Azure Table storage.

I use Scalability and performance targets for Table storage as a primary source for my performance estimation. The document provides 2 numbers:

  1. Maximum request rate per storage account 20,000 transactions per second, which assumes a 1-KiB entity size

  2. Target throughput for a single table partition (1 KiB-entities) Up to 2,000 entities per second

Does it mean that I won't get much throughput benefits from having more than 10-ish partitions since TPS is caped by 10x 1 partition TPS limit?

Actually I am also wondering if they use "transactions" and "entities" interchangeably in the doc. Does the first number applicable to batch transaction or for batches I should divide 20000 by number of transactions in batch.

1 Answers

It is true that having more 10 partitions will not give you throughput benefits but that is only if all 10 partitions are are running at max throughput i.e 2000 tps. If any partition is not running at max throughput, then you will be under utilizing your table storage. This is why It is recommended HERE that

For optimal load balancing of traffic, you should use more partitions so that Azure Table storage can distribute the partitions to more partition servers.

We just worry about the partitioning/partition key and Azure will handle the load balancing upto the max throughput per partition/storage acct.

Related