Megosztás a következőn keresztül:

Teljesítmény optimalizálása memóriabeli technológiák használatával az Azure SQL Database-ben

A következőkre vonatkozik:Azure SQL Database

A memóriabeli technológiák lehetővé teszik az alkalmazás teljesítményének javítását és az adatbázis költségeinek csökkentését.

Mikor érdemes memóriabeli technológiákat használni?

A memóriabeli technológiák használatával teljesítménybeli fejlesztéseket érhet el különböző számítási feladatok használatával:

  • Tranzakciós (online tranzakciós feldolgozás (OLTP)), ahol a kérések többsége kisebb adatkészleteket olvas vagy frissít, például létrehozási/olvasási/frissítési/törlési (CRUD) műveleteket.
  • Elemzési (online elemzési feldolgozás (OLAP)), ahol a lekérdezések többsége jelentéskészítési célból összetett számításokkal rendelkezik, valamint rendszeresen ütemezett folyamatok, amelyek betöltési (vagy tömeges terheléses) műveleteket hajtanak végre, és/vagy adatmódosításokat írnak a meglévő táblákba. Az OLAP-számítási feladatok gyakran rendszeresen frissülnek az OLTP számítási feladatokról.
  • vegyes (hibrid tranzakció-elemzési feldolgozás (HTAP)), ahol az OLTP- és OLAP-lekérdezések is ugyanazon az adatkészleten futnak.

A memórián belüli technológiák javíthatják ezeknek a számítási feladatoknak a teljesítményét a feldolgozandó adatok memóriában tartásával, a lekérdezések natív fordításával, vagy speciális feldolgozással, például a mögöttes hardveren elérhető kötegelt feldolgozással és SIMD-utasításokkal.

Áttekintés

Az Azure SQL Database a következő memóriabeli technológiákat támogatja:

  • In-Memory OLTP növeli a másodpercenkénti tranzakciók számát, és csökkenti a tranzakciófeldolgozás késését. Az In-Memory OLTP előnyeit kihasználó forgatókönyvek a következők: nagy átviteli sebességű tranzakciófeldolgozás, például kereskedés és játék, eseményekből vagy IoT-eszközökből származó adatbetöltés, gyorsítótárazás, adatbetöltés, valamint ideiglenes tábla- és táblaváltozó-forgatókönyvek.
  • fürtözött oszlopcentrikus indexek csökkentik a tárolókapacitást (akár 10-szer), és javítják a jelentéskészítési és elemzési lekérdezések teljesítményét. Az adatpiacokon lévő ténytáblákkal több adat illeszthető be az adatbázisba, és javíthatja a teljesítményt. Emellett az operatív adatbázisban lévő előzményadatokkal is archiválhatja az adatokat, és akár tízszer több adatot is lekérdezhet.
  • Nem klaszterezett oszlopraktár-indexek az HTAP számára valós idejű betekintést nyerhet vállalkozásába azáltal, hogy közvetlenül lekérdezi az operatív adatbázist anélkül, hogy költséges kinyerési, átalakítási és betöltési (ETL) folyamatot futtatna, és várnia kellene az adattárház feltöltésére. A nemclustered oszlopalapú indexek lehetővé teszik az elemzési lekérdezések gyors végrehajtását az OLTP-adatbázisban, miközben csökkentik a működési terhelésre gyakorolt hatást.
  • HTAP-hoz memóriaoptimalizált fürtözött oszlopcentrikus indexek lehetővé teszik a gyors tranzakciófeldolgozást, valamint az elemzési lekérdezések egyidejűleg elemzési lekérdezések nagyon gyors futtatását ugyanazon adatokon.

Az oszlopcentrikus indexeket és In-Memory OLTP-t 2012-ben és 2014-ben vezették be az SQL Serverhez. Az Azure SQL Database, az Azure SQL Managed Instance és az SQL Server ugyanazt a memóriabeli technológiákat valósítja meg.

Jegyzet

Részletes oktatóanyag az In-Memory OLTP technológia teljesítménybeli előnyeinek bemutatásához, amely a AdventureWorksLT mintaadatbázis és a ostress.exehasználatával készült, lásd a Memóriabeli minta az Azure SQL Database.

A memóriabeli technológia előnyei

A hatékonyabb lekérdezés- és tranzakciófeldolgozás miatt a memóriabeli technológiák is segítenek a költségek csökkentésében. A teljesítménynövekedés eléréséhez általában nem kell frissítenie az adatbázis tarifacsomagját. Bizonyos esetekben akár a díjkategóriát is csökkentheti, miközben a memóriabeli technológiákkal teljesítménybeli javulást tapasztalhat.

Az In-Memory OLTP használatával a Quorum Business Solutions meg tudta duplázni a számítási feladatokat, miközben a DTU-k 70%javultak. További információ: In-Memory OLTP az Azure SQL-adatbázisban.

