Explicați opțiunile de implementare
Bază de date Azure SQL, o platformă ca serviciu (PaaS), oferă o scalabilitate ridicată și întreținere minimă, făcându-l o soluție excelentă pentru anumite sarcini de lucru. Este potrivit pentru dezvoltarea de aplicații noi, oferind dezvoltatorilor flexibilitate semnificativă în construirea de servicii noi și oferind opțiuni granulare de implementare la scară. Această soluție de întreținere scăzută este ideală pentru diverse sarcini de lucru, asigurând dezvoltarea eficientă și eficientă a aplicațiilor.
Înțelegerea modelelor de implementare
Atunci când implementați baza de date Azure SQL, există două modele de implementare principale: o singură bază de date și rezervoare elastice. În modelul de rezervoare elastice, resursele sunt partajate între mai multe baze de date din același rezervor, în timp ce, în modelul unic de bază de date, resursele sunt gestionate independent pentru fiecare bază de date.
Similar cu mașinile virtuale, baza de date SQL poate fi implementată utilizând diverse metode, inclusiv PowerShell, Azure CLI sau portalul Azure.
Bază de date unică
Modelul de implementare bază de date unic este cea mai simplă modalitate de a utiliza baza de date AZURE SQL. În acest model, gestionați fiecare bază de date individual în ceea ce privește scalarea și dimensiunea datelor. Fiecare bază de date are propriile resurse dedicate, chiar dacă sunt implementate mai multe baze de date pe același server logic.
Puteți monitoriza utilizarea resurselor pentru fiecare bază de date prin portalul Azure. Această caracteristică vă permite să urmăriți și să evaluați cu ușurință performanța bazelor de date.
Piscine elastice
Rezervoarele elastice vă permit să alocați resurse de stocare și calcul la un grup de baze de date, simplificând gestionarea comparativ cu gestionarea fiecărei baze de date individual. Acestea sunt mai ușor de scalat decât bazele de date unice, deoarece modificările rezervorului elastic ajustează automat resursele pentru toate bazele de date incluse.
Acest model este eficient pentru software ca aplicații de serviciu, deoarece resursele sunt partajate între toate bazele de date. Puteți configura resurse utilizând modelul de achiziționare bazat pe DTU sau vCore.
Este important să monitorizați continuu resursele pentru a identifica vârfurile de performanță care ar putea afecta alte baze de date din rezervor. Revizitarea periodică a strategiei de alocare asigură suficiente resurse pentru toate bazele de date.
Piscinele elastice sunt ideale pentru arhitecturile cu entități găzduite cu utilizare medie scăzută, unde fiecare entitate găzduită are propria copie a bazei de date.
Înțelegerea modelelor de achiziționare
După ce ați ales modelul de implementare potrivit pentru baza de date SQL, următorul pas este să selectați modelul de cumpărare care se potrivește cel mai bine cerințelor de lucru și de buget. Baza de date Azure SQL oferă două modele de cumpărare: modelul vCore și modelul bazat pe DTU. Fiecare model are propriile avantaje, deci este esențial să înțelegeți care se potrivește cel mai bine cu cerințele de volum de lucru și cu considerațiile legate de costuri.
bazat pe vCore
Acesta este modelul recomandat de cumpărare, unde resursele de calcul și de stocare sunt decupate. Aceasta înseamnă că puteți să scalați spațiul de stocare și să calculați resursele în mod independent de altul. Această flexibilitate asigură faptul că puteți ajusta resursele în funcție de necesitățile dvs. specifice, fără a afecta alte componente.
În modelul de achiziție bazat pe vCore, costurile depind de mai mulți factori, inclusiv de nivelul de serviciu, de configurația hardware, de numărul vCore și de cantitatea de memorie, de spațiul de stocare rezervat al bazei de date și de spațiul de stocare real de backup.
Notă
Pentru detalii despre prețuri, consultați pagina Preț bază de date Azure SQL.
Un nivel de serviciu este o configurație predefinită care determină performanța, tipul de stocare, disponibilitatea ridicată, opțiunile de recuperare în caz de dezastru și disponibilitatea anumitor caracteristici pentru baza de date.
Modelul de achiziționare vCore oferă trei opțiuni de nivel de serviciu:
| Nivel de serviciu | Capacitatea |
|---|---|
| Scop general | Acest nivel de serviciu este proiectat pentru operațiuni mai puțin intensive și oferă un echilibru cost-eficient de calcul și de stocare. Acesta include atât niveluri de calcul asigurate, cât și fără server , oferind flexibilitate pentru a îndeplini diverse cerințe ale volumului de lucru, în timp ce optimizați bugetul. |
| Critic de afaceri | Acest nivel este ideal pentru aplicațiile care necesită latență scăzută și spațiu de stocare de înaltă performanță. Acesta acceptă In-Memory OLTP și include o reproducere doar în citire încorporată. În plus, oferă mai multă memorie pentru fiecare nucleu și utilizează spațiul de stocare SSD local, făcându-l ideal pentru sarcinile de lucru sensibile la performanță. |
| Hiperscale | Acest nivel este ajustat pentru aplicații cu baze de date mari și cerințe de transfer ridicate. Hyperscale introduce caracteristici complexe de scalare orizontală, permițând adăugarea nodurilor de calcul pe măsură ce crește dimensiunea datelor. Este acceptat exclusiv pe baze de date SQL unice și permite scalarea semnificativă a stocării și calculării resurselor dincolo de limitele nivelurilor de serviciu critic pentru scopuri generale și afaceri. |
Bazat pe DTU
În modelul DTU, există trei niveluri de servicii: Basic, Standard și Premium. Calculați și resursele de stocare depind de nivelul DTU, oferind o gamă de capacități de performanță cu limite de stocare fixe, reținere de backup și costuri.
De exemplu, dacă baza de date atinge limita maximă de stocare, va trebui să creșteți capacitatea DTU, chiar dacă utilizarea calculului este scăzută. De asemenea, operațiunile de scalare din baza de date Azure SQL pot provoca întreruperi scurte ale conexiunii la sfârșitul procesului. Acest lucru se poate întâmpla în două scenarii principale:
- Inițierea unei operațiuni de scalare care necesită o reluare internă în caz de nereușită.
- Adăugarea sau eliminarea bazelor de date din rezervorul elastic.
Notă
Pentru a gestiona erorile de conexiune, implementați o logică de reîncercare corespunzătoare în aplicația dvs.
Înțelegerea interacțiilor dintre implementarea și modelele de achiziționare este esențială pentru optimizarea performanței și a eficienței costurilor. Selectând cu atenție combinația corectă, vă puteți asigura că implementarea bazei de date SQL Azure îndeplinește cerințele aplicației în timp ce se încadrează în buget.
De exemplu, dacă optați pentru modelul de implementare unică a bazei de date, puteți prefera modelul de achiziționare vCore pentru flexibilitatea sa în scalarea resurselor de calcul și stocare independent. Pe de altă parte, dacă alegeți modelul de implementare a fondului comun elastic, modelul de achiziționare bazat pe DTU ar putea fi mai eficient din cauza costurilor, deoarece vă permite să partajați resurse între mai multe baze de date din cadrul rezervorului.
Efectuați backup și restaurați
Azure oferă capacități de backup și restaurare perfecte pentru baza de date SQL. Iată câteva caracteristici cheie:
Backup continuu
Baza de date AZURE SQL asigură copii backup regulate, copiindu-le încontinuu pentru a accesa stocarea geo-redundantă (RA-GRS). Copiile backup complete au loc copii backup săptămânale, diferențiale la fiecare 12-24 de ore și copii backup ale jurnalelor de tranzacții la fiecare 5-10 minute.
Geo-Restore
Cu backupurile geo-redundante în mod implicit, puteți restaura cu ușurință bazele de date în diferite regiuni, utile pentru scenarii mai puțin stricte de recuperare a dezastrelor. Spațiul de stocare de backup este facturat separat, dar este creat fără costuri suplimentare, cu dimensiunea maximă a nivelului de date selectat. Durata de restaurare geografică depinde de dimensiunea bazei de date, de jurnalele de tranzacții și de solicitările de restaurare simultană.
Notă
Geo-restaurarea este disponibilă atunci când proprietatea de redundanță de stocare backup este setată la spațiul de stocare de backup geo-redundant.
Restaurare punct în timp (PITR)
Vă permite să configurați o anumită politică de retenție în timp pentru fiecare bază de date, de la 1 la 35 de zile (valoarea implicită este șapte zile). De asemenea, puteți restaura bazele de date la un anumit moment din timp în același server utilizând portalul Azure, PowerShell, CLI sau API-ul REST.
retenție Long-Term (LTR)
Reținerea pe termen lung este utilă pentru scenariile care vă solicită să setați politica de retenție dincolo de ceea ce este oferit de Azure. Puteți seta o politică de retenție timp de până la 10 ani și această opțiune este dezactivată în mod implicit.
Pentru mai multe informații despre copiile backup automate, consultați Copii backup automate - Bază de date Azure SQL și Instanță gestionată AZURE SQL.
Activarea reglajului automat
Reglarea automată este o caracteristică puternică încorporată care aplică învățare programată pentru a optimiza performanța interogării. Acesta identifică automat oportunitățile de reglare și le implementează pentru a îmbunătăți eficiența bazei de date.
În prezent, reglarea automată include următoarele caracteristici:
- Identificarea interogărilor scumpe
- Forțarea ultimului plan bun de execuție
- Adăugarea indexurilor
- Se elimină indexurile
Serviciile Azure utilizează algoritmi avansați pentru a determina cele mai bune indexuri pentru modelele dvs. de interogare. Aceste indexuri sunt testate inițial pe o copie a bazei de date înainte de a fi aplicate la mediul live, asigurând întreruperi minime.
Toate bazele de date moștenesc configurația de la serverul părinte și puteți dezactiva cu ușurință această caracteristică, dacă este necesar. Această flexibilitate le permite dezvoltatorilor să mențină controlul, beneficiind în același timp de îmbunătățirile automate ale performanței.
Utilizarea unei interogări elastice
Interogarea elastică vă permite să rulați interogări T-SQL în mai multe baze de date din baza de date SQL. Această caracteristică este utilă pentru aplicațiile care utilizează nume de trei și patru părți care nu pot fi modificate și îmbunătățește portabilitatea prin facilitarea migrării.
Interogările elastice acceptă următoarele scenarii de partiționare:
| Nivel de serviciu | Capacitatea |
|---|---|
| Partiționare verticală | Numite și interogări inter-bază de date. Datele sunt partiționate vertical în mai multe baze de date cu scheme diferite. De exemplu, este posibil să aveți o bază de date pentru datele clienților și alta pentru informații despre plăți. Partiționarea verticală vă permite să rulați interogări inter-bază de date între aceste baze de date. |
| Partiționare orizontală | Cunoscut și sub numele de ciobire. Datele sunt partiționate pe orizontală pentru a distribui rânduri pe mai multe baze de date scalate, toate partajând aceeași schemă. Această topologie acceptă atât modelele cu entități găzduite unice, cât și cele cu mai multe entități găzduite. |
Această flexibilitate face ca interogările elastice să fie un instrument puternic pentru gestionarea și interogarea datelor în mai multe baze de date.
Configurarea lucrărilor elastice
Caracteristica de activitate elastică servește drept înlocuire sql Server Agent pentru baza de date SQL Azure, similară cu caracteristica Administrare server multiplă într-o instanță SQL Server locală.
Cu operațiuni elastice, puteți executa comenzi T-SQL în diverse implementări țintă, inclusiv baze de date SQL, rezervoare elastice pentru baze de date SQL și baze de date SQL în hărți fragmentate. Aceste resurse de baze de date pot cuprinde diferite abonamente și regiuni Azure. Capacitatea de executare paralelă este utilă pentru automatizarea activităților de întreținere a bazelor de date, asigurând eficiența și consistența în implementările dvs.
Mutarea datelor utilizând sincronizarea datelor SQL
Sincronizarea datelor SQL permite sincronizarea incrementală a datelor în mai multe baze de date, indiferent dacă rulează pe baza de date SQL sau pe SQL Server local. Această caracteristică este utilă pentru descărcarea sarcinilor de lucru intensive de producție într-o bază de date separată pentru analize sau operațiuni neplanificate.
Sincronizarea datelor operează pe o topologie hub, unde o bază de date din grupul de sincronizare este desemnată ca hub. Grupul de sincronizare poate include mai multe baze de date de membri, iar sincronizarea are loc între bazele de date ale hubului și ale membrilor individuali. Modificările sunt urmărite utilizând triggerele de inserare, actualizare și ștergere printr-un tabel istoric creat în baza de date a utilizatorului.
Atunci când creați un grup de sincronizare, trebuie să specificați o bază de date pentru a stoca metadatele grupului de sincronizare. Această bază de date de metadate poate fi nouă sau existentă, atât timp cât se află în aceeași regiune ca grupul de sincronizare.
Pentru mai multe informații despre cum să configurați sincronizarea datelor SQL, consultați Tutorial: Configurarea sincronizării datelor SQL între bazele de date în baza de date SQL Azure și SQL Server.