Delen via


Elastische pools helpen u bij het beheren en schalen van meerdere databases in Azure SQL Database

van toepassing op:Azure SQL Database-

Elastische pools van Azure SQL Database zijn een eenvoudige, rendabele oplossing voor het beheren en schalen van meerdere databases met verschillende en onvoorspelbare gebruiksvereisten. De databases in een elastische pool bevinden zich op één server en delen een vast aantal resources tegen een vaste prijs. Elastische pools in SQL Database stellen SaaS-ontwikkelaars (Software-as-a-Service) in staat om de prijsprestaties voor een groep databases binnen een voorgeschreven budget te optimaliseren en tegelijkertijd prestatie-elasticiteit voor elke database te leveren.

Wat zijn elastische SQL-pools?

SaaS-ontwikkelaars bouwen toepassingen boven op grootschalige gegevenslagen met meerdere databases. Een typisch toepassingspatroon is het inrichten van één database voor elke klant. Verschillende klanten hebben echter vaak verschillende en onvoorspelbare gebruikspatronen en het is moeilijk om de resourcevereisten van elke databasegebruiker te voorspellen. Traditioneel had u twee opties:

  • Te veel middelen toewijzen op basis van piekgebruik, wat leidt tot hogere kosten.
  • Onderbebouwing om kosten te besparen ten koste van prestaties en klanttevredenheid tijdens pieken.

Elastische pools lossen dit probleem op door ervoor te zorgen dat databases de prestatiebronnen krijgen die ze nodig hebben wanneer ze ze nodig hebben. Ze bieden een eenvoudig mechanisme voor resourcetoewijzing binnen een voorspelbaar budget. Zie multitenant SaaS-databasetenancypatronenvoor meer informatie over ontwerppatronen voor SaaS-toepassingen met elastische pools.

Belangrijk

Er worden geen kosten per database in rekening gebracht voor elastische pools. U wordt gefactureerd voor elk uur dat er een pool bestaat op de hoogste eDTU of vCores, ongeacht het gebruik of dat de pool minder dan een uur actief was.

Met elastische pools kunt u resources aanschaffen voor een pool die wordt gedeeld door meerdere databases om onvoorspelbare gebruiksperioden door afzonderlijke databases mogelijk te maken. U kunt resources voor de pool configureren op basis van het aankoopmodel op basis van DTU of het aankoopmodel op basis van vCore. Het geaggregeerde gebruik van de databases bepaalt de resourcevereiste voor een pool.

De hoeveelheid resources die beschikbaar zijn voor de pool, wordt bepaald door uw budget. U hoeft alleen maar te doen:

  • Voeg databases toe aan de pool.
  • U kunt desgewenst de minimale en maximale resources voor de databases instellen in het DTU- of vCore-aankoopmodel.
  • Stel de resources van de pool in op basis van uw budget.

U kunt pools gebruiken om uw service naadloos te laten groeien van een lean startup tot een volwassen bedrijf op een steeds grotere schaal.

Binnen de pool krijgen afzonderlijke databases de flexibiliteit om resources binnen ingestelde parameters te gebruiken. Bij zware belasting kan een database meer resources verbruiken om aan de vraag te voldoen. Databases onder lichte belastingen verbruiken minder en databases zonder belasting verbruiken geen resources. Het inrichten van resources voor de hele pool in plaats van voor individuele databases vereenvoudigt uw beheertaken. Bovendien hebt u een voorspelbaar budget voor de pool.

Er kunnen meer resources worden toegevoegd aan een bestaande pool met minimale downtime. Als er geen extra resources meer nodig zijn, kunnen ze op elk gewenst moment uit een bestaande pool worden verwijderd. U kunt ook databases toevoegen aan of verwijderen uit de pool. Als een database voorspelbaar de resources onderbenut, kunt u deze verplaatsen.

Notitie

Wanneer u databases naar of uit een elastische pool verplaatst, is er geen downtime, met uitzondering van een korte periode (in de volgorde van seconden) wanneer databaseverbindingen aan het einde van de bewerking worden verwijderd.

Wanneer moet u een elastische SQL Database-pool overwegen?

Pools zijn geschikt voor een groot aantal databases met specifieke gebruikspatronen. Dit patroon wordt gekenmerkt door een laag gemiddeld gebruik met onregelmatige gebruikspieken voor een bepaalde database. Omgekeerd mogen meerdere databases met permanent gemiddeld hoog gebruik niet in dezelfde elastische pool worden geplaatst.

Hoe meer databases u aan een pool kunt toevoegen, hoe groter uw besparingen. Afhankelijk van uw toepassingsgebruikspatroon is het mogelijk om besparingen te zien met slechts twee S3-databases.

De volgende secties helpen u te begrijpen hoe u kunt beoordelen of uw specifieke verzameling databases kan profiteren van een groep. In de voorbeelden worden Standard-pools gebruikt, maar dezelfde principes zijn van toepassing op elastische pools in andere servicelagen.

Patronen voor databasegebruik beoordelen

