Válasszon a virtuálismag- és a DTU-vásárlási modellek közül – Azure SQL Database és SQL Managed Instance

a következőkre vonatkozik: Azure SQL Database Azure SQL felügyelt példánya

Azure SQL Database és Azure SQL Managed Instance segítségével egyszerűen vásárolhat a teljesítmény- és költség igényeinek megfelelő, teljes körűen felügyelt paaS-adatbázismotort. Attól függően, hogy milyen üzembe helyezési modellt választott Azure SQL Database, kiválaszthatja az Önnek megfelelő vásárlási modellt:

  • Virtuálismag-alapú vásárlási modell (ajánlott). Ez a vásárlási modell választási lehetőséget biztosít a kiépített számítási szint és a kiszolgáló nélküli számítási szint között. A kiépített számítási szinten kiválaszthatja a számítási feladathoz mindig kiépített számítási erőforrások pontos mennyiségét. A kiszolgáló nélküli számítási szinten adhatja meg a számítási erőforrások automatikus skálázását egy konfigurálható számítási tartományon keresztül. Ezzel a számítási szinttel a számítási feladatok tevékenységének függvényében automatikusan szüneteltetheti és folytathatja az adatbázist. Az időegységenkénti virtuálismag-egységár alacsonyabb a kiépített számítási szinten, mint a kiszolgáló nélküli számítási szinten.
  • Adatbázis-tranzakciós egységen (DTU) alapuló vásárlási modell. Ez a vásárlási modell csomagolt számítási és tárolási csomagokat biztosít a gyakori számítási feladatokhoz.

Két vásárlási modell érhető el:

Az alábbi táblázat és diagram összehasonlítja és összehasonlítja a virtuálismag-alapú és a DTU-alapú vásárlási modelleket:

Vásárlási modell Leírás A következőkre alkalmas
DTU-alapú Ez a modell a számítási, tárolási és I/O-erőforrások kötegelt mérőszámán alapul. A számítási méretek az önálló adatbázisok esetében adatbázis-tranzakciós egységben (DTU), a rugalmas készletek esetében pedig rugalmas adatbázis-tranzakciós egységben (eDTU) vannak megadva. További információ a DTU-kkal és eDTU-kkal kapcsolatban: Mik azok a DTU-k és eDTU-k? Egyszerű, előre konfigurált erőforrás-beállításokat kívánó ügyfelek
Virtuálismag-alapú Ez a modell lehetővé teszi a számítási és tárolási erőforrások egymástól független választását. A virtuálismag-alapú vásárlási modell lehetővé teszi az Azure Hybrid Benefit SQL Serverrel való használatát a költségek megtakarítása érdekében. A rugalmasságot, a vezérlést és az átláthatóságot értéket képviselő ügyfelek

Díjszabási modell összehasonlítása

Optimalizálni és menteni szeretné a felhővel töltött kiadásait?

Az Azure-szolgáltatások pénzbe kerülnek. Az Azure Cost Management segít a költségvetések beállításában és a riasztások konfigurálásában, hogy kézben tarthassa a költségeket. Cost Managementával elemezheti, kezelheti és optimalizálhatja Azure-költségeit. További információt a költségek elemzésének gyorsútmutatójában talál.

Számítási költségek

Kiépített számítási költségek

A kiépített számítási szinten a számítási költség az alkalmazáshoz kiépített teljes számítási kapacitást tükrözi.

A üzletileg kritikus szolgáltatásszinten legalább három replikát automatikusan lefoglalunk. A számítási erőforrások ezen további kiosztásának tükrözze, hogy a virtuálismag-alapú vásárlási modell ára körülbelül 2,7-szer magasabb a üzletileg kritikus szolgáltatási szinten, mint az általános célú szolgáltatási szinten. Hasonlóképpen, az ssd-tároló magasabb GB üzletileg kritikus ára a magasabb I/O-korlátokat és kisebb késést tükrözi.

A biztonsági másolatok tárolási költsége megegyezik az üzletileg kritikus szolgáltatási szint és a általános célú szolgáltatási szint költségeivel, mivel mindkét szint standard szintű tárolást használ a biztonsági másolatok készítéséhez.

Kiszolgáló nélküli számítási költségek