Jegyzet

In-Memory OLTP az Azure SQL Database prémium (DTU) és üzletileg kritikus (vCore) szolgáltatási szintjeiben érhető el. A rugalmas skálázási szolgáltatási szint In-Memory OLTP-objektumok egy részhalmazát támogatja. További információ: rugalmas skálázási korlátozások.

Az oszlopcentrikus indexek az Alapszintű szint kivételével minden szolgáltatási szinten elérhetők, és a Standard szinten, ha a szolgáltatási célkitűzés S3 alatt van. További információ: Oszlopcentrikus indexeket tartalmazó adatbázisok szolgáltatási szintjének módosítása.

Ez a cikk az Azure SQL Database-hez kapcsolódó In-Memory OLTP- és oszlopcentrikus indexek jellemzőit ismerteti, valamint az alábbi példákat is tartalmazza:

  • Ezeknek a technológiáknak a tárolási és adatméret-korlátokra gyakorolt hatása.
  • Az ezeket a technológiákat használó adatbázisok különböző tarifacsomagok közötti mozgásának kezelése.
  • Az In-Memory OLTP és az oszlopcentrikus indexek szemléltető használata.

Az SQL Server memórián belüli technológiáival kapcsolatos további információkért lásd:

In-Memory OLTP

In-Memory OLTP technológia rendkívül gyors adathozzáférési műveleteket biztosít az összes adat memóriában tartásával. Speciális indexeket, lekérdezések natív fordítását és reteszmentes adathozzáférést is használ az OLTP-számítási feladat teljesítményének javítása érdekében. Az In-Memory OLTP-adatok rendszerezésének két módja van:

  • memória-optimalizált sortár formátum, ahol minden sor külön memóriaobjektum. Ez egy klasszikus In-Memory OLTP-formátum, amely nagy teljesítményű OLTP-számítási feladatokhoz van optimalizálva. A memóriaoptimalizált tábláknak két típusa van, amelyek memóriaoptimalizált sortár formátumban használhatók:

    • tartós táblák (SCHEMA_AND_DATA), ahol a memóriába helyezett sorok megmaradnak a kiszolgáló újraindítása után. Az ilyen típusú táblák úgy viselkednek, mint egy hagyományos soráruházi tábla, a memóriabeli optimalizálás további előnyeivel.
    • Nem használható táblák (SCHEMA_ONLY), ahol a sorok nem maradnak meg az újraindítás után. Ez a táblatípus ideiglenes adatokhoz (például ideiglenes táblák cseréjéhez) készült, vagy olyan táblákhoz, ahol gyorsan be kell töltenie az adatokat, mielőtt áthelyezi őket egy tárolt táblába (úgynevezett átmeneti táblákba).

  • Memóriaoptimalizált oszlopformátumú formátum, ahol az adatok oszlopos formátumban vannak rendszerezve. Ez a struktúra olyan HTAP-forgatókönyvekhez készült, ahol elemzési lekérdezéseket kell futtatnia ugyanazon az adatstruktúrán, amelyen az OLTP-számítási feladat fut.

Jegyzet

In-Memory OLTP-technológia olyan adatstruktúrákhoz lett kialakítva, amelyek teljes mértékben képesek a memóriában tartózkodni. Mivel a memóriában lévő adatok nem tölthetők ki a lemezre, győződjön meg arról, hogy elegendő memóriával rendelkező adatbázist használ. További információért lásd az OLTPIn-Memory adatméretét és tárhelykorlátját.

Adatméret és tárterületkorlát In-Memory OLTP-hez

In-Memory OLTP memóriaoptimalizált táblákat tartalmaz, amelyek a felhasználói adatok tárolására szolgálnak. Ezeknek a tábláknak a memóriában kell elférniük. Minden szolgáltatási célkitűzés rendelkezik memóriakvótával vagy -korláttal a memóriaoptimalizált táblákhoz, más néven In-Memory OLTP storage.

Minden támogatott egyadatbázis-szolgáltatás célkitűzése és minden rugalmas készletszolgáltatás-célkitűzés tartalmaz egy bizonyos mennyiségű In-Memory OLTP-tárolót:

Az alábbi elemek számítanak bele az In-Memory OLTP-tárterületkorlátba:

  • Aktív felhasználói adatsorok memóriaoptimalizált táblákban és táblaváltozókban. A régi sorverziók nem számítanak bele a korlátba.
  • Indexek memóriaoptimalizált táblákon.
  • Az ALTER TABLE-műveletek működési többletterhelése.

Ha eléri a korlátot, kvótán kívüli hibaüzenet jelenik meg, és már nem tud adatokat beszúrni vagy frissíteni. A hiba elhárításához törölje az adatokat, vagy növelje az adatbázis vagy a rugalmas készlet szolgáltatási célkitűzését.

