Forklare distribusjonsalternativer
Azure SQL Database, en plattform som tjeneste (PaaS), tilbyr høy skalerbarhet og minimalt med vedlikehold, noe som gjør den til en utmerket løsning for bestemte arbeidsbelastninger. Det er egnet for ny programutvikling, noe som gir utviklere betydelig fleksibilitet i å bygge nye tjenester og tilby detaljerte distribusjonsalternativer i stor skala. Denne løsningen med lite vedlikehold er ideell for ulike arbeidsbelastninger, noe som sikrer effektiv og effektiv programutvikling.
Forstå distribusjonsmodeller
Når du distribuerer Azure SQL Database, finnes det to primære distribusjonsmodeller: én database og elastiske utvalg. I modellen for elastiske bassenger deles ressurser mellom flere databaser i samme utvalg, mens i den ene databasemodellen administreres ressurser uavhengig av hver database.
I likhet med virtuelle maskiner kan SQL Database distribueres ved hjelp av ulike metoder, inkludert PowerShell, Azure CLI eller Azure-portalen.
Enkel database
Distribusjonsmodellen for én database er den enkleste måten å bruke Azure SQL Database på. I denne modellen administrerer du hver database individuelt når det gjelder skalering og datastørrelse. Hver database har egne dedikerte ressurser, selv om flere databaser distribueres på samme logiske server.
Du kan overvåke ressursutnyttelsen av hver database gjennom Azure-portalen. Med denne funksjonen kan du enkelt spore og vurdere ytelsen til databasene.
Elastiske bassenger
Elastiske bassenger lar deg tildele lagrings- og databehandlingsressurser til en gruppe databaser, noe som forenkler administrasjon sammenlignet med håndtering av hver database individuelt. De er enklere å skalere enn enkeltdatabaser, ettersom endringer i det elastiske utvalget automatisk justerer ressurser for alle inkluderte databaser.
Denne modellen er kostnadseffektiv for programvare som tjenesteprogrammer, ettersom ressurser deles mellom alle databaser. Du kan konfigurere ressurser ved hjelp av enten den DTU-baserte eller vCore-baserte kjøpsmodellen.
Det er viktig å kontinuerlig overvåke ressurser for å identifisere ytelsestopper som kan påvirke andre databaser i utvalget. Regelmessig gå tilbake til tildelingsstrategien sikrer tilstrekkelige ressurser for alle databaser.
Elastiske bassenger er ideelle for flertenante arkitekturer med lav gjennomsnittlig utnyttelse, der hver leier har sin egen databasekopi.
Forstå kjøpsmodeller
Når du har valgt riktig distribusjonsmodell for SQL-databasen, er neste trinn å velge kjøpsmodellen som passer best til arbeidsbelastningen og budsjettkravene. Azure SQL Database tilbyr to innkjøpsmodeller: vCore-modellen og den DTU-baserte modellen. Hver modell har sine egne fordeler, så det er viktig å forstå hvilken som passer best til arbeidsbelastningskravene og kostnadshensyn.
vCore-basert
Dette er den anbefalte kjøpsmodellen, der databehandlings- og lagringsressurser er koblet fra. Det betyr at du kan skalere lagrings- og databehandlingsressurser uavhengig av hverandre. Denne fleksibiliteten sikrer at du kan justere ressurser i henhold til dine spesifikke behov uten å påvirke andre komponenter.
I den vCore-baserte kjøpsmodellen avhenger kostnadene av flere faktorer, inkludert tjenestenivå, maskinvarekonfigurasjon, antall vCores og minnemengde, reservert databaselagring og faktisk sikkerhetskopilagring.
Merk deg
Hvis du vil ha prisdetaljer, kan du se prissiden for Azure SQL Database.
Et tjenestenivå er en forhåndsdefinert konfigurasjon som bestemmer ytelse, lagringstype, høy tilgjengelighet, nødgjenopprettingsalternativer og tilgjengeligheten til bestemte funksjoner for databasen.
VCore-kjøpsmodellen tilbyr tre alternativer for servicenivå:
| Tjenestenivå | Evne |
|---|---|
| Generelt formål | Dette tjenestenivået er utformet for mindre intensive operasjoner og tilbyr en kostnadseffektiv balanse mellom databehandling og lagringsalternativer. Det inkluderer både klargjorte og serverløse databehandlingsnivåer, noe som gir fleksibilitet til å møte varierende arbeidsbelastningskrav mens du optimaliserer budsjettet. |
| Forretningskritisk | Dette nivået er ideelt for programmer som krever lav ventetid og lagring med høy ytelse. Den støtter In-Memory OLTP og inneholder en innebygd skrivebeskyttet replika. I tillegg gir den mer minne per kjerne og bruker lokal SSD-lagring, noe som gjør den ideell for ytelsessensitive arbeidsbelastninger. |
| Hyperskala | Dette nivået er skreddersydd for programmer med store databaser og høye krav til gjennomstrømming. Hyperscale introduserer avanserte vannrette skaleringsfunksjoner, noe som gjør det mulig å legge til databehandlingsnoder etter hvert som datastørrelsen øker. Det støttes utelukkende på enkle SQL-databaser og muliggjør betydelig skalering av lagrings- og databehandlingsressurser utover grensene for tjenestenivåene Generelt formål og Forretningskritisk. |
DTU-basert
Det finnes tre tjenestenivåer i DTU-modellen: Basic, Standard og Premium. Databehandlings- og lagringsressurser avhenger av DTU-nivået, og tilbyr en rekke ytelsesfunksjoner med faste lagringsgrenser, reserveoppbevaring og kostnader.
Hvis databasen for eksempel når sin maksimale lagringsgrense, må du øke DTU-kapasiteten, selv om databehandlingsutnyttelsen er lav. Skalering av operasjoner på Azure SQL Database kan også føre til korte tilkoblingsavbrudd på slutten av prosessen. Dette kan skje i to hovedscenarioer:
- Starte en skaleringsoperasjon som krever en intern failover.
- Legge til eller fjerne databaser fra det elastiske utvalget.
Merk deg
Hvis du vil håndtere tilkoblingsfeil, implementerer du riktig logikk i programmet på nytt.
Å forstå samspillet mellom distribusjons- og innkjøpsmodeller er avgjørende for å optimalisere ytelse og kostnadseffektivitet. Ved å velge riktig kombinasjon nøye, kan du sikre at distribusjonen av Azure SQL Database oppfyller programmets krav mens du holder deg innenfor budsjettet.
Hvis du for eksempel velger distribusjonsmodellen for én database, foretrekker du kanskje vCore-kjøpsmodellen for fleksibiliteten i skalering av databehandlings- og lagringsressurser uavhengig av hverandre. Hvis du derimot velger den elastiske distribusjonsmodellen for bassenget, kan den DTU-baserte kjøpsmodellen være mer kostnadseffektiv, da den lar deg dele ressurser mellom flere databaser i utvalget.
Utfør sikkerhetskopiering og gjenoppretting
Azure tilbyr sømløse sikkerhetskopierings- og gjenopprettingsfunksjoner for SQL Database. Her er noen viktige funksjoner:
Kontinuerlig sikkerhetskopiering
Azure SQL Database sikrer regelmessige sikkerhetskopier, og kopierer dem kontinuerlig til geo-redundant lagringsplass med lesetilgang (RA-GRS). Fullstendige sikkerhetskopier forekommer ukentlige sikkerhetskopieringer hver 12. til 24. time, og sikkerhetskopiering av transaksjonslogger hvert 5. til 10. minutt.
Geo-Restore
Med geo-redundante sikkerhetskopier som standard kan du enkelt gjenopprette databaser til forskjellige områder, nyttig for mindre strenge scenarioer for nødgjenoppretting. Sikkerhetskopilagring faktureres separat, men opprettes uten ekstra kostnad med den maksimale størrelsen på det valgte datanivået. Varigheten for geogjenoppretting avhenger av databasestørrelse, transaksjonslogger og forespørsler om samtidig gjenoppretting.
Merk deg
Geogjenoppretting er tilgjengelig når egenskapen for reservelagring er satt til geo-redundant sikkerhetskopilagring.
Gjenoppretting til tidspunkt (PITR)
Lar deg konfigurere en bestemt oppbevaringspolicy for punkt i tid for hver database, fra 1 til 35 dager (standard er sju dager). Du kan også gjenopprette databaser til et bestemt tidspunkt i samme server ved hjelp av Azure Portal, PowerShell, CLI eller REST API.
Long-Term oppbevaring (LTR)
Langsiktig oppbevaring er nyttig for scenarioer som krever at du angir oppbevaringspolicyen utover det som tilbys av Azure. Du kan angi en oppbevaringspolicy i opptil 10 år, og dette alternativet er deaktivert som standard.
Hvis du vil ha mer informasjon om automatiserte sikkerhetskopier, kan du se Automatiserte sikkerhetskopier – Azure SQL Database & Azure SQL Managed Instance.
Aktiver automatisk justering
Automatisk justering er en kraftig innebygd funksjon som bruker maskinlæring til å optimalisere spørringsytelsen. Den identifiserer automatisk justeringsmuligheter og implementerer dem for å forbedre effektiviteten i databasen.
Automatisk justering inkluderer for øyeblikket følgende funksjoner:
- Identifisere dyre spørringer
- Tvinge den siste gode utførelsesplanen
- Legge til indekser
- Fjerner indekser
Azure-tjenester bruker avanserte algoritmer til å bestemme de beste indeksene for spørringsmønstrene. Disse indeksene testes først på en kopi av databasen før de brukes i det direktesendte miljøet, noe som sikrer minimal forstyrrelse.
Alle databaser arver konfigurasjonen fra den overordnede serveren, og du kan enkelt deaktivere denne funksjonen om nødvendig. Denne fleksibiliteten gjør det mulig for utviklere å opprettholde kontrollen samtidig som de drar nytte av automatiserte ytelsesforbedringer.
Bruk elastisk spørring
Med elastisk spørring kan du kjøre T-SQL-spørringer på tvers av flere databaser i SQL Database. Denne funksjonen er nyttig for programmer som bruker tre- og firedelte navn som ikke kan endres, og som forbedrer portabiliteten ved å legge til rette for overføring.
Elastiske spørringer støtter følgende partisjoneringsscenarioer:
| Tjenestenivå | Evne |
|---|---|
| Loddrett partisjonering | Også kjent som spørringer på tvers av databaser. Data partisjoneres loddrett på tvers av flere databaser med forskjellige skjemaer. Du kan for eksempel ha én database for kundedata og en annen for betalingsinformasjon. Med loddrett partisjonering kan du kjøre kryssdatabasespørringer mellom disse databasene. |
| Vannrett partisjonering | Også kjent som skåring. Data partisjoneres vannrett for å distribuere rader på tvers av flere utskalerte databaser, og alle deler samme skjema. Denne topologien støtter både modeller med én leier og fleretenanter. |
Denne fleksibiliteten gjør elastiske spørringer til et kraftig verktøy for administrasjon og spørring av data på tvers av flere databaser.
Konfigurer elastiske jobber
Funksjonen for elastisk jobb fungerer som SQL Server Agent-erstatning for Azure SQL Database, på samme måte som multiserveradministrasjonsfunksjonen i en lokal SQL Server-forekomst.
Med elastiske jobber kan du utføre T-SQL-kommandoer på tvers av ulike måldistribusjoner, inkludert SQL-databaser, elastiske sql-databaser og SQL-databaser i oppskårne kart. Disse databaseressursene kan dekke ulike Azure-abonnementer og -områder. Den parallelle utførelsesfunksjonen er nyttig for å automatisere vedlikeholdsoppgaver i databasen, noe som sikrer effektivitet og konsekvens på tvers av distribusjonene.
Flytte data ved hjelp av SQL Data Sync
SQL Data Sync aktiverer trinnvis synkronisering av data på tvers av flere databaser, enten de kjører på SQL Database eller lokal SQL Server. Denne funksjonen er nyttig for å avlaste intensive produksjonsarbeidsbelastninger til en egen database for analyser eller ikke-planlagte operasjoner.
Datasynkronisering fungerer på en hubtopologi, der én database i synkroniseringsgruppen er angitt som huben. Synkroniseringsgruppen kan inneholde flere medlemsdatabaser, og synkronisering forekommer mellom huben og individuelle medlemsdatabaser. Endringer spores ved hjelp av innsettings-, oppdaterings- og sletteutløsere gjennom en historisk tabell som er opprettet i brukerdatabasen.
Når du oppretter en synkroniseringsgruppe, må du angi en database for å lagre metadataene for synkroniseringsgruppen. Denne metadatadatabasen kan være enten ny eller eksisterende, så lenge den befinner seg i samme område som synkroniseringsgruppen.
Hvis du vil ha mer informasjon om hvordan du konfigurerer SQL Data Sync, kan du se Opplæring: Konfigurere SQL Data Sync mellom databaser i Azure SQL Database og SQL Server.