Uitbreiden met Azure SQL DatabaseScaling out with Azure SQL Database

U kunt Azure SQL-data bases eenvoudig uitschalen met behulp van de Elastic database -hulpprogram ma's.You can easily scale out Azure SQL databases using the Elastic Database tools. Met deze hulpprogram ma's en functies kunt u de database resources van Azure SQL database gebruiken om oplossingen te maken voor transactionele werk belastingen, en met name SaaS-toepassingen (Software as a Service).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-functies bestaan uit het volgende:Elastic Database features are composed of the:

In de volgende afbeelding ziet u een architectuur die de Elastic database-functies bevat ten opzichte van een verzameling data bases.The following graphic shows an architecture that includes the Elastic Database features in relation to a collection of databases.

In deze afbeelding vertegenwoordigen de kleuren van de data base schema's.In this graphic, colors of the database represent schemas. Data bases met dezelfde kleur delen hetzelfde schema.Databases with the same color share the same schema.

  1. Een set Azure SQL-data bases wordt gehost op Azure met behulp van de sharding-architectuur.A set of Azure SQL databases is hosted on Azure using sharding architecture.
  2. De Elastic database-client bibliotheek wordt gebruikt voor het beheren van een Shard-set.The Elastic Database client library is used to manage a shard set.
  3. Een subset van de data bases wordt in een elastische poolgeplaatst.A subset of the databases is put into an elastic pool. (Zie Wat is een pool?).(See What is a pool?).
  4. Met een Elastic database taak worden geplande of ad hoc T-SQL-scripts uitgevoerd voor alle data bases.An Elastic Database job runs scheduled or ad hoc T-SQL scripts against all databases.
  5. Het hulp programma splitsen wordt gebruikt om gegevens van een Shard naar een andere te verplaatsen.The split-merge tool is used to move data from one shard to another.
  6. Met de Elastic database query kunt u een query schrijven die alle data bases in de Shard-set omspant.The Elastic Database query allows you to write a query that spans all databases in the shard set.
  7. Met elastische trans acties kunt u trans acties uitvoeren die meerdere data bases omvatten.Elastic transactions allow you to run transactions that span several databases.

Hulpprogramma's voor elastische databases

Waarom zou u de hulpprogram ma's gebruiken?Why use the tools?

Het bereiken van de elasticiteit en schaal voor Cloud toepassingen is eenvoudig voor Vm's en Blob Storage. u hoeft alleen maar de eenheden toe te voegen of af te trekken, of de stroom te verg Roten.Achieving elasticity and scale for cloud applications has been straightforward for VMs and blob storage - simply add or subtract units, or increase power. Maar er is wel een uitdaging voor het verwerken van stateful gegevens in relationele data bases.But it has remained a challenge for stateful data processing in relational databases. De uitdagingen in deze scenario's:Challenges emerged in these scenarios:

  • Groei en krimping van capaciteit voor het deel van de relationele data base van uw werk belasting.Growing and shrinking capacity for the relational database part of your workload.
  • Het beheren van HOTS pots die mogelijk van invloed zijn op een specifieke subset van gegevens, zoals een drukke eind gebruiker (Tenant).Managing hotspots that may arise affecting a specific subset of data - such as a busy end-customer (tenant).

In de meeste gevallen zijn scenario's zoals deze beschreven door investeren in grotere database servers voor de ondersteuning van de toepassing.Traditionally, scenarios like these have been addressed by investing in larger-scale database servers to support the application. Deze optie is echter beperkt in de Cloud, waar alle verwerking plaatsvindt op vooraf gedefinieerde basishardware.However, this option is limited in the cloud where all processing happens on predefined commodity hardware. In plaats daarvan is het distribueren van gegevens en verwerking in veel identieke gestructureerde data bases (een scale-out patroon bekend als ' sharding ') een alternatief voor traditionele scale-up benaderingen op het gebied van kosten en elasticiteit.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.

Horizon taal en verticaal schalenHorizontal and vertical scaling

In de volgende afbeelding ziet u de horizontale en verticale afmetingen van schalen. Dit zijn de basis manieren waarop de elastische data bases kunnen worden geschaald.The following figure shows the horizontal and vertical dimensions of scaling, which are the basic ways the elastic databases can be scaled.

Horizon taal versus verticaal uitschalen