In de volgende afbeelding ziet u een voorbeeld van een database die veel van de niet-actieve tijd doorbrengt, maar periodiek piekt met activiteit. Dit gebruikspatroon is geschikt voor een pool.

diagram met één database die geschikt is voor een pool.

De grafiek illustreert het DTU-gebruik van meer dan één uur van 12:00 tot 1:00, waarbij elk gegevenspunt granulariteit van één minuut heeft. Om 12:10 piekt DB1 tot 90 DTU's, maar het totale gemiddelde gebruik is minder dan vijf DTU's. Er is een S3-rekenkracht vereist voor het uitvoeren van deze workload in één database, maar deze grootte laat de meeste resources ongebruikt tijdens perioden met een lage activiteit.

Met een pool kunnen deze ongebruikte DTU's worden gedeeld tussen meerdere databases. Een pool vermindert de benodigde DTU's en de totale kosten.

Stel dat andere databases vergelijkbare gebruikspatronen hebben als DB1 op basis van het vorige voorbeeld. In de volgende twee cijfers wordt het gebruik van 4 databases en 20 databases gelaagd in dezelfde grafiek om de niet-overlapping van hun gebruik in de loop van de tijd te illustreren met behulp van het aankoopmodel op basis van DTU:

diagram met vier databases met een gebruikspatroon dat geschikt is voor een pool.

diagram met 20 databases met een gebruikspatroon dat geschikt is voor een pool.

De zwarte lijn in de voorgaande grafiek illustreert het cumulatieve DTU-gebruik voor alle 20 databases. Deze regel laat zien dat het cumulatieve DTU-gebruik nooit meer dan 100 DTU's overschrijdt en aangeeft dat de 20 databases gedurende deze periode 100 eDTU's kunnen delen. Het resultaat is een twintigvoudige vermindering van DTU's en een dertienvoudige prijsvermindering in vergelijking met het gebruik van S3-rekengrootten voor elke individuele database.

Dit voorbeeld is ideaal omdat:

  • Er zijn grote verschillen tussen piekgebruik en gemiddeld gebruik per database.
  • Het piekgebruik voor elke database vindt op verschillende tijdstippen plaats.
  • eDTU's worden gedeeld tussen veel databases.

In het DTU-aankoopmodel is de prijs van een pool een functie van de eDTU's van de pool. Hoewel de eDTU-eenheidsprijs voor een groep 1,5 keer groter is dan de DTU-eenheidsprijs voor één database, kunnen groep-eDTU's worden gedeeld door veel databases en zijn er minder totale eDTU's nodig. Deze verschillen in prijzen en het delen van eDTU's vormen de basis van het besparingspotentieel dat pools kunnen bieden.

In het aankoopmodel van vCore is de prijs van vCore-eenheden voor elastische pools hetzelfde als de prijs voor vCore-eenheden voor individuele databases.

Hoe kies ik de juiste poolgrootte?

De beste grootte voor een pool is afhankelijk van de geaggregeerde resources die nodig zijn voor alle databases in de pool. U moet het volgende bepalen:

  • Maximale rekenresources die worden gebruikt door alle databases in de pool. Rekenresources worden geïndexeerd door eDTU's of vCores, afhankelijk van uw keuze voor het aankoopmodel.
  • Maximum aantal opslagbytes dat wordt gebruikt door alle databases in de pool.

Zie voor servicelagen en resourcelimieten in elk aankoopmodel het aankoopmodel op basis van DTU of het aankoopmodel op basis van vCore.

Met de volgende stappen kunt u inschatten of een pool rendabeler is dan individuele databases:

  1. Schat de eDTU's of vCores die nodig zijn voor de pool:

    1. Voor het DTU-gebaseerde aankoopmodel:
      1. MAX(<Totaal aantal DB's × Gemiddelde DTU-gebruik per DB>, <Aantal gelijktijdig piekende DB's × Piek-DTU-gebruik per DB>)
    2. Voor het aankoopmodel op basis van vCore:
      1. MAX(<Totaal aantal DB's × Gemiddeld vCore-gebruik per DB>, <Aantal gelijktijdig piekende DB's × Piek vCore-gebruik per DB>)
  2. Maak een schatting van de totale opslagruimte die nodig is voor de pool door de gegevensgrootte toe te voegen die nodig is voor alle databases in de pool. Bepaal voor het DTU-aankoopmodel de grootte van de eDTU-pool die deze hoeveelheid opslagruimte biedt.

  3. Neem voor het aankoopmodel op basis van DTU de grotere eDTU-schattingen uit stap 1 en stap 2.

    1. Voor het aankoopmodel op basis van vCore voert u de vCore-schatting uit stap 1 uit.
  4. Zie de pagina met prijzen voor SQL Database.

    1. Zoek de kleinste poolgrootte die groter is dan de schatting uit stap 3.
  5. Vergelijk de poolprijs van stap 4 met behulp van de juiste rekengrootten voor individuele databases.

Belangrijk

Als het aantal databases in een pool het maximaal ondersteunde aantal databases nadert, moet u overwegen resourcebeheer in dichte elastische pools.

Eigenschappen per database

