Shared Access Signature for Azure Table Storage with PK and RK ranges

Question

I have a situation where I need to create a SAS token based on a range of PartitionKeys and RowKeys both.

To be more precise, my PK is based on Ticks of timestamp (there is a partion for every 10-minute range). My RK is based on some string.

I'm trying to call storage from a browser and get data for a range of PKs (based on some time range) and within those PK's, based for a range of some RKs. IE:

PK > 100000000 && PK < 200000000 && RK > "aaa" && RK <"mmm"

When I create the token, response from storage returns correct partitions, but entities for all RK's.

            var sas = table.GetSharedAccessSignature(new SharedAccessTablePolicy
                                              {
                                                  Permissions = SharedAccessTablePermissions.Query,
                                                  SharedAccessExpiryTime = DateTime.UtcNow.Add(period)
                                              }, null, startPk, startRk, endPk, endRk);

Any ideas how to make the call only follow provided RK range without me having to filter out on the client unnecessary entities?

Answer 1

@GauravMantri pointed me to a helpful article: http://blogs.msdn.com/b/windowsazurestorage/archive/2012/06/12/introducing-table-sas-shared-access-signature-queue-sas-and-update-to-blob-sas.aspx

What I was trying to do is not supported. PK/RK ranges are given for a continous range from start PK/RK to end PK/RK, rather than a filter query as I have thought.

Answer 2

Note that your partition key pattern may result in bad performance because of the "Append Only" pattern that you are setting up: https://azure.microsoft.com/en-us/documentation/articles/storage-performance-checklist/#subheading28

Azure Storage learns your usage pattern, and adjusts the partition distribution according to the load, adaptively. So if you have your load across a number of partition keys, then it can split those partitions into different servers internally, to balance your load. However, if you load is all on one partition, and that partition changes periodically (like it does with append-only pattern), then the adaptive load balancing logic gets ineffective. To avoid this, you should avoid using dates or date-times as your partition key, if your query patterns allow it.