Asynchronous I/O has been present in the .Net Framework from version 1.0, through the Begin/End methods, but it’s only in the recent years when it became a popular topic. There were probably two main reasons for that. One of them was the raise in popularity of node.js which has continuously advertised the event-driven, non-blocking IO … Continue reading
SQL Azure prices drop for big DB sizes make federating more challenging
Microsoft has recently announced a massive price drop for SQL Azure databases, which of course is a great thing. The new price rules are as follows:
|Database Size||Price Per Database Per Month|
|0 to 100 MB||Flat $4.995|
|Greater than 100 MB to 1 GB||Flat $9.99|
|Greater than 1 GB to 10 GB||$9.99 for first GB, $3.996 for each additional GB|
|Greater than 10 GB to 50 GB||$45.954 for first 10 GB, $1.998 for each additional GB|
|Great than 50 GB to 150 GB||$125.874 for first 50 GB, $0.999 for each additional GB|
More details on the official Azure pricing page. You can get a better overview on the new vs. old prices in the following table:
|DB size (GB)||Old price||New price||Price / GB||Total decrease (%)|
As you can see from the table above, the price for 1GB databases is the only one that is unchanged. Other then it, the price decrease is proportional with the size of the database, excepting the databases between 50 and 150GB, which in the old scheme were capped at $499.95.
This poses a challenge for those who want to scale their database by using federations. Sql Azure Federations is a great way of making the database layer inside an application support an increased number of operations / second and thus allowing an increased number of concurrent users on the application.
Up until now, the best practice for scalability was to federate as much as possible. 50 federations of 1GB each were preferred to a single database of 50GB. The price was no problem, since in the end they would have both cost around $500.
Now though, a 50GB database only costs $125.99, while a database with 50 federations of 1GB costs $509.49 ($9.99 for the root database + 50 * $9.99 for each federation). A 75% price difference is not something to be ignored and everybody would have put some serious thought before creating a swarm of small sized federations.
Things are not very complicated however. One of the main features of the Azure platform is elasticity, which applies very well for SQL Azure since increasing and decreasing the number federations inside a database are online operations, meaning that you can always perform them with no down time involved. So the best practice for scalability at database level would be the following:
- Build your application and database to support federations
- Try to predict the required load on the database and create an appropriate number of federations
- Monitor the database usage. If the usage is high split to more federations, if the usage is low reduce the number of federations
Using the above pattern you would be able to match your costs with the actual computing power needs.