A számítási kapacitás definiálásának és a kiszolgáló nélküli számítási szint költségeinek kiszámításáról a kiszolgáló nélküli SQL Database leírásában található.

Tárolási költségek

A különböző típusú tárolók számlázása eltérő. Az adattárolásért a kiépített tárterületért a kiválasztott maximális adatbázis- vagy készletméret alapján kell fizetnie. A költségek csak akkor változnak, ha csökkenti vagy növeli a maximális értéket. A biztonsági mentési tár a példány automatikus biztonsági mentéséhez van társítva, és dinamikusan van lefoglalva. A biztonsági másolatok megőrzési időtartamának növelése növeli a példány által felhasznált biztonsági mentési tárterületet.

Alapértelmezés szerint az adatbázisok hét napos automatikus biztonsági mentései egy írási hozzáférésű georedundáns tárfiókba (RA-GRS) vannak átmásolva. Ezt a tárhelyet hetente teljes biztonsági mentések, napi különbözeti biztonsági mentések és tranzakciónapló-biztonsági mentések használják, amelyeket a rendszer öt percenként másol. A tranzakciónaplók mérete az adatbázis változási sebességétől függ. Az adatbázis méretének 100%-ával egyenlő minimális tárterületet díjmentesen biztosítjuk. A biztonsági mentési tárterület további használatának díja GB/hó.

A tárolási árakkal kapcsolatos további információkért tekintse meg a díjszabási oldalt.

Virtuálismag-alapú vásárlási modell

A virtuális mag (vCore) egy logikai CPU-t képvisel, és lehetőséget kínál a hardvergenerációk és a hardver fizikai jellemzői (például a magok száma, a memória és a tárterület mérete) közötti választásra. A virtuálismag-alapú vásárlási modell rugalmasságot, szabályozást, az egyéni erőforrás-használat átláthatóságát, valamint a helyszíni számítási feladatok követelményeinek a felhőbe való egyszerű fordítását teszi lehetővé. Ez a modell lehetővé teszi, hogy számítási, memória- és tárolási erőforrásokat válasszon a számítási feladatok igényei alapján.

A virtuálismag-alapú vásárlási modellben a virtuálismag-alapú általános célú és üzletileg kritikus szolgáltatási SQL Database és SQL Managed Instance. Az egyes adatbázisokhoz a Hyperscale szolgáltatási szintet is választhatja.

A virtuálismag-alapú vásárlási modell lehetővé teszi a számítási és tárolási erőforrások egymástól független választását, a helyszíni teljesítménynek való megfelelőt és az ár optimalizálását. A virtuálismag-alapú vásárlási modellben a következő szolgáltatásokért fizet:

  • Számítási erőforrások (a szolgáltatásszint + a virtuális magok száma és a memória mennyisége + hardvergeneráció).
  • Az adatok típusa és mennyisége, valamint naplótárolás.
  • Backup Storage (RA-GRS).

Fontos

A számítási erőforrásokért, az I/O-ért, valamint az adatokért és a naplótárolásért adatbázisonként vagy rugalmas készletenként kell fizetni. A biztonsági mentési tárterületért minden adatbázisért díjat kell fizetnie. A díjakkal kapcsolatos további SQL Managed Instance lásd: SQL Managed Instance. Régiókorlátozások: A támogatott régiók aktuális listáját lásd: régiónként elérhető termékek. Ha olyan régióban kell létrehoznia egy felügyelt példányt, amely jelenleg nem támogatott, küldjön támogatási kérést a Azure Portal.

Ha az adatbázis több mint 300 DTUs-t használ fel, a virtuálismag-alapú vásárlási modellre való konvertálás csökkentheti a költségeket. A konvertáláshoz használhatja a választott API-t, vagy használhatja a Azure Portal állásidő nélkül. Az átalakítás azonban nem kötelező, és nem automatikusan történik. Ha a DTU-alapú vásárlási modell megfelel a teljesítménnyel és az üzleti követelményekkel kapcsolatos követelményeknek, érdemes folytatni a használatot.

A DTU-alapú vásárlási modellről a virtuálismag-alapú vásárlási modellre való átváltásról lásd: Áttelepítés DTU-ból virtuális magba.

DTU-alapú vásárlási modell

