Montée en charge avec la base de données SQL AzureScaling out with Azure SQL Database

Vous pouvez facilement faire évoluer les bases de données SQL Azure à l’aide des outils de base de données élastique .You can easily scale out Azure SQL databases using the Elastic Database tools. Ces outils et fonctionnalités vous permettent d’utiliser les ressources de la base de données SQL Azure pour créer des solutions pour les charges de travail transactionnelles et notamment les applications Software as a Service (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. Les fonctionnalités de base de données élastique se composent des éléments suivants :Elastic Database features are composed of the:

L’illustration ci-dessous montre une architecture qui inclut les fonctionnalités de base de données élastique liées à une collection de bases de données.The following graphic shows an architecture that includes the Elastic Database features in relation to a collection of databases.

Dans ce graphique, les couleurs de la base de données représentent des schémas.In this graphic, colors of the database represent schemas. Les bases de données de même couleur partagent le même schéma.Databases with the same color share the same schema.

  1. Un ensemble de bases de données SQL Azure est hébergé sur Azure avec une architecture de partitionnement.A set of Azure SQL databases are hosted on Azure using sharding architecture.
  2. La bibliothèque cliente de base de données élastique sert à gérer un ensemble de partitions.The Elastic Database client library is used to manage a shard set.
  3. Un sous-ensemble des bases de données est placé dans un pool élastique.A subset of the databases are put into an elastic pool. (Voir Qu’est-ce qu’un pool ?).(See What is a pool?).
  4. Une tâche de base de données élastique exécute des scripts T-SQL planifiés ou ad hoc sur toutes les bases de données.An Elastic Database job runs scheduled or ad hoc T-SQL scripts against all databases.
  5. L’ outil de fusion et fractionnement sert à déplacer des données d’une partition à l’autre.The split-merge tool is used to move data from one shard to another.
  6. La requête de base de données élastique vous permet d’écrire une requête qui s’étend sur toutes les bases de données de l’ensemble de partitions.The Elastic Database query allows you to write a query that spans all databases in the shard set.
  7. Les transactions élastiques vous permettent d’exécuter des transactions qui s’étendent sur plusieurs bases de données.Elastic transactions allow you to run transactions that span several databases.

Outils de base de données élastique

Pourquoi utiliser les outils ?Why use the tools?

Obtenir l’élasticité et l’évolutivité pour les applications cloud a été simple pour les machines virtuelles et le stockage d’objets blob. En effet, il suffit d’ajouter ou de soustraire des unités, ou d’augmenter la puissance.Achieving elasticity and scale for cloud applications has been straightforward for VMs and blob storage - simply add or subtract units, or increase power. Mais cela reste un défi pour le traitement des informations de bases de données relationnelles.But it has remained a challenge for stateful data processing in relational databases. Des difficultés sont apparues dans les scénarios suivants :Challenges emerged in these scenarios:

  • Agrandissement et réduction des capacités pour la partie base de données relationnelle de votre charge de travail.Growing and shrinking capacity for the relational database part of your workload.
  • Gestion des zones réactives susceptibles de survenir et d’affecter un sous-ensemble de données spécifique, comme un client final très occupé (locataire).Managing hotspots that may arise affecting a specific subset of data - such as a busy end-customer (tenant).

Traditionnellement, ces types de scénarios ont été résolus en investissant dans des serveurs de base de données à plus grande échelle de manière à prendre en charge l’application.Traditionally, scenarios like these have been addressed by investing in larger-scale database servers to support the application. Toutefois, cette option est limitée dans le cloud où tous les traitements se produisent sur un matériel prédéfini.However, this option is limited in the cloud where all processing happens on predefined commodity hardware. La distribution des données et le traitement sur plusieurs bases de données ayant la même structure (un schéma de montée en charge connu sous le terme « partitionnement ») constituent une alternative aux approches traditionnelles de montée en charge, à la fois en matière de coût et d’élasticité.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.

Mise à l’échelle horizontale et verticaleHorizontal and vertical scaling

La figure ci-dessous illustre les dimensions horizontales et verticales de la mise à l'échelle, qui représentent les méthodes de base de mise à l'échelle des bases de données élastiques.The following figure shows the horizontal and vertical dimensions of scaling, which are the basic ways the elastic databases can be scaled.

Comparaison entre la montée en charge horizontale et verticale

La mise à l’échelle horizontale fait référence à l’ajout ou la suppression des bases de données afin d’ajuster les capacités ou les performances globales.Horizontal scaling refers to adding or removing databases in order to adjust capacity or overall performance. Cette procédure est fréquemment appelée « montée en charge ».This is also called “scaling out”. Le partitionnement est une approche courante de mise à l’échelle horizontale, dans laquelle les données sont partitionnées sur une collection de bases de données structurées de manière identique.Sharding, in which data is partitioned across a collection of identically structured databases, is a common way to implement horizontal scaling.

La mise à l’échelle verticale fait référence à l’augmentation ou à la réduction du niveau de performance d’une base de données individuelle et est également appelée « mise à l’échelle vers le haut ».Vertical scaling refers to increasing or decreasing the performance level of an individual database—this is also known as “scaling up.”

La plupart des applications de base de données à l’échelle du cloud associent ces deux stratégies.Most cloud-scale database applications use a combination of these two strategies. Par exemple, une application Software as a Service peut utiliser la mise à l’échelle horizontale pour approvisionner les nouveaux clients finaux et la mise à l’échelle verticale pour permettre l’augmentation ou la diminution des ressources de la base de données du client final, en fonction des besoins de la charge de travail.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.

  • La mise à l’échelle horizontale est gérée à l’aide de la bibliothèque cliente de base de données élastique.Horizontal scaling is managed using the Elastic Database client library.
  • La mise à l’échelle verticale est effectuée à l’aide des applets de commande Azure PowerShell pour modifier le niveau de service, ou en plaçant des bases de données dans un pool élastique.Vertical scaling is accomplished using Azure PowerShell cmdlets to change the service tier, or by placing databases in an elastic pool.

PartitionnementSharding

Le partitionnement est une technique permettant de distribuer de grandes quantités de données structurées de façon identique entre plusieurs bases de données indépendantes.Sharding is a technique to distribute large amounts of identically structured data across a number of independent databases. Il est particulièrement populaire auprès des développeurs cloud qui créent des offres Software as a Service (SAAS) pour les clients finaux ou les entreprises.It is especially popular with cloud developers creating Software as a Service (SAAS) offerings for end customers or businesses. Ces clients finaux sont souvent appelés « locataires ».These end customers are often referred to as “tenants”. Le partitionnement peut être nécessaire pour plusieurs raisons :Sharding may be required for any number of reasons:

  • La quantité totale de données est trop grande pour tenir dans les contraintes d'une base de données uniqueThe total amount of data is too large to fit within the constraints of a single database
  • Le débit des transactions de la charge de travail globale dépasse les capacités d'une base de données uniqueThe transaction throughput of the overall workload exceeds the capabilities of a single database
  • Les locataires peuvent nécessiter une isolation physique l'un de l'autre, donc des bases de données distinctes sont nécessaires pour chaque locataireTenants may require physical isolation from each other, so separate databases are needed for each tenant
  • Différentes sections d’une base de données peuvent se trouver dans différentes zones géographiques pour des raisons géopolitiques, de performances ou de conformité.Different sections of a database may need to reside in different geographies for compliance, performance, or geopolitical reasons.

Dans d'autres scénarios, telle la réception de données à partir d'appareils distribués, le partitionnement peut servir à remplir un ensemble de bases de données organisées en fonction du temps.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. Par exemple, une base de données distincte peut être dédiée à chaque jour ou chaque semaine.For example, a separate database can be dedicated to each day or week. Dans ce cas, la clé de partitionnement peut être un entier représentant la date (présente dans toutes les lignes des tables partitionnées) et les requêtes qui retournent des informations pour une plage de dates doivent être acheminées par l’application vers le sous-ensemble de bases de données couvrant la plage en question.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.

Le partitionnement fonctionne mieux lorsque toutes les transactions d'une application peuvent être limitées à une seule valeur de clé de partitionnement.Sharding works best when every transaction in an application can be restricted to a single value of a sharding key. Cela permet de garantir que toutes les transactions sont locales à une base de données spécifique.That ensures that all transactions are local to a specific database.

Architecture mutualisée et architecture à un seul locataireMulti-tenant and single-tenant

Certaines applications utilisent l'approche la plus simple consistant à créer une base de données distincte pour chaque locataire.Some applications use the simplest approach of creating a separate database for each tenant. C’est le modèle de partitionnement par locataire unique qui offre des fonctionnalités d’isolation, de sauvegarde/restauration et de mise à l’échelle des ressources au niveau de granularité du locataire.This is the single tenant sharding pattern that provides isolation, backup/restore ability, and resource scaling at the granularity of the tenant. Avec le partitionnement par locataire unique, chaque base de données est associée à une valeur d'identifiant de locataire spécifique (ou la valeur de clé du client), mais il n'est pas nécessaire que cette clé soit toujours présente dans les données elles-mêmes.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. L’application est responsable de l’acheminement de chaque demande vers la base de données appropriée. Et la bibliothèque cliente peut simplifier cette procédure.It is the application’s responsibility to route each request to the appropriate database - and the client library can simplify this.

Comparaison entre l’architecture à locataire unique et l’architecture mutualisée

D'autres scénarios regroupent plusieurs locataires dans des bases de données, plutôt que de les isoler dans des bases de données distinctes.Others scenarios pack multiple tenants together into databases, rather than isolating them into separate databases. Il s’agit d’un modèle type de partitionnement à plusieurs locataires et il peut être nécessaire lorsqu’une application gère un grand nombre de petits locataires.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. Dans un partitionnement à plusieurs locataires, les lignes des tables de base de données sont toutes conçues pour comporter une clé identifiant l'ID du locataire ou la clé de partitionnement.In multi-tenant sharding, the rows in the database tables are all designed to carry a key identifying the tenant ID or sharding key. Là encore, la couche Application est responsable de l’acheminement de la demande d’un locataire vers la base de données appropriée et la bibliothèque cliente de base de données élastique peut prendre cette procédure en charge.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. En outre, le dispositif de sécurité au niveau des lignes peut servir à filtrer les lignes auxquelles chaque locataire peut accéder. Pour plus d’informations, consultez Applications multi-locataires avec des outils de base de données élastique et la sécurité au niveau des lignes.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. Il peut être nécessaire de redistribuer les données entre les bases de données à l’aide du modèle de partitionnement à plusieurs locataires. L’outil de fusion et de fractionnement des bases de données élastiques permet de faciliter cette procédure.Redistributing data among databases may be needed with the multi-tenant sharding pattern, and this is facilitated by the elastic database split-merge tool. Pour en savoir plus sur les modèles de conception pour les applications SaaS avec des pools élastiques, voir Design Patterns for Multi-tenant SaaS Applications with Azure SQL Database(Modèles de conception pour les applications SaaS mutualisées avec la base de données SQL Azure).To learn more about design patterns for SaaS applications using elastic pools, see Design Patterns for Multi-tenant SaaS Applications with Azure SQL Database.

Déplacement de données de bases de données à plusieurs locataires vers des bases de données à un seul locataireMove data from multiple to single-tenancy databases

Lorsque vous créez une application SaaS, il est courant d'offrir aux clients potentiels une version d'évaluation du logiciel.When creating a SaaS application, it is typical to offer prospective customers a trial version of the software. Dans ce cas, il est plus rentable d'utiliser une base de données à plusieurs locataires pour les données.In this case, it is cost-effective to use a multi-tenant database for the data. Toutefois, lorsqu'un prospect devient un client, une base de données à un seul locataire est préférable car elle offre de meilleures performances.However, when a prospect becomes a customer, a single-tenant database is better since it provides better performance. Si le client a créé des données pendant la période d’évaluation, utilisez l’ outil de fusion et de fractionnement pour déplacer les données de la base de données à plusieurs locataires vers la nouvelle base de données à un seul locataire.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.

Étapes suivantesNext steps

Pour obtenir un exemple d’application illustrant la bibliothèque cliente, voir Prise en main des outils de base de données élastique.For a sample app that demonstrates the client library, see Get started with Elastic Database tools.

Pour convertir des bases de données existantes afin d’utiliser les outils, voir Migrer des bases de données existantes pour la montée en charge.To convert existing databases to use the tools, see Migrate existing databases to scale out.

Pour plus de détails sur le pool élastique, consultez Considérations sur les prix et performances pour un pool élastique ou créez un pool à l’aide des pools élastiques.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.

Ressources supplémentairesAdditional resources

Vous n’utilisez pas encore d’outils de base de données élastique ?Not using elastic database tools yet? Consultez notre Guide de prise en main.Check out our Getting Started Guide. Pour toute question, contactez-nous sur le forum SQL Database et formulez vos demandes de fonctionnalités éventuelles sur le forum de commentaires 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.