Uitbreiden met Azure SQL DatabaseScaling out with Azure SQL Database

Kunt u eenvoudig uitschalen Azure SQL-databases via de elastische Database hulpprogramma's.You can easily scale out Azure SQL databases using the Elastic Database tools. Deze hulpprogramma's en onderdelen kunnen u de database-bronnen van Azure SQL Database om oplossingen voor transactionele werkbelastingen en met name de 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. Elastische databasefuncties bestaan uit de:Elastic Database features are composed of the:

De volgende afbeelding toont een architectuur met de elastische Database functies 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 worden gehost op Azure met behulp van sharding-architectuur.A set of Azure SQL databases are hosted on Azure using sharding architecture.
  2. De clientbibliotheek voor elastische Database wordt gebruikt voor het beheren van een set shard.The Elastic Database client library is used to manage a shard set.
  3. Een subset van de databases worden die pakketten in een elastische pool.A subset of the databases are put into an elastic pool. (Zie wat is er een groep?).(See What is a pool?).
  4. Een elastische Database-taak wordt gepland of ad-hoc T-SQL-scripts uitgevoerd op alle databases.An Elastic Database job runs scheduled or ad hoc T-SQL scripts against all databases.
  5. De gesplitste merge tool wordt gebruikt voor het verplaatsen van gegevens van één shard naar een andere.The split-merge tool is used to move data from one shard to another.
  6. De elastische Database query kunt u een query die alle databases in de shard-set omvat schrijven.The Elastic Database query allows you to write a query that spans all databases in the shard set.
  7. Elastische transacties kunt u transacties op meerdere verschillende databases uitvoeren.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?