Az adatbázis-tranzakciós egység (DTU) a processzor, a memória, az olvasások és az írások kevert mértéke. A DTU-alapú vásárlási modell a számítási erőforrások előre konfigurált csomagkészletét kínálja, valamint tárhelyet biztosít az alkalmazásteljesítmény különböző szintjeinek teljesítményének növelése érdekében. Ha előnyben részesíti az előre konfigurált csomagok és rögzített kifizetések egyszerűségét minden hónapban, a DTU-alapú modell jobban megfelelhet az igényeinek.

A DTU-alapú vásárlási modellben az alapszintű, a standard és a prémium szolgáltatási szint közül választhat a Azure SQL Database. A DTU-alapú vásárlási modell nem érhető el a Azure SQL Managed Instance.

Adatbázis-tranzakciós egységek (DTA-k)

A szolgáltatási szinten belüli adott számítási méretű önálló adatbázisok esetében az Azure egy bizonyos szintű erőforrásokat garantál az adott adatbázishoz (az Azure-felhőben található többi adatbázistól függetlenül). Ez a garancia kiszámítható teljesítményszintet biztosít. Az adatbázishoz lefoglalt erőforrások mennyiségét a rendszer DTA-számként számítja ki, és a számítási, tárolási és I/O-erőforrások kötegelt mértéke.

Az erőforrások arányát eredetileg egy online tranzakciófeldolgozási (OLTP) teljesítményteszt számítási feladat határozza meg, amelyet a valós OLTP számítási feladatokra jellemzően terveztek. Ha a számítási feladat túllépi ezen erőforrások mennyiségét, az átviteli sebesség csökken, ami lassabb teljesítményt és időkorrekozást eredményez.

A számítási feladat által használt erőforrások nincsenek hatással az Azure-felhő más adatbázisai számára elérhető erőforrásokra. Hasonlóképpen, a más számítási feladatok által használt erőforrások nincsenek hatással az adatbázis számára elérhető erőforrásokra.

Határolókeret

A DTUs-okat leginkább a különböző számítási méretekben és szolgáltatási szinteken álló adatbázisokhoz lefoglalt relatív erőforrások megértéséhez lehet hasznossá. Például:

  • A DTU-nak az adatbázis számítási méretének növelésével való duplázása azzal egyenlő, hogy megduplázza az adatbázis számára elérhető erőforráskészletet.
  • A prémium szintű, 1750 DTU-val rendelkezik P11 szintű adatbázis 350-szer több DTU számítási teljesítményt biztosít, mint egy 5 DTU-val egy alapszintű szolgáltatási szintű adatbázis.

A számítási feladatok erőforrás- (DTU-) fogyasztásának mélyebb elemzéséhez használja a lekérdezési teljesítményelemzéseket a következő feladatokhoz:

  • Azonosítsa a legfontosabb lekérdezéseket a processzor/időtartam/végrehajtás száma alapján, amelyek finomhangolhatóak a jobb teljesítmény érdekében. Az I/O-igényes lekérdezések esetében például előnyös lehet a memóriabeli optimalizálási technikák használata, hogy jobban kihasználják a rendelkezésre álló memóriát egy adott szolgáltatási szinten és számítási méretben.
  • A lekérdezés részleteinek részletes megtekintésével megtekintheti annak szövegét és az erőforrás-használat előzményeit.
  • Hozzáférés a teljesítmény-finomhangolási javaslatokhoz, amelyek az SQL Database Advisor.

Rugalmas adatbázis-tranzakciós egységek (eDTUs)

A mindig elérhető adatbázisok esetén ahelyett, hogy dedikált erőforráskészletet (DTUS-t) biztosítanának, amelyekre esetleg nem mindig lenne szükség, ezeket az adatbázisokat egy rugalmas készletbe is helyezze. A rugalmas készletben található adatbázisok egyetlen kiszolgálón vannak, és osztoznak az erőforrások készleten.

A rugalmas készletben található megosztott erőforrások mérése rugalmas adatbázis-tranzakciós egységekkel (eDTUS-okkal) történik. A rugalmas készletek egyszerű, költséghatékony megoldást kínálnak több olyan adatbázis teljesítménybeli céljainak kezelésére, amelyek felhasználási mintái nagy mértékben és kiszámíthatatlanul változnak. A rugalmas készlet garantálja, hogy a készlet egy adatbázisa nem használhatja fel az összes erőforrást, ugyanakkor gondoskodik arról, hogy a készletben található adatbázisok mindig a lehető legkevesebb szükséges erőforrással érhetők el.