U kunt desgewenst eigenschappen per database instellen om patronen voor resourceverbruik in elastische pools te wijzigen. Zie de documentatie voor resourcelimieten voor DTU- en vCore elastische pools voor meer informatie.

Andere SQL Database-functies gebruiken met elastische pools

U kunt andere SQL Database-functies gebruiken met elastische pools.

Elastische taken en elastische groepen

Met een pool worden beheertaken vereenvoudigd door scripts uit te voeren in elastische taken. Een elastische job elimineert het grootste deel van de eentonigheid die gepaard gaat met grote hoeveelheden databases.

Zie Uitschalen met Azure SQL Databasevoor meer informatie over andere databasehulpprogramma's voor het werken met meerdere databases.

Elastische Hyperscale-pools

Hyperscale elastische pools overzicht in Azure SQL Database is algemeen beschikbaar.

Alleen-lezen uitschaalexemplaren

U kunt read-only scale out-instanties van Azure SQL Database niet gebruiken met de elastic query-functionaliteit.

Opties voor bedrijfscontinuïteit voor databases in een elastische pool

Pooldatabases ondersteunen over het algemeen dezelfde functies voor bedrijfscontinuïteit die beschikbaar zijn voor individuele databases:

  • herstel naar een bepaald tijdstip: herstel naar een bepaald tijdstip maakt gebruik van automatische databaseback-ups om een database in een pool te herstellen naar een bepaald tijdstip. Zie herstel naar een bepaald tijdstip.
  • Geo-herstel: Geo-herstel biedt de standaardhersteloptie wanneer een database niet beschikbaar is vanwege een incident in de regio waar de database wordt gehost. Zie Geo-herstel.
  • actieve geo-replicatie: voor toepassingen met agressievere herstelvereisten dan geo-herstel kan bieden, configureert u actieve geo-replicatie of een failovergroep.

Zie richtlijnen voor herstel na noodgevallenvoor meer informatie over de bovenstaande strategieën.

Een nieuwe elastische SQL Database-pool maken met behulp van Azure Portal

U kunt op twee manieren een elastische pool maken in Azure Portal:

  • Maak een elastische pool en selecteer een bestaande of nieuwe server.
  • Maak een elastische pool van een bestaande server.

Een elastische pool maken en een bestaande of nieuwe server selecteren:

  1. Ga naar de Azure-portal om een elastische pool te maken. Zoek en selecteer Azure SQL.

  2. Selecteer maken om het deelvenster Sql-implementatieoptie selecteren te openen. Om meer informatie over elastische pools te bekijken, selecteert u op de tegel Databases de optie Details weergeven.

  3. Op de tegel Databases, selecteer in de vervolgkeuzelijst resourcetype, de optie elastische pool. Selecteer vervolgens Maken.

    schermopname van het maken van een elastische pool.

  4. Vervolgens kunt u uw elastische pool beheren via de Azure portal, PowerShell, Azure CLI, REST API of T-SQL.

Een elastische pool maken op een bestaande server:

  1. Ga naar een bestaande server en selecteer Nieuwe pool om rechtstreeks op die server een pool te maken.

    Notitie

    U kunt meerdere pools op een server maken, maar u kunt geen databases van verschillende servers toevoegen aan dezelfde pool.

    De servicelaag van de pool bepaalt de functies die beschikbaar zijn voor de elasticen in de pool en de maximale hoeveelheid resources die beschikbaar zijn voor elke database. Zie resourcelimieten voor elastische pools in het DTU-modelvoor meer informatie. Zie resourcelimieten op basis van vCore voor elastische pools.

  2. Als u de resources en prijzen van de pool wilt configureren, selecteert u Groep configureren. Selecteer vervolgens een servicelaag, voeg databases toe aan de pool en configureer de resourcelimieten voor de pool en de bijbehorende databases.

  3. Nadat u de pool hebt geconfigureerd, selecteert u Toepassen, noemt u de groep en selecteert u OK om de pool te maken.

  4. Vervolgens uw elastische pool beheren via het Azure Portal, PowerShell, Azure CLI, REST API of T-SQL.

Een elastische pool en de bijbehorende databases bewaken

In Azure Portal kunt u het gebruik van een elastische pool en de databases in die pool bewaken. U kunt ook een set wijzigingen aanbrengen in uw elastische pool en alle wijzigingen tegelijk verzenden. Deze wijzigingen omvatten het toevoegen of verwijderen van databases, het wijzigen van de instellingen van uw elastische pool of het wijzigen van uw database-instellingen.

U kunt de ingebouwde tools voor prestatiebewaking en waarschuwingstools gebruiken in combinatie met prestatiebeoordelingen. SQL Database kan ook metrische gegevens en resourcelogboeken verzenden voor eenvoudigere bewaking.

Klantcasestudies

  • SnelStart-: SnelStart heeft elastische pools met SQL Database gebruikt om de zakelijke services snel uit te breiden met een snelheid van 1000 nieuwe SQL-databases per maand.
  • Umbraco: Umbraco maakt gebruik van elastische pools met SQL Database om snel services in te richten en te schalen voor duizenden tenants in de cloud.