Uitbreiden met Azure SQL DatabaseScaling out with Azure SQL Database

U kunt gemakkelijk schalen van Azure SQL-databases met behulp van de Elastic Database hulpprogramma's.You can easily scale out Azure SQL databases using the Elastic Database tools. Deze hulpprogramma's en functies, kunt u de bronnen van Azure SQL Database om oplossingen voor transactionele werkbelastingen en met name Software als een Service (SaaS)-toepassingen te maken.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. Functies voor elastische Database worden samengesteld uit de:Elastic Database features are composed of the:

De volgende afbeelding toont een architectuur met de functies voor elastische Database ten opzichte van een verzameling van databases.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 database schema's.In this graphic, colors of the database represent schemas. Databases met dezelfde kleur delen hetzelfde schema.Databases with the same color share the same schema.

  1. Een set Azure SQL-databases wordt gehost op Azure met behulp van sharding-architectuur.A set of Azure SQL databases is hosted on Azure using sharding architecture.
  2. De Elastic Database-clientbibliotheek wordt gebruikt voor het beheren van een shard-verzameling.The Elastic Database client library is used to manage a shard set.
  3. Een subset van de databases wordt geplaatst in een elastische pool.A subset of the databases is put into an elastic pool. (Zie wat is een pool?).(See What is a pool?).
  4. Een elastische taak geplande of ad hoc T-SQL-scripts op alle databases wordt uitgevoerd.An Elastic Database job runs scheduled or ad hoc T-SQL scripts against all databases.
  5. De hulpprogramma voor splitsen en samenvoegen wordt gebruikt voor het verplaatsen van gegevens uit één shard naar een andere.The split-merge tool is used to move data from one shard to another.
  6. De elastische databasequery kunt u een query schrijven waarmee alle databases in de shard-set omvat.The Elastic Database query allows you to write a query that spans all databases in the shard set.
  7. Elastische transacties kunt u uitvoeren van transacties met betrekking verschillende databases tot.Elastic transactions allow you to run transactions that span several databases.

Hulpprogramma's voor elastische databases

Waarom de hulpprogramma's gebruiken?Why use the tools?

Bereiken van flexibiliteit en schaalbaarheid voor cloud-Apps is eenvoudig voor VM's en blob-opslag - gewoon toevoegen of eenheden aftrekken of power verhogen.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 een uitdaging voor stateful gegevensverwerking in relationele databases gebleven.But it has remained a challenge for stateful data processing in relational databases. Uitdagingen naar voren gekomen in deze scenario's:Challenges emerged in these scenarios:

  • Vergroten en verkleinen capaciteit voor de relationele database die deel uitmaken van uw workload.Growing and shrinking capacity for the relational database part of your workload.
  • Het beheren van hotspots die kunnen ontstaan die betrekking hebben op een specifieke subset van gegevens -, zoals een bezet eindklant (tenant).Managing hotspots that may arise affecting a specific subset of data - such as a busy end-customer (tenant).

Traditioneel zijn scenario's zoals deze opgelost door te 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 wordt echter beperkt in de cloud waar alle verwerking op vooraf gedefinieerde basishardware plaatsvindt.However, this option is limited in the cloud where all processing happens on predefined commodity hardware. Distribueren van gegevens en -verwerking voor verschillende databases van dezelfde gestructureerde biedt (een scale-out-patroon 'sharding' genoemd) in plaats daarvan een alternatief voor traditionele omhoog benaderingen, zowel wat betreft de kosten en flexibiliteit.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.

Horizontaal en verticaal schalenHorizontal and vertical scaling

De volgende afbeelding toont de horizontale en verticale afmetingen van de schaal, dit zijn de manieren waarop die de elastische databases 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.

Horizontale en verticale scale-out

Horizontaal schalen verwijst naar het toevoegen of verwijderen van databases om te kunnen passen capaciteit of algehele prestaties, ook wel genoemd 'schaal' uit.Horizontal scaling refers to adding or removing databases in order to adjust capacity or overall performance, also called “scaling out”. Sharding, waarin de gegevens zijn gepartitioneerd over een verzameling van identieke gestructureerde databases, is een veelgebruikte manier voor het implementeren van horizontaal schalen.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 vergroten of verkleinen het berekenen van een individuele database, ook wel bekend als 'omhoog."Vertical scaling refers to increasing or decreasing the compute size of an individual database, also known as “scaling up.”

