3 ms·

It seemed like the pricing structure (for SQL Azure, particularly) made for a big unknown. Was the billing in line with your expectations? What are things to

It seemed like the pricing structure (for SQL Azure, particularly) made for a big unknown. Was the billing in line with your expectations? What are things to watch out for?

vyrotek 16y ago
Some things completely depend on the type of project you run. We decided that only the bare-minimum/must-be-relational data will go into SQL Azure so that the database doesn't grow too fast. Instead, we use Table Storage for the really big data. It does require a big change in the way you think about storing and querying your data though since you lose functions such as Count,GroupBy,Joins,etc. But, there is now something called 'Federations' coming out for SQL Server which will let you automatically and sometimes magically shard your data across multiple database with little maintenance. I'm not sure what the roadmap of that feature is but it eliminates any of the GB cap worries that existed before. The biggest surprise we ran into was the cost of Transactions. Even though you get 10k storage transactions for pennies, it does add up. Especially since every request for items from a queue is a transaction. So a lot of thought has to go into things to make sure parts of the system aren't too 'chatty' when it comes to Azure Storage. You don't have this problem with SQL Azure. There is no transaction cost, only the GB used.
- vshlos 16y ago
  We mainly use TableStorage as well for storing data, however since none of the data that we have is stored (besides user information) we have each webnode talking directly to each other. I am not quite sure if each of these transactions costs money, but since all the connections between servers are stable connections that are left open in a separate thread, I am thinking it will be pretty cheap. We did run into some problems when using TableStore since I think we underestimated how much we need Count, GroupBy, Sort, etc. Even basic operations such as bringing back a list to display to the user, then clicking to sort by a column is difficult.

It seemed like the pricing structure (for SQL Azure, particularly) made for a big unknown. Was the billing in line with your expectations? What are things to watch out for?

vyrotek 16y ago

Some things completely depend on the type of project you run. We decided that only the bare-minimum/must-be-relational data will go into SQL Azure so that the database doesn't grow too fast. Instead, we use Table Storage for the really big data. It does require a big change in the way you think about storing and querying your data though since you lose functions such as Count,GroupBy,Joins,etc. But, there is now something called 'Federations' coming out for SQL Server which will let you automatically and sometimes magically shard your data across multiple database with little maintenance. I'm not sure what the roadmap of that feature is but it eliminates any of the GB cap worries that existed before. The biggest surprise we ran into was the cost of Transactions. Even though you get 10k storage transactions for pennies, it does add up. Especially since every request for items from a queue is a transaction. So a lot of thought has to go into things to make sure parts of the system aren't too 'chatty' when it comes to Azure Storage. You don't have this problem with SQL Azure. There is no transaction cost, only the GB used.

vshlos 16y ago
We mainly use TableStorage as well for storing data, however since none of the data that we have is stored (besides user information) we have each webnode talking directly to each other. I am not quite sure if each of these transactions costs money, but since all the connections between servers are stable connections that are left open in a separate thread, I am thinking it will be pretty cheap. We did run into some problems when using TableStore since I think we underestimated how much we need Count, GroupBy, Sort, etc. Even basic operations such as bringing back a list to display to the user, then clicking to sort by a column is difficult.