VERKOOP: 1-800-867-1389
Deze inhoud is niet beschikbaar in uw taal, maar wel in het Engels.

Scaling Out Azure SQL Databases

Updated: February 19, 2015

Microsoft Azure SQL Database (Azure SQL Database) is built on standardized hardware that is owned, hosted, and maintained by Microsoft. Azure SQL Database offers a variety of service tiers and performance levels to fit the diverse needs of database applications in the cloud. (See Azure SQL Database Service Tiers and Performance Levels.) However there are limits to performance and capacity of the standardized hardware, so when additional resources are required scaling out becomes necessary. This requires sharding, which horizontally partitions data across multiple databases.  Each database in this model is referred to as a shard.

Azure SQL Database supports three methods to implement sharding:

Elastic Scale
Azure SQL Database Elastic Scale (Preview) simplifies building and managing an application that uses sharding. A .Net client library allows applications to define how data is mapped to shards and routes OLTP requests to appropriate databases.  An Azure service template is included that you can host in your own Azure subscription. The template enables a database management app to reconfigure how data is distributed among shards. For more information, see Azure SQL Database Elastic Scale (Preview).

Optimizing Data Elasticity Through Database Sharding
This topic, Optimizing Data Elasticity Through Database Sharding, is designed for organizations that want to take advantage of data-tier elasticity based on potentially hundreds or thousands of database nodes. Many organizations are elastically scaling their relational data tiers by adopting custom database sharding techniques in their cloud solutions. Based on their feedback, AzureCAT created a series of articles describing key concepts and best practices. These articles introduce basic principles of database scalability and describe common data elasticity patterns proven to work with cloud services such as Microsoft Azure SQL Database, and are perfectly valid for both custom sharding and Elastic Scale APIs based solutions.

Custom Sharding
You can design and develop your own mechanisms for defining shards, routing connections, and managing data distribution among them. However, custom sharding typically requires significant development effort beyond application logic. 

The Federations feature in Azure SQL Database automatically partitions data horizontally based on a federation distribution key. For more information about Federations, see Federations in Azure SQL Database.

The Federations feature will be retired with Web and Business service tiers.  Consider deploying solutions utilizing Elastic Scale to maximize scalability, flexibility, and performance. For more information about Federations retirement, see Web and Business Edition Sunset FAQ.  

New sharded applications should implement the Elastic Scale APIs and capabilities, as it provides the most valuable features for sharding development and management.

Use a custom sharding approach if your application requires much more functionality beyond the capabilities of Elastic Scale.

Existing Federations solutions can be migrated to employ sharding using the Elastic Scale’s migration utility. For more information, see Federations migration.

See Also

Vindt u dit nuttig?
(1500 tekens resterend)
Bedankt voor uw feedback
© 2015 Microsoft