Horizon taal schalen verwijst naar het toevoegen of verwijderen van data bases voor het aanpassen van de capaciteit of de algehele prestaties, ook wel ' uitschalen ' genoemd.Horizontal scaling refers to adding or removing databases in order to adjust capacity or overall performance, also called “scaling out”. Sharding, waarin gegevens worden gepartitioneerd over een verzameling van identieke gestructureerde data bases, is een gemeen schappelijke manier om horizon taal schalen te implementeren.Sharding, in which data is partitioned across a collection of identically structured databases, is a common way to implement horizontal scaling.

Verticaal schalen verwijst naar het verg Roten of verkleinen van de reken grootte van een afzonderlijke Data Base, ook wel bekend als ' omhoog schalen '.Vertical scaling refers to increasing or decreasing the compute size of an individual database, also known as “scaling up.”

De meeste database toepassingen in de Cloud gebruiken een combi natie van deze twee strategieën.Most cloud-scale database applications use a combination of these two strategies. Een software als een service toepassing kan bijvoorbeeld horizon taal schalen gebruiken om nieuwe eind gebruikers en verticale schaling in te richten, zodat de data base van elke eind gebruiker de resources kan verg Roten of verkleinen als dat nodig is voor de werk belasting.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.

  • Horizon taal schalen wordt beheerd met behulp van de Elastic database-client bibliotheek.Horizontal scaling is managed using the Elastic Database client library.
  • Verticaal schalen wordt uitgevoerd met behulp van Azure PowerShell-cmdlets om de servicelaag te wijzigen of door data bases in een elastische pool te plaatsen.Vertical scaling is accomplished using Azure PowerShell cmdlets to change the service tier, or by placing databases in an elastic pool.

ShardingSharding

Sharding is een techniek om grote hoeveel heden identieke, gestructureerde gegevens over een aantal onafhankelijke data bases te verdelen.Sharding is a technique to distribute large amounts of identically structured data across a number of independent databases. Het is met name populair bij Cloud ontwikkelaars die software as a Service (SAAS)-aanbiedingen voor eind klanten of bedrijven maken.It is especially popular with cloud developers creating Software as a Service (SAAS) offerings for end customers or businesses. Deze eind klanten worden vaak ' tenants ' genoemd.These end customers are often referred to as “tenants”. Sharding kan om verschillende redenen vereist zijn:Sharding may be required for any number of reasons:

  • De totale hoeveelheid gegevens is te groot om te passen binnen de beperkingen van een afzonderlijke data baseThe total amount of data is too large to fit within the constraints of an individual database
  • De trans actie-door Voer van de totale werk belasting overschrijdt de mogelijkheden van een afzonderlijke data baseThe transaction throughput of the overall workload exceeds the capabilities of an individual database
  • Tenants kunnen fysieke isolatie van elkaar vereisen, zodat afzonderlijke data bases nodig zijn voor elke TenantTenants may require physical isolation from each other, so separate databases are needed for each tenant
  • Verschillende secties van een Data Base moeten mogelijk in verschillende geografische grafieken worden geplaatst om te voldoen aan de vereisten, de prestaties of de geopolitieke redenen.Different sections of a database may need to reside in different geographies for compliance, performance, or geopolitical reasons.

In andere scenario's, zoals het opnemen van gegevens van gedistribueerde apparaten, kan sharding worden gebruikt voor het vullen van een set data bases die tijdelijk zijn geordend.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. Een afzonderlijke Data Base kan bijvoorbeeld worden toegewezen aan elke dag of week.For example, a separate database can be dedicated to each day or week. In dat geval kan de sharding-sleutel een geheel getal zijn dat de datum vertegenwoordigt (aanwezig in alle rijen van de Shard-tabellen) en moeten query's die informatie ophalen voor een datum bereik door de toepassing worden gerouteerd naar de subset van data bases die het desbetreffende bereik hebben.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 werkt het beste wanneer elke trans actie in een toepassing kan worden beperkt tot één waarde van een sharding-sleutel.Sharding works best when every transaction in an application can be restricted to a single value of a sharding key. Hiermee zorgt u ervoor dat alle trans acties lokaal zijn voor een specifieke data base.That ensures that all transactions are local to a specific database.

Multi tenant en single-tenantMulti-tenant and single-tenant

