使用 Azure SQL Database 相應放大Scaling out with Azure SQL Database

您可以使用 彈性資料庫 工具,輕鬆地向外擴充 Azure SQL 資料庫。You can easily scale out Azure SQL databases using the Elastic Database tools. 這些工具和功能可讓您使用 Azure SQL Database 中的資料庫資源,建立交易式工作負載的解決方案,尤其是軟體即服務 (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. 一組 Azure SQL 資料庫 使用分區化架構裝載於 Azure 中。A set of Azure SQL databases are 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 are put into an elastic pool. (請參閱 何謂集區?)。(See What is a pool?).
  4. 彈性資料庫作業會針對所有資料庫執行排定的或 ad-hoc 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 database 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. 這也稱為「相應放大」。This is 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 performance level of an individual database—this is 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

分區化是一種將大量相同結構的資料分散在許多獨立資料庫的技術。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 a single database
  • 整體工作負載的交易輸送量超過單一資料庫的能力The transaction throughput of the overall workload exceeds the capabilities of a single 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 is the single tenant sharding pattern that provides isolation, backup/restore ability, and resource scaling at the granularity of the tenant. 使用單一租用戶分區化時,每個資料庫與特定的租用戶識別碼值 (或客戶索引鍵值) 相關聯,但該索引鍵不一定出現在資料本身。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 is a typical multi-tenant sharding pattern - and it may be driven by the fact that an application manages large numbers of small tenants. 在多租用戶分區化中,資料庫資料表中的資料列都設計成具有索引鍵 (識別租用戶識別碼) 或分區化索引鍵。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 - for details, see Multi-tenant applications with elastic database tools and row-level security. 多租用戶分區化模式可能需要在資料庫之間重新分配資料,而彈性資料庫分割合併工具可協助達成此工作。Redistributing data among databases may be needed with the multi-tenant sharding pattern, and this is facilitated by the elastic database split-merge tool. 若要深入了解使用彈性集區的 SaaS 應用程式的設計模式,請參閱 多租用戶 SaaS 應用程式與 Azure SQL Database 的設計模式To learn more about design patterns for SaaS applications using elastic pools, see Design Patterns for Multi-tenant SaaS Applications with Azure SQL Database.

將資料從多租用戶資料庫移到單一租用戶資料庫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. 如有問題,請透過 SQL Database 論壇與我們連絡,如需要求增加功能,請將這些功能新增至 SQL Database 意見反應論壇For questions, please reach out to us on the SQL Database forum and for feature requests, please add them to the SQL Database feedback forum.