Az In-Memory OLTP-tárterület kihasználtságának figyeléséről és a riasztások konfigurálásáról, amikor már közel kerül a határértékhez, a Monitor In-Memory OLTP-tárterületcímű témakörben olvashat.

Tudnivalók a rugalmas készletekről

Rugalmas készletek esetén az In-Memory OLTP-tároló a készlet összes adatbázisában meg van osztva. Ezért az egyik adatbázis használata hatással lehet más adatbázisokra is. Ehhez két megoldás érhető el:

  • Konfiguráljon Max eDTU-t vagy Max vCore-et azokhoz az adatbázisokhoz, amelyek alacsonyabbak, mint a teljes készlet eDTU- vagy vCore-száma. Ez a maximális érték a készlet bármely adatbázisának In-Memory OLTP-tárterület-kihasználtságát is arányosan korlátozza.
  • Konfigurálj egy Min eDTU vagy Min vCore értéket, amely nagyobb mint 0. Ez a minimális garancia arra, hogy a készlet minden adatbázisa rendelkezik a konfigurált Min eDTU vagy Min vCore-nek megfelelő mennyiségű elérhető In-Memory OLTP-tárterülettel.

Az In-Memory OLTP-technológiákat használó adatbázisok szolgáltatási szintjének módosítása

In-Memory OLTP nem támogatott az Azure SQL Database Általános célú, Standard és Alapszintű szolgáltatási szintjeiben. Ezért nem lehet olyan adatbázist skálázni, amely rendelkezik In-Memory OLTP-objektumokkal ezen szintek egyikére. Ha egy adatbázist ezen szolgáltatási szintek egyikére szeretne skálázni, távolítsa el az összes memóriaoptimalizált táblát és táblázattípust, valamint az összes natívan lefordított T-SQL-modult, vagy konvertálja őket lemezalapú objektumokká és hagyományos T-SQL-modulokká.

Üzletileg kritikus vagy prémium szintű adatbázisok méretezésekor a memóriaoptimalizált táblák adatainak el kell férniük az adatbázis vagy rugalmas készlet célszolgáltatás-célkitűzésében elérhető In-Memory OLTP-tárolóban. Ha le szeretné méretezni az adatbázist vagy a rugalmas készletet, vagy áthelyez egy adatbázist egy rugalmas készletbe, és a célszolgáltatás célkitűzése nem rendelkezik elegendő rendelkezésre álló In-Memory OLTP-tárolóval, a művelet meghiúsul.

Annak meghatározása, hogy léteznek-e In-Memory OLTP-objektumok

Programozott módon állapítható meg, hogy egy adott adatbázis támogatja-e In-Memory OLTP-t. A következő Transact-SQL lekérdezést hajthatja végre:

SELECT DATABASEPROPERTYEX(DB_NAME(), 'IsXTPSupported');

Ha a lekérdezés 1ad vissza, In-Memory OLTP támogatott ebben az adatbázisban.

A következő lekérdezések azonosítják azokat az objektumokat, amelyeket el kell távolítani ahhoz, hogy az adatbázis rugalmas skálázási, általános célú, standard vagy alapszintű szolgáltatási szintre skálázható legyen:

SELECT * FROM sys.tables WHERE is_memory_optimized = 1;
SELECT * FROM sys.table_types WHERE is_memory_optimized = 1;
SELECT * FROM sys.sql_modules WHERE uses_native_compilation = 1;

Memóriabeli oszloptár

A memóriabeli oszlopcentrikus technológia lehetővé teszi nagy mennyiségű adat tárolását és lekérdezését a táblákban. A Columnstore technológia oszlopalapú adattárolási formátumot és kötegelt lekérdezésfeldolgozást használ annak érdekében, hogy az OLAP-számítási feladatok lekérdezési teljesítményének akár 10-szeresére is szert tehessenek a hagyományos sororientált tárolással szemben. Az adatok tömörítése akár tízszer hatékonyabb is lehet, mint a tömörítetlen adatméret.

