Scaling out with Azure SQL Database(使用 Azure SQL 数据库进行扩展)Scaling out with Azure SQL Database

适用于:是Azure SQL 数据库 APPLIES TO: yesAzure SQL Database

可以使用“弹性数据库”工具轻松地扩展 Azure SQL 数据库中的数据库。You can easily scale out databases in Azure SQL Database using the Elastic Database tools. 借助这些工具和功能,可以使用 Azure SQL 数据库中的数据库资源来为事务工作负荷,尤其是服务型软件 (SaaS) 应用程序创建解决方案。These tools and features let you use the database resources of Azure SQL Database to create solutions for transactional workloads, and especially Software as a Service (SaaS) applications. 弹性数据库包括:Elastic Database features are composed of the:

下图显示了一种体系结构,它包含与数据库集合有关的弹性数据库功能。The following graphic shows an architecture that includes the Elastic Database features in relation to a collection of databases.

在此图中,数据库颜色表示架构。In this graphic, colors of the database represent schemas. 颜色相同的数据库具有相同的架构。Databases with the same color share the same schema.

  1. 一组使用分片体系结构的 SQL 数据库托管在 Azure 上。A set of SQL databases is hosted on Azure using sharding architecture.
  2. 弹性数据库客户端库 用于管理分片集。The Elastic Database client library is used to manage a shard set.
  3. 一个数据库子集已放入弹性池A subset of the databases is put into an elastic pool. (请参阅什么是池?)。(See What is a pool?).
  4. 弹性数据库针对所有数据库运行计划的或即席的 T-SQL 脚本。An Elastic Database job runs scheduled or ad hoc T-SQL scripts against all databases.
  5. 拆分/合并工具用于将数据从一个分片移到另一个分片。The split-merge tool is used to move data from one shard to another.
  6. 使用 弹性数据库查询 可以编写跨分片集中所有数据库运行的查询。The Elastic Database query allows you to write a query that spans all databases in the shard set.
  7. 弹性事务允许跨多个数据库运行事务。Elastic transactions allow you to run transactions that span several databases.


为什么使用这些工具?Why use the tools?

VM 和 blob 存储可以轻松实现云应用程序的弹性和缩放需求 - 只需添加或减少单位,或者增加功率。Achieving elasticity and scale for cloud applications has been straightforward for VMs and blob storage - simply add or subtract units, or increase power. 但对于关系数据库中的有状态数据处理,这仍是一个挑战。But it has remained a challenge for stateful data processing in relational databases. 在这些情况下出现的难题:Challenges emerged in these scenarios:

  • 增加和缩小工作负载的关系数据库部分的容量。Growing and shrinking capacity for the relational database part of your workload.
  • 管理可能会影响特定数据子集的热点 - 例如,繁忙的最终客户(租户)。Managing hotspots that may arise affecting a specific subset of data - such as a busy end-customer (tenant).

过去以来,在解决此类情况时,一般都是投资更大规模的服务器来支持应用程序。Traditionally, scenarios like these have been addressed by investing in larger-scale servers to support the application. 但是,在预定义商品硬件上执行所有处理的云中,此选项受限制。However, this option is limited in the cloud where all processing happens on predefined commodity hardware. 将数据和处理负载分散到许多结构相同的数据库(一种称为“分片”的向外缩放模式),无论在成本还是弹性上,都是超越传统向上缩放方法的另一种选择。Instead, distributing data and processing across many identically structured databases (a scale-out pattern known as "sharding") provides an alternative to traditional scale-up approaches both in terms of cost and elasticity.

横向缩放与纵向缩放Horizontal and vertical scaling

下图显示了缩放的横向和纵向维度,即弹性数据库的基本缩放方法。The following figure shows the horizontal and vertical dimensions of scaling, which are the basic ways the elastic databases can be scaled.


水平缩放是指添加或删除数据库,以调整容量或整体性能,也称为“横向扩展”。Horizontal scaling refers to adding or removing databases in order to adjust capacity or overall performance, also called "scaling out". 分片是常用的横向缩放实现方法,它会将数据分区到结构相同的一组数据库上。Sharding, in which data is partitioned across a collection of identically structured databases, is a common way to implement horizontal scaling.

垂直缩放是指增加或减少单个数据库的计算大小,也称为“纵向扩展”。Vertical scaling refers to increasing or decreasing the compute size of an individual database, also known as "scaling up."

大多数云规模的数据库应用程序都使用这两种策略的组合。Most cloud-scale database applications use a combination of these two strategies. 例如,软件即服务应用程序可能使用横向缩放来预配新的最终客户,使用纵向缩放来允许每个最终客户的数据库根据工作负荷的需要增加或缩减资源。For example, a Software as a Service application may use horizontal scaling to provision new end-customers and vertical scaling to allow each end-customer's database to grow or shrink resources as needed by the workload.

  • 可以使用弹性数据库客户端库来管理水平缩放。Horizontal scaling is managed using the Elastic Database client library.
  • 可以通过使用 Azure PowerShell cmdlet 更改服务层级或者通过将数据库放入弹性池中,来实现纵向缩放。Vertical scaling is accomplished using Azure PowerShell cmdlets to change the service tier, or by placing databases in an elastic pool.


