Azure SQLDatabase Series concept and service layer

Technorati tag: azure,sql,public Cloud 1. Concept

Currently, there are two ways to use a database on Azure, one is to install a database on a VM or to deploy a VM that already has a database, which requires the user to configure SLAs, backups, or even deployment, and a SQL database that directly uses the PAAs platform, without deployment, with SLA guarantees, Can be configured directly, but with a db size limit of up to 500G.

Using Azure SQL database can I avoid lengthy periods of purchasing and installing hardware-with Azure SQL database, you can create and delete databases at any time without waiting for a purchase order to be approved, a device arrives, a power and cooling system upgrade, or installation is complete. By pre-configuring hardware based on the aggregate requirements in each of our data centers, Microsoft is addressing these challenges in a holistic approach, dramatically reducing the time it takes from ideas to solutions. This can save a customer's business for weeks or months compared to manual procurement and deployment of hardware.

Microsoft also includes many automated management features in Azure SQL Database, such as automatic HA, load balancing, and built-in management.

Automatic high Availability (HA)

Azure SQL database retains at least three copies of each user database and has a logic that automatically submits each change to the replica quorum in a synchronized manner. This ensures that any single computer failure does not result in data loss. In addition, each replica is placed on a different hardware rack so that power outages or network switch outages do not affect your database. Finally, there is the logic that if you lose the computer, the copy is automatically rebuilt so that the system automatically retains the health properties that you want, even if the health of the computer becomes unhealthy. These mechanisms can avoid the lengthy process that is currently required to install and configure a high-availability solution. By pre-Configuring an HA solution for your data, you can eliminate another major challenge when building a mission-critical database solution using traditional methods.

Load Balancing

Unlike traditional virtual machines, Azure SQL Database also includes a mechanism to automatically distribute the load across multiple computers. The load balancer dynamically observes the resource usage of the cluster and moves the database copy to the computers in the cluster to distribute the load dynamically and equitably across multiple users. This extends the on-demand capacity of the database and allows the user to independently consider the requirements for each database, because the load balancer will be able to migrate busy databases and keep such databases away from each other. When you create a solution that spans many databases, this logic provides an abstraction layer through which customers can focus on the capacity needs of each database, regardless of the specific size limit of the virtual machine.

Built-in management

Azure SQL Database runs as a service. This means that you define a run-time target for each database to avoid lengthy maintenance downtime. Microsoft provides a single-vendor solution for a service, which means that if you have any questions, just call a company. In addition, Microsoft constantly updates services, adds features, increases capacity, and looks for ways to improve the experience in every update we make. Updates are transparent and do not incur downtime, which means that updates are integrated within our normal HA failover mechanism. This way, once we announce new features, customers can use these features without having to wait for the server to be upgraded in a future outage. 2. Service Layer

SQL database in Azure currently has five service tiers: Basic, Standard, advanced, Web, and Enterprise. However, within 12 months from April 24, 2014, the Web and Enterprise service Tiers (versions) will be deactivated.

The advanced service layer makes cloud application performance more predictable by tightly controlling the amount of resources in Azure SQL Database and its secondary replicas. Azure SQL Database extends this philosophy to the new standard service tier, which provides higher performance predictability for databases. The performance requirements of the basic service tier and the standard service tier are lower, and are designed to meet the performance requirements of lower-cost databases.

5 performance levels for basic, standard, and advanced:

Service Layer	Performance level
Basic	Basic
Standard	S1 S2
Senior	P1 P2 P3

Service Layer Structure:

Service Layer/performance level	DTU	Maximum database size	Maximum number of worker threads	Number of sessions of the Conference	Predictability
Basic	1	2 GB	20	100	Good
Standard/S1	5	GB	50	200	Very good
Standard/S2	25	GB	100	500	Very good
Advanced/P1	100	GB	200	2,000	Best
Advanced/P2	200	GB	400	4,000	Best
Advanced/P3	800	GB	1,600	16,000	Best

Service Layer/performance level	DTU	Maximum database size	Benchmark Transaction Rate	Predictability
Basic	1	2 GB	3,467 transactions per hour	Good
Standard/S1	5	GB	283 transactions per minute	Very good
Standard/S2	25	GB	1,470 transactions per minute	Very good
Advanced/P1	100	GB	98 Transactions per second	Best
Advanced/P2	200	GB	192 transactions per second	Best
Advanced/P3	800	GB	730 transactions per second	Best

PS: The resource and Capacity database Throughput Unit (DTU) representation for each service tier and performance level. The DTU allows you to describe the relative capacity of this performance level based on the mixed metrics of CPU, memory, and read-write rates provided by each performance level. Doubling the database DTU level is equivalent to doubling the database capacity. With this benchmark, we can assess the impact of the higher capabilities provided by each performance level on database performance by performing actual database operations while proportionally sizing database sizes, users, and transaction rates based on the resources provided to the database.