Elasticiteit en schaal voor cloud-toepassingen is eenvoudig VM's en de blob-opslag - simpelweg toevoegen of afgetrokken eenheden of vergroot power.Achieving elasticity and scale for cloud applications has been straightforward for VMs and blob storage - simply add or subtract units, or increase power. Maar het moeilijk voor stateful gegevensverwerking in relationele databases is gebleven.But it has remained a challenge for stateful data processing in relational databases. Uitdagingen ontstaan in deze scenario's:Challenges emerged in these scenarios:

  • Groeien en capaciteit voor de relationele database deel uitmaakt van uw workload te verkleinen.Growing and shrinking capacity for the relational database part of your workload.
  • Het beheren van hotspots die kunnen ontstaan die invloed hebben op een specifieke subset van gegevens -, zoals een bezet end-klant (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 door te investeren in grotere schaal databaseservers ter ondersteuning van de toepassing gericht.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 waarbij alle bijbehorende verwerkingen op vooraf gedefinieerde basishardware gebeurt.However, this option is limited in the cloud where all processing happens on predefined commodity hardware. Distributie van gegevens en verwerking tussen meerdere databases van dezelfde gestructureerde bevat (een patroon voor scale-out 'sharding' genoemd) in plaats daarvan een alternatief voor traditionele omhoog schalen benaderingen zowel op het gebied 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.

Horizontale en verticale schalenHorizontal and vertical scaling

De volgende afbeelding ziet de horizontale en verticale afmetingen van de schaal, die 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 aan te passen capaciteit of de algehele prestaties.Horizontal scaling refers to adding or removing databases in order to adjust capacity or overall performance. Dit is een afkorting 'schalen' uit.This is also called “scaling out”. Sharding, waarin de gegevens in een verzameling van identieke gestructureerde databases zijn gepartitioneerd 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.

Verticale schaling verwijst naar het vergroten of verkleinen van het prestatieniveau van een individuele database — dit staat ook bekend als "omhoog schalen."Vertical scaling refers to increasing or decreasing the performance level of an individual database—this is also known as “scaling up.”

De meeste databasetoepassingen voor cloud-scale een combinatie van deze twee strategieën gebruiken.Most cloud-scale database applications use a combination of these two strategies. Bijvoorbeeld, kunt een servicetoepassing Software als een horizontaal schalen voor het inrichten van nieuwe end-klanten en verticaal schalen dat elke eindgebruiker database kan vergroten of verkleinen van resources naar behoefte 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 clientbibliotheek voor elastische Database.Horizontal scaling is managed using the Elastic Database client library.
  • Azure PowerShell-cmdlets te wijzigen van de servicelaag met verticale schalen moet worden uitgevoerd of door het plaatsen van 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 vooral populaire met cloud-ontwikkelaars maken van Software als een Service (SAAS)-aanbiedingen voor end-klanten 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 'tenants'.These end customers are often referred to as “tenants”. Sharding mogelijk zijn vereist voor een aantal redenen zijn:Sharding may be required for any number of reasons:

  • De totale hoeveelheid gegevens is te groot om te passen binnen de beperkingen van één databaseThe total amount of data is too large to fit within the constraints of a single database
  • De transactiedoorvoer van de algemene werklast overschrijdt de mogelijkheden van een individuele databaseThe transaction throughput of the overall workload exceeds the capabilities of a single database
  • Tenants mogelijk fysieke isolatie van elkaar, zodat de afzonderlijke databases nodig zijn voor elke tenantTenants may require physical isolation from each other, so separate databases are needed for each tenant
  • Mogelijk verschillende secties van een database moet zich bevinden in verschillende geografieën 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 voor het vervullen van een set databases 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 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 de datum (aanwezig is in alle rijen van de shard-tabel) en query's bij het ophalen van informatie voor een bepaald datumbereik van de toepassing naar de subset van de databases die betrekking hebben op het desbetreffende bereik moeten worden gerouteerd.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 een enkele 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 die lokaal op een specifieke database.That ensures that all transactions are local to a specific database.

Multitenant- 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. Dit is de patroon voor één tenant sharding die zorgt voor isolatie, de mogelijkheid back-up/herstel en resource schalen aan de granulatie van de tenant.This is the single tenant sharding pattern that provides isolation, backup/restore ability, and resource scaling at the granularity of the tenant. Met één tenant sharding, elke database is gekoppeld aan een specifieke tenant-id-waarde (of waarde van de klant), maar die 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 de clientbibliotheek kunt dit vereenvoudigen.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 is een typische multitenant sharding patroon - en deze mag worden aangedreven door het feit dat een toepassing een groot aantal kleine tenants beheert.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 een multitenant-sharding zijn de rijen in de databasetabellen alle ontworpen voor het transport van een sleutel die identificeert de tenant-ID of 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. Opnieuw de toepassingslaag is verantwoordelijk voor het doorsturen van aanvraag voor een tenant met de juiste database en dit kan worden ondersteund door de clientbibliotheek voor 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 kan worden gebruikt voor filteren welke rijen toegang elke tenant - voor meer informatie tot hebben Zie multitenant-toepassingen met elastische database-hulpprogramma's en beveiliging.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 zijn mogelijk vereist met het patroon multitenant sharding en dit proces wordt vergemakkelijkt door het hulpprogramma voor elastische database gesplitste samenvoegen.Redistributing data among databases may be needed with the multi-tenant sharding pattern, and this 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 groepen.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 vanaf meerdere verplaatsen naar één tenancymodus databasesMove data from multiple to single-tenancy databases

Wanneer u een SaaS-toepassing maakt, is het typische aanbieden potentiële klanten een evaluatieversie 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 voordelig in een multitenant-database gebruiken 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 één-tenant-database echter beter omdat deze betere prestaties biedt.However, when a prospect becomes a customer, a single-tenant database is better since it provides better performance. Als de klant had gemaakt van gegevens tijdens de proefperiode, gebruikt u de gesplitste merge tool voor het verplaatsen van de gegevens van meerdere tenants naar de nieuwe database voor éé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 u laat zien van de clientbibliotheek aan de slag met hulpprogramma's voor elastische Database.For a sample app that demonstrates the client library, see Get started with Elastic Database tools.

Zie het converteren van bestaande databases voor het gebruik van de hulpprogramma's migreren van bestaande databases uit te schalen.To convert existing databases to use the tools, see Migrate existing databases to scale out.

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

Geen gebruik van hulpprogramma's voor elastische database nog?Not using elastic database tools yet? Bekijk onze Getting Started Guide.Check out our Getting Started Guide. Voor vragen kunt contact met ons op de SQL Database-forum 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.