分片是一项可跨许多独立数据库、分发大量相同结构数据的技术。Sharding is a technique to distribute large amounts of identically structured data across a number of independent databases. 这项技术尤其受到最终客户或企业创建软件即服务 (SAAS) 产品的云开发人员的欢迎。It is especially popular with cloud developers creating Software as a Service (SAAS) offerings for end customers or businesses. 这些最终客户通常称为“租户”。These end customers are often referred to as "tenants". 需要分片的原因有很多:Sharding may be required for any number of reasons:

  • 数据总量过大,超出单一数据库的约束范围The total amount of data is too large to fit within the constraints of an individual database
  • 整个工作负载的事务吞吐量超出单一数据库的容量The transaction throughput of the overall workload exceeds the capabilities of an individual database
  • 租户可能需要与其他租户物理隔离,因此每个租户都需要单独的数据库Tenants may require physical isolation from each other, so separate databases are needed for each tenant
  • 由于符合性、性能或地理政治的原因,不同的数据库部分可能需要驻留在不同的地域中。Different sections of a database may need to reside in different geographies for compliance, performance, or geopolitical reasons.

在其他方案(例如从分布式设备中引入数据)中,分片可用于填充临时组织的一组数据库。In other scenarios, such as ingestion of data from distributed devices, sharding can be used to fill a set of databases that are organized temporally. 例如,可以在每天或每周专门使用某个单独的数据库。For example, a separate database can be dedicated to each day or week. 在该情况下,分片键可以是一个表示日期的整数(显示在分片表的所有行中),应用程序必须将用于检索有关日期范围的信息的查询路由到涉及相关范围的数据库子集。In that case, the sharding key can be an integer representing the date (present in all rows of the sharded tables) and queries retrieving information for a date range must be routed by the application to the subset of databases covering the range in question.

当应用程序中的每个事务均受限于分片键的单个值时,分片效果最佳。Sharding works best when every transaction in an application can be restricted to a single value of a sharding key. 这确保了所有事务对特定数据库而言都是本地的。That ensures that all transactions are local to a specific database.

多租户和单租户Multi-tenant and single-tenant

某些应用程序使用最简单的方法为每个租户创建一个单独的数据库。Some applications use the simplest approach of creating a separate database for each tenant. 此方法是单租户分片模式,它提供了隔离、备份/还原功能,还可根据租户粒度进行资源缩放。This approach is the single tenant sharding pattern that provides isolation, backup/restore ability, and resource scaling at the granularity of the tenant. 借助单租户分片,每个数据库都将与特定租户 ID 值(或客户键值)关联,而该键无需始终出现在数据本身中。With single tenant sharding, each database is associated with a specific tenant ID value (or customer key value), but that key need not always be present in the data itself. 应用程序负责将每个请求路由到相应的数据库 - 客户端库可以简化这种操作。It is the application's responsibility to route each request to the appropriate database - and the client library can simplify this.


其他方案是将多个租户一同打包到数据库中,而非将其隔离到单独的数据库中。Others scenarios pack multiple tenants together into databases, rather than isolating them into separate databases. 此模式是典型的多租户分片模式,该模式可能取决于应用程序可管理大量极小型租户这一情况。This pattern is a typical multi-tenant sharding pattern - and it may be driven by the fact that an application manages large numbers of small tenants. 在多租户分片中,数据库表中的行全都被设计为带有可标识租户 ID 的键或分片键。In multi-tenant sharding, the rows in the database tables are all designed to carry a key identifying the tenant ID or sharding key. 同样,应用程序层负责将租户的请求路由到相应的数据库,而弹性数据库客户端库可以支持这种操作。Again, the application tier is responsible for routing a tenant's request to the appropriate database, and this can be supported by the elastic database client library. 另外,可以使用低级别安全性来筛选每个租户可以访问的行。In addition, row-level security can be used to filter which rows each tenant can access . 多租户分片模式可能需要在数据库之间重新分配数据,而弹性数据库拆分/合并工具可帮助实现此目的。Redistributing data among databases may be needed with the multi-tenant sharding pattern, and is facilitated by the elastic database split-merge tool.

将数据从多租户数据库移到单租户数据库Move data from multiple to single-tenancy databases

在创建 SaaS 应用程序时,通常会给潜在客户提供试用版本。When creating a SaaS application, it is typical to offer prospective customers a trial version of the software. 在此情况下,使用多租户数据库来处理数据较符合成本效益。In this case, it is cost-effective to use a multi-tenant database for the data. 不过,当潜在客户成为真正客户后,单租户数据库就更好,因为它提供更好的性能。However, when a prospect becomes a customer, a single-tenant database is better since it provides better performance. 如果客户在试用期间创建了数据,可以使用拆分/合并工具将数据从多租户数据库移到新的单租户数据库。If the customer had created data during the trial period, use the split-merge tool to move the data from the multi-tenant to the new single-tenant database.

后续步骤Next steps

有关演示客户端库的示例应用,请参阅弹性数据库工具入门For a sample app that demonstrates the client library, see Get started with Elastic Database tools.

若要转换现有的数据库以使用该工具,请参阅迁移要扩展的现有数据库To convert existing databases to use the tools, see Migrate existing databases to scale out.

若要查看弹性池的具体信息,请参阅弹性池的价格和性能注意事项,或者参考弹性池创建新池。To see the specifics of the elastic pool, see Price and performance considerations for an elastic pool, or create a new pool with elastic pools.

其他资源Additional resources

尚未使用弹性数据库工具?Not using elastic database tools yet? 请查看入门指南Check out our Getting Started Guide.