Sommige toepassingen gebruiken de eenvoudigste benadering van het maken van een afzonderlijke Data Base voor elke Tenant.Some applications use the simplest approach of creating a separate database for each tenant. Deze benadering is het sharding-patroon met één Tenant dat isolatie, back-ups maken/herstellen en het schalen van resources biedt bij de granulatie van de Tenant.This approach is the single tenant sharding pattern that provides isolation, backup/restore ability, and resource scaling at the granularity of the tenant. Bij één Tenant sharding wordt elke Data Base gekoppeld aan een specifieke Tenant-ID-waarde (of de waarde van de klant sleutel), maar deze sleutel hoeft niet altijd aanwezig te zijn in de gegevens zelf.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. Het is de verantwoordelijkheid van de toepassing om elke aanvraag te routeren naar de juiste data base en de client bibliotheek kan dit vereenvoudigen.It is the application’s responsibility to route each request to the appropriate database - and the client library can simplify this.

Eén Tenant versus multi tenant

Andere scenario's verpakken meerdere tenants in data bases in plaats van ze te isoleren in afzonderlijke data bases.Others scenarios pack multiple tenants together into databases, rather than isolating them into separate databases. Dit patroon is een typisch sharding patroon met meerdere tenants en kan worden aangestuurd door het feit dat een toepassing een groot aantal kleine tenants beheert.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. In multi tenant-sharding zijn de rijen in de database tabellen allemaal ontworpen om een sleutel te bieden voor het identificeren van de Tenant-ID of de sharding-sleutel.In multi-tenant sharding, the rows in the database tables are all designed to carry a key identifying the tenant ID or sharding key. Daarnaast is de toepassingslaag verantwoordelijk voor het routeren van de aanvraag van een Tenant naar de juiste data base. Dit kan worden ondersteund door de client bibliotheek voor Elastic data base.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. Daarnaast kan beveiliging op rijniveau worden gebruikt om te filteren tot welke rijen elke Tenant toegang heeft. Zie multi tenant-toepassingen met Elastic data base-hulpprogram ma's en beveiliging op rijniveauvoor meer informatie.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. Het opnieuw distribueren van gegevens tussen data bases is mogelijk nodig met het sharding-patroon met meerdere tenants en wordt vergemakkelijkt door het Elastic data base-hulp programma voor splitsen en samen voegen.Redistributing data among databases may be needed with the multi-tenant sharding pattern, and is facilitated by the elastic database split-merge tool. Zie Ontwerppatronen voor SaaS-toepassingen met meerdere tenants met behulp van Azure SQL Database voor meer informatie over ontwerppatronen voor SaaS-toepassingen met elastische pools.To learn more about design patterns for SaaS applications using elastic pools, see Design Patterns for Multi-tenant SaaS Applications with Azure SQL Database.

Gegevens verplaatsen van meerdere naar single-pacht data basesMove data from multiple to single-tenancy databases

Bij het maken van een SaaS-toepassing is het gebruikelijk om potentiële klanten een evaluatie versie van de software aan te bieden.When creating a SaaS application, it is typical to offer prospective customers a trial version of the software. In dit geval is het rendabel om een Data Base met meerdere tenants te gebruiken voor de gegevens.In this case, it is cost-effective to use a multi-tenant database for the data. Wanneer een prospect echter een klant wordt, is een Data Base met één Tenant beter omdat deze betere prestaties levert.However, when a prospect becomes a customer, a single-tenant database is better since it provides better performance. Als de klant tijdens de proef periode gegevens heeft gemaakt, gebruikt u het hulp programma voor splitsen en samen voegen om de gegevens van de multi tenant naar de nieuwe Data Base met één Tenant te verplaatsen.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.

Volgende stappenNext steps

Zie aan de slag met Elastic database-hulpprogram ma'svoor een voor beeld-app die de client bibliotheek laat zien.For a sample app that demonstrates the client library, see Get started with Elastic Database tools.

Zie bestaande data bases migreren om uit te breidenvoor het converteren van bestaande data bases om de hulpprogram ma's te gebruiken.To convert existing databases to use the tools, see Migrate existing databases to scale out.

Zie prijs-en prestatie overwegingen voor een elastische poolof een nieuwe groep maken met elastischePools voor een overzicht van de details van de elastische pool.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.

Aanvullende resourcesAdditional resources

Geen gebruik van hulpmiddelen voor elastic database nog?Not using elastic database tools yet? Bekijk onze Getting Started Guide.Check out our Getting Started Guide. U vragen hebt, neemt u contact met ons op de forum van SQL-Database en voor functieaanvragen, deze toe te voegen aan de forum met feedback van 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.