views:

304

answers:

2

Currently Table Storage supports From, Where, Take, and First.

Are there plans to support any of the other 29 operators?

Are there architectural or design practices in regards to storage that one should follow in order to implement things like COUNT, SUM, GROUP BY, etc?

If we have to code for these ourselves, how much of a performance difference are we looking at to something similar via SQL and SQL Server? Do you see it being somewhat comparable or will it be far far slower if I need to do a Count or Sum or Group By over a gigantic dataset?

I like the Azure platform and the idea of cloud based storage. I like Windows Azure for the amount of data it can store and the schema-less nature of table storage. SQL Azure just won't work due to the high cost to storage space.

+1  A: 

The only alternative is to pull everything down locally and run Count() or Sum() over the local objects. Because you have to transfer the entire contents of your table before doing the count, this will certainly be much slower than doing something server-side like with SQL. How much slower depends on the size of your data.

smarx
+3  A: 

Ryan,

As Steve said, aggregations are resolved "client side", which might kead to bad perfromance if your datasets are too large.

An alternative is to think about the problem in a different way. You might want to pre-compute those values so they are readily available. For example if you have master-detail data (like the proverbial Purchase order + line items), you might want to store the "sum of line items" in the header. This might appear to be "redundant" (and it is), but de-normalization is something you will have to consider.

These pre-computations can be done "synch" or "asynch". In some situations you can afford having approximations, so delaying the computation might be beneficial from a perfromance perspective.

Eugenio Pace