SQL Azure uses best practices for database deployment

Although SQL Azure is appropriate for most of the best time for SQL Server, and its generation and development is based on SQL Server technology, when building new types of application systems, there are some differences in architecture and features This requires the transformation of ideas to further consider and delve into.

For example, when there is too much load on the database, we need to identify the cause of the problem, whether the database connection is not right or the SQL Azure data source connection is not smooth, while developing the application to handle some problems that are not encountered in traditional SQL Server applications. Here are a few recommendations and best practices for SQL Azure database deployment.

If your front-end application is on a Windows Azure host, you should place the application and the SQL Azure database on the same machine, which optimizes the connection by reducing the latency between the application and the database server. Traditionally, Web servers and database servers are on the same machine, but SQL Azure hosts are placed in several data centers around the world. Therefore, from a system configuration perspective, Windows Azure applications should be placed on the same machine as SQL Azure.

Just as traditional databases handle load response to larger and more frequent use by scaling out rather than scaling up. SQL Azure databases are more applicable to this rule because of resource constraints. When SQL Azure discovers that a database uses too much CPU and disk I/O, it controls throughput to ensure that other databases are not affected. Because throttling is implemented at the database level, a large amount of data can be dispersed across multiple databases in either the horizontal or vertical direction, in which case the chance of a bad connection is reduced, and any potential connection congestion affects only a subset of the datasets.

In addition, small databases can be faster if you need to start a failover of SQL Azure between two databases. Similarly, if you have a read-only database server that is refreshed from SQL Server, you can create multiple databases in SQL Azure so that applications can iterate or randomly choose which database to access. This way, you can distribute the load on SQL Azure and reduce the chance of poor connectivity.

Another thing to note is that SQL Azure server connections are more susceptible to interference, and your applications should be better able to handle them and provide a greater transparency of reconnection. Compared to the more traditional SQL Server environment, there are several scenarios where connectivity disruptions can occur. For example, if you leave your local network, connection failures occur at multiple points including routers, switches, regional Internet outages, and how the SQL Azure database works. If your database server fails, SQL Azure will start a new server online and restore your database. This is a quick process that takes only a few seconds, but any existing connections will be interrupted.