Az oszlopcentrikus indexek két típusa használható az adatok rendszerezésére:

  • Fürtözött oszlopadatbázis, ahol a tábla minden adata oszlopformátumban van rendszerezve. Ebben az indextípusban a táblázat összes sora oszlopos formátumban van elhelyezve, amely nagy mértékben tömöríti az adatokat, és lehetővé teszi gyors elemzési lekérdezések és jelentések végrehajtását a táblán. Az adatok jellegétől függően az adatok mérete 10x-100x-ra csökkenhet. A fürtözött oszlopcentrikus indexek nagy mennyiségű adat gyors betöltését is lehetővé teszik (tömeges terhelés), mivel a lemezen való tárolás előtt a rendszer a 100 000 sornál nagyobb adatkötegeket tömöríti. Ez az indextípus jó választás a klasszikus adattárház-forgatókönyvekhez.
  • nem fürtözött oszlopcentrikus, ahol az adatokat hagyományos sortártáblában tárolják, és az elemzési lekérdezésekhez használt oszlopcentrikus formátumban van egy további index. Ez az indextípus lehetővé teszi a hibrid Transactional-Analytic-feldolgozást (HTAP): lehetővé teszi a gyors valós idejű elemzések futtatását egy tranzakciós számítási feladaton. Az OLTP-lekérdezések olyan sortártáblán futnak, amely kis sorok elérésére van optimalizálva, míg az OLAP-lekérdezések az oszlopcentrikus indexen futnak, amely jobb választás a vizsgálatokhoz és az elemzésekhez. A lekérdezésoptimalizáló dinamikusan választja ki a sor- vagy oszlopalapú formátumot a lekérdezés alapján. A nemclustered oszlopcentrikus indexek nem csökkentik az adatok méretét, mivel az eredeti adatkészlet minden módosítás nélkül az eredeti sortártáblában marad. A további oszlopcentrikus index mérete azonban nagyságrendekkel kisebb, mint az egyenértékű B-fa index.

Jegyzet

A memóriabeli oszlopcentrikus technológia csak a memóriában történő feldolgozáshoz szükséges adatokat tárolja, míg a memóriába nem férő adatokat a rendszer lemezen tárolja. Ezért az oszloptár-struktúrákban lévő adatok mennyisége meghaladhatja a rendelkezésre álló memória mennyiségét.

Oszlopcentrikus indexek adatmérete és tárhelye

Az oszlopcentrikus indexeknek nem kell teljes mértékben a memóriában elférniük. Ezért az indexek méretének egyetlen korlátja a maximális teljes adatbázisméret, amelyet a DTU-alapú vásárlási modell és virtuális magalapú vásárlási modell cikkekben dokumentálunk.

Fürtözött oszlopcentrikus indexek használata esetén a rendszer oszlopos tömörítést használ az alaptábla-tárolóhoz. Ez a tömörítés jelentősen csökkentheti a felhasználói adatok tárolási lábnyomát, ami azt jelenti, hogy több adatot is elfér az adatbázisban. A tömörítési arány tovább növelhető az oszlopos archiválásitömörítéssel. Az elérhető tömörítés mennyisége az adatok jellegétől függ, de a tömörítés tízszerese nem ritka.

Ha például egy 1 terabájtos (TB) méretű adatbázissal rendelkezik, és oszlopcentrikus indexek használatával eléri a tömörítés tízszeresét, összesen 10 TB felhasználói adatot illeszthet be az adatbázisban.

Ha nem klaszterezett oszlopalapú indexeket használ, az alaptábla hagyományos sortároló formátumban tárolódik továbbra is. Ezért a tárolási megtakarítás nem olyan jelentős, mint a klaszterezett oszlopcentrikus indexek esetén. Ha azonban sok hagyományos nemclustered indexet egyetlen oszlopcentrikus indexre cserél, a tábla tárolási lábnyomában továbbra is általános megtakarítás látható. Az alaptáblához használhatja a rowstore adattömörítési is.

Oszlopcentrikus indexeket tartalmazó adatbázisok szolgáltatási szintjének módosítása

Ha a DTU vásárlási modellt használja, és az adatbázis oszlopcentrikus indexeket tartalmaz, az alkalmazás leállhat, ha az adatbázist az S3 szolgáltatás célkitűzése alatt skálázza. Az oszlopcentrikus indexek csak a rugalmas skálázási, üzletileg kritikus és prémium szolgáltatási szinteken, valamint a Standard szolgáltatási szinten támogatottak, ha S3 vagy újabb verziót használnak. Az oszlopcentrikus indexek nem támogatottak az Alapszintű szolgáltatási szinten. Ha az adatbázist nem támogatott szolgáltatási szintre vagy szolgáltatási célkitűzésre skálázza, az oszlopcentrikus index elérhetetlenné válik. A rendszer dML-utasítások végrehajtásakor tartja karban az indexet, de soha nem használja az indexet. Ha később visszaskálázható egy támogatott szolgáltatási szintre vagy szolgáltatási célkitűzésre, az oszlopcentrikus index azonnal készen áll az újbóli használatra.

Ha a fürtözött oszlopcentrikus index egy nem támogatott szolgáltatási szintre vagy szolgáltatási célkitűzésre van skálázva, a teljes tábla elérhetetlenné válik. A skálázási művelet előtt távolítsa el az összes oszlopstore indexet, majd cserélje le őket sorstore fürtözött indexekre vagy halmokra.

Kapcsolódó tartalom

  • Last updated on