A készlet adott számú eDTUs-t kap egy adott áron. A rugalmas készletben az egyes adatbázisok automatikusan skálázást tudnak beállítani a konfigurált határokon belül. A nagyobb terhelés alatt álló adatbázisok több eDTE-t használnak fel az igényeknek való megfelelő igények szerint. A kisebb terhelés alatt elhasznált adatbázisok kevesebb eDTE-t használnak fel. A terhelést nem kezelő adatbázisok nem használnak eDTUs-t. Mivel az erőforrások nem adatbázisonként, hanem a teljes készlethez vannak kiépítve, a rugalmas készletek leegyszerűsítik a felügyeleti feladatokat, és kiszámítható költségvetést biztosítanak a készlet számára.

Hozzáadhat további eDTE-ket egy meglévő készlethez adatbázis-állásidő nélkül, és nincs hatással a készletben lévő adatbázisokra. Hasonlóképpen, ha már nincs szüksége további eDTE-kre, bármikor eltávolíthatja őket egy meglévő készletből. Adatbázisokat bármikor hozzáadhat a készlethez, vagy kivonhat onnan adatbázisokat. Az eDTUs más adatbázisok számára való lefoglalásához korlátozza az adatbázis által nagy terhelés alatt használható eDTUS-okat. Ha egy adatbázis folyamatosan alulhasználja az erőforrásokat, helyezze át a készletből, és konfigurálja egyetlen adatbázisként, kiszámítható mennyiségű szükséges erőforrással.

A számítási feladatokhoz szükséges DTUS-kapacitások számának meghatározása

Ha egy meglévő helyszíni vagy virtuálisgép-számítási feladatot szeretne SQL Server SQL Database-be, SQL Database DTU-kalkulátor segítségével közelítőleg meg tudja közelítőleg a szükséges DTU-okat. Meglévő számítási feladatok SQL Database lekérdezési teljesítmény elemzésekkel megértheti az adatbázis-erőforrás-használatot (DTUs), és mélyebb elemzéseket kaphat a számítási feladatok optimalizálásához. A sys.dm_db_resource_stats felügyeleti nézet (DMV) lehetővé teszi az elmúlt egy óra erőforrás-használatának megtekintését. A sys.resource_stats katalógusnézet az elmúlt 14 nap erőforrás-fogyasztását jeleníti meg, de alacsonyabb ötperces átlagértékekkel.

A DTU-kihasználtság meghatározása

A DTU/eDTU-kihasználtság egy adatbázis vagy rugalmas készlet DTU/eDTU-korláthoz viszonyított átlagos százalékos arányának meghatározásához használja a következő képletet:

avg_dtu_percent = MAX(avg_cpu_percent, avg_data_io_percent, avg_log_write_percent)

A képlet bemeneti értékei a következő DMV sys.dm_db_resource_stats sys.resource_stats éssys.elastic_pool_resource_stats szerezhetők be. Más szóval a DTU/eDTU kihasználtság egy adatbázis vagy rugalmas készlet DTU/eDTU-korlátja felé való százalékos arányának meghatározásához válassza ki a legnagyobb százalékos értéket a következők közül: , , és egy adott avg_cpu_percent avg_data_io_percent avg_log_write_percent időpontban.

Megjegyzés

Az adatbázis DTU-korlátját a processzor, az olvasás, az írás és az adatbázis számára elérhető memória határozza meg. Mivel azonban a SQL Database-motor általában az összes rendelkezésre álló memóriát felhasználja az adatgyorsítótárhoz a teljesítmény javítása érdekében, az érték általában közel 100 százalék lesz, függetlenül az aktuális avg_memory_usage_percent adatbázis-terheléstől. Ezért annak ellenére, hogy a memória közvetve befolyásolja a DTU-korlátot, nem használatos a DTU-kihasználtsági képletben.

Rugalmas erőforráskészletet kihasználó számítási feladatok