De meeste toepassingen op cloudschaal database een combinatie van deze twee strategieën gebruiken.Most cloud-scale database applications use a combination of these two strategies. Bijvoorbeeld, kunt een Software als een servicetoepassing horizontaal schalen voor het inrichten van nieuwe end-klanten en verticaal schalen waarmee elke eindgebruiker database vergroten of verkleinen van resources, indien nodig door de werkbelasting.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.

  • Horizontaal schalen wordt beheerd met behulp van de Elastic Database-clientbibliotheek.Horizontal scaling is managed using the Elastic Database client library.
  • Verticaal schalen is uitgevoerd met behulp van Azure PowerShell-cmdlets te wijzigen van de servicelaag of door databases in een elastische pool.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 voor de distributie van grote hoeveelheden identiek gestructureerde gegevens over een aantal onafhankelijke databases.Sharding is a technique to distribute large amounts of identically structured data across a number of independent databases. Het is met name populaire met cloudontwikkelaars die het maken van Software als een Service (SAAS)-aanbiedingen voor eindgebruikers of bedrijven.It is especially popular with cloud developers creating Software as a Service (SAAS) offerings for end customers or businesses. Deze end-klanten worden vaak aangeduid als 'huurder'.These end customers are often referred to as “tenants”. Sharding is mogelijk vereist voor een aantal oorzaken hebben:Sharding may be required for any number of reasons:

  • De totale hoeveelheid gegevens is te groot om te passen binnen de beperkingen van een individuele databaseThe total amount of data is too large to fit within the constraints of an individual database
  • De transactiedoorvoer van de totale werklast groter is dan de mogelijkheden van een individuele databaseThe transaction throughput of the overall workload exceeds the capabilities of an individual database
  • Tenants mogelijk fysiek geïsoleerd van elkaar, zodat u afzonderlijke databases nodig zijn voor elke tenantTenants may require physical isolation from each other, so separate databases are needed for each tenant
  • Verschillende secties van een database moet mogelijk bevinden zich in verschillende fysieke locaties voor naleving, prestaties of 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 de opname van gegevens van gedistribueerde apparaten kan sharding worden gebruikt om in te vullen van een set databases die tijdelijk zijn ingedeeld.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 aparte database 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 dat aangeeft van de datum (aanwezig zijn in alle rijen van de shard tabellen) en query's bij het ophalen van gegevens voor een bepaalde periode moeten worden gerouteerd van de toepassing naar de subset van databases die betrekking hebben op het desbetreffende bereik.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 als elke transactie in een toepassing beperkt tot één waarde van een sharding-sleutel worden kan.Sharding works best when every transaction in an application can be restricted to a single value of a sharding key. Dit zorgt ervoor dat alle transacties lokaal op een specifieke database worden.That ensures that all transactions are local to a specific database.

Meerdere tenants en één tenantMulti-tenant and single-tenant

Sommige toepassingen gebruiken de eenvoudigste manier voor het maken van een aparte database voor elke tenant.Some applications use the simplest approach of creating a separate database for each tenant. Deze aanpak is het één tenant sharding-patroon die zorgt voor isolatie, back-up/herstel mogelijkheid en resource schalen zonder dat u 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. Met sharding van één tenant, elke database is gekoppeld aan een specifieke tenant-id-waarde (of waarde van de klant), maar deze sleutel moet niet altijd aanwezig 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 voor het routeren van elke aanvraag naar de juiste database - en deze kan worden vereenvoudigd door de clientbibliotheek.It is the application’s responsibility to route each request to the appropriate database - and the client library can simplify this.

Één tenant ten opzichte van meerdere tenants

Andere scenario's voor meerdere tenants samen pack in de databases in plaats van ze te isoleren in afzonderlijke databases.Others scenarios pack multiple tenants together into databases, rather than isolating them into separate databases. Dit patroon is een typische multitenant sharding-patroon - en deze 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 de sharding van meerdere tenants zijn de rijen in de databasetabellen ontworpen voor het uitvoeren van een sleutel 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. Nogmaals, de toepassingslaag is verantwoordelijk voor de routering van een tenant-aanvraag naar de juiste database en dit kan worden ondersteund door de clientbibliotheek van elastische database.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. Bovendien beveiliging op rijniveau kan worden gebruikt om te filteren welke rijen toegang elke tenant - voor meer informatie tot hebben, Zie multitenant-toepassingen met elastische Databasehulpprogramma's en beveiliging op rijniveau.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. Opnieuw distribueren van gegevens tussen databases kan nodig zijn met het patroon sharding van meerdere tenants, en wordt mogelijk gemaakt door de elastic database-hulpprogramma voor splitsen en samenvoegen.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.

Verplaatsen van gegevens uit meerdere databases voor één-tenantsMove data from multiple to single-tenancy databases

Bij het maken van een SaaS-toepassing, is het typische potentiële klanten bieden een proefversie van de software.When creating a SaaS application, it is typical to offer prospective customers a trial version of the software. In dit geval is het rendabele gebruik van een multitenant-database voor de gegevens.In this case, it is cost-effective to use a multi-tenant database for the data. Wanneer een kandidaat een klant wordt, is een database met één tenant echter beter omdat het levert betere prestaties.However, when a prospect becomes a customer, a single-tenant database is better since it provides better performance. Als de klant gegevens tijdens de proefperiode is afgelopen gemaakt heeft, gebruikt u de hulpprogramma voor splitsen en samenvoegen de gegevens van meerdere tenants verplaatsen naar de nieuwe database met één tenant.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 voor een voorbeeld-app die laat zien van de clientbibliotheek aan de slag met elastische Databasehulpprogramma's.For a sample app that demonstrates the client library, see Get started with Elastic Database tools.

Als u wilt converteren van bestaande databases voor het gebruik van de hulpprogramma's, Zie bestaande databases migreren voor uitschalen.To convert existing databases to use the tools, see Migrate existing databases to scale out.

Zie de details van de elastische pool prijs- en Prestatieoverwegingen voor een elastische pool, of maak een nieuwe groep met elastische pools.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.