A készletek jól megfelelnek az alacsony erőforrás-kihasználtságú átlagos erőforrás-kihasználtságú és viszonylag ritkán kiugró kihasználtságú adatbázisokhoz. További információ: Mikor érdemes megfontolni egy rugalmas SQL Database készletet?.

Hardvergenerációk a DTU-alapú vásárlási modellben

A DTU-alapú vásárlási modellben az ügyfelek nem választhatják ki az adatbázisaikhoz használt hardvergenerációt. Bár egy adott adatbázis általában hosszú ideig (általában több hónapig) egy adott hardvergeneráción marad, vannak olyan események, amelyek miatt az adatbázist áthelyezik egy másik hardvergenerációba.

Egy adatbázis például áthelyezható egy másik hardvergenerációba, ha egy másik szolgáltatási célkitűzésre skálázták fel vagy le, vagy ha az adatközpont aktuális infrastruktúrája megközelíti a kapacitáskorlátokat, vagy ha a jelenleg használt hardvert az életciklusa miatt leszerelik.

Ha egy adatbázist másik hardverre költöztetnek, a számítási feladatok teljesítménye változhat. A DTU-modell garantálja, hogy a DTU-teljesítményteszt számítási feladatának átviteli sebesség és válaszidő lényegesen azonos marad, ahogy az adatbázis egy másik hardvergenerációba kerül, amíg a szolgáltatási célkitűzése (a DTU-k száma) változatlan marad.

Az ügyfelek számítási feladatainak széles skáláját lefedő Azure SQL Database azonban a különböző hardverek ugyanazon szolgáltatási célhoz való használatának hatása jobban kiejtheti. A különböző számítási feladatok különböző hardverkonfigurációt és funkciókat fognak kihozni. Ezért a DTU-teljesítményteszten kívül más számítási feladatok esetében is láthatóak a teljesítménybeli különbségek, ha az adatbázis egyik hardvergenerációról a másikra kerül át.

Például a hálózati késésre érzékeny alkalmazások jobb teljesítményt láthatnak a Gen5-hardverek és a Gen4 esetében a Gyorsított hálózathasználat a Gen5-ben, de az intenzív olvasási I/O-t használó alkalmazások jobb teljesítményt láthatnak a Gen4 és a Gen5 esetében, mivel a Gen4-ben nagyobb a memória/mag arány.

Azok a számítási feladatok, amelyek érzékenyek a hardverváltozásra, vagy akik szabályozni szeretnék, hogy melyik hardvergenerációt szeretnék használni az adatbázisukhoz, a virtuálismag-alapú modellel kiválaszthatják az előnyben részesített hardvergenerációt az adatbázis létrehozása és skálázása során. A virtuálismag-alapú modellben minden egyes hardvergeneráció szolgáltatási célkitűzésének erőforráskorlátai dokumentálva vannak az egy-adatbázisra és a rugalmas készletekre is. További információ a virtuálismag-alapú modellben található hardvergenerációkról: Hardvergenerációk hardvergenerációk SQL Database hardvergenerációk a virtuálismag-SQL Managed Instance.

Gyakori kérdések (GYIK)

Offline állapotba kell hoznom az alkalmazást, hogy DTU-alapú szolgáltatási szintről virtuálismag-alapú szolgáltatási szintre váltsak?

Nem. Az alkalmazást nem kell offline állapotba vinnie. Az új szolgáltatási szintek egy egyszerű online konverziós módszert kínálnak, amely hasonló az adatbázisok standard szolgáltatási szintről prémium szolgáltatási szintre való frissítésének meglévő folyamatához, és a többihez hasonló. Ezt az átalakítást a következő parancsokkal kezdheti meg: Azure Portal, a PowerShell, az Azure CLI, a T-SQL vagy a REST API. Lásd az önálló adatbázisok kezelését és a rugalmas készletek kezelését ismertető részt.

Konvertálható egy adatbázis a virtuálismag-alapú vásárlási modell szolgáltatási rétege helyett a DTU-alapú vásárlási modell szolgáltatási rétegeként?

Igen, az adatbázist egyszerűen átalakíthatja bármilyen támogatott teljesítménybeli célkitűzésre a Azure Portal, a PowerShell, az Azure CLI, a T-SQL vagy a REST API. Lásd az önálló adatbázisok kezelését és a rugalmas készletek kezelését ismertető részt.

Következő lépések