Olvasás angol nyelven

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


Vertikális felskálázás az Azure SQL Database-lel

A következőkre vonatkozik:Azure SQL Database

Az Azure SQL Database-ben egyszerűen méretezheti az adatbázisokat a rugalmas adatbázis- eszközökkel. Ezek az eszközök és funkciók lehetővé teszik, hogy Azure SQL Database adatbázis-erőforrásait használva megoldásokat hozzon létre a tranzakciós számítási feladatokhoz, különösen az SaaS-alkalmazásokhoz. A rugalmas adatbázis funkciói a következőkből állnak:

Az alábbi ábrán egy olyan architektúra látható, amely tartalmazza az rugalmas adatbázis funkcióit, adatbázis-gyűjteményhez viszonyítva.

Ebben a ábrában az adatbázis színei sémákat jelölnek. Az azonos színű adatbázisok ugyanazt a sémát használják.

  1. Az Azure-ban SQL-adatbázisok skálázási architektúrával üzemelnek.
  2. A Rugalmas adatbázis ügyfélkódtár a szegmenskészletek kezelésére szolgál.
  3. Az adatbázisok egy részhalmaza egy rugalmas készletbekerül.
  4. Egy rugalmas adatbázis-feladat T-SQL-szkripteket futtat az összes adatbázison.
  5. A felosztásos egyesítési eszköz az adatok egyik szeletből a másikba való áthelyezésére szolgál.
  6. A rugalmas adatbázis-lekérdezés lehetővé teszi, hogy olyan lekérdezést írjon, amely a szegmenskészlet összes adatbázisára kiterjed.
  7. rugalmas tranzakciók lehetővé teszik több adatbázisra kiterjedő tranzakciók futtatását.

rugalmas adatbázis-eszközök diagramja.

Miért érdemes használni az eszközöket?

A felhőalkalmazások rugalmasságának és skálázásának elérése a virtuális gépek és a blobtárolók számára egyszerű – egyszerűen egységeket adhat hozzá vagy vonhat ki, vagy növelheti a teljesítményt. A relációs adatbázisok állapotalapú adatfeldolgozása azonban továbbra is kihívást jelent. Az alábbi forgatókönyvekben felmerülő kihívások:

  • A számítási feladat relációs adatbázis-részének kapacitásának növekedése és zsugorítása.
  • Olyan hotspotok kezelése, amelyek az adatok egy adott részhalmazát érinthetik – például egy foglalt végfelhasználót (bérlőt).

Az ilyen forgatókönyveket hagyományosan az alkalmazás támogatásához nagyobb méretű kiszolgálókba való befektetéssel oldották meg. Ez a lehetőség azonban korlátozott a felhőben, ahol minden feldolgozás előre meghatározott áruhardveren történik. Ehelyett az adatok és a feldolgozás elosztása számos azonos strukturált adatbázis között (a horizontális felskálázási minta, más néven horizontális felskálázás) alternatívát kínál a hagyományos vertikális felskálázási megközelítésekkel szemben mind a költségek, mind a rugalmasság szempontjából.

Vízszintes és függőleges skálázás

Az alábbi ábra a skálázás vízszintes és függőleges dimenzióit mutatja be, amelyek a rugalmas adatbázisok méretezésének alapvető módjai.

Vízszintes és függőleges horizontális felskálázást bemutató diagram.

A horizontális skálázás az adatbázisok hozzáadását vagy eltávolítását jelenti a kapacitás vagy az általános teljesítmény módosítása érdekében, más néven "horizontális felskálázás". A horizontális skálázás megvalósításának gyakori módja a horizontális horizontális skálázás, amelyben az adatok azonos strukturált adatbázisok gyűjteményei között particionálva lesznek.

A vertikális skálázás az egyes adatbázisok számítási méretének növelését vagy csökkentését jelenti, más néven "vertikális felskálázást".

A legtöbb felhőalapú adatbázis-alkalmazás a két stratégia kombinációját használja. A szoftver mint szolgáltatásalkalmazás például horizontális skálázást használhat az új végfelhasználók kiépítéséhez és a vertikális skálázáshoz, hogy az egyes végfelhasználók adatbázisa a számítási feladat igényeinek megfelelően növelje vagy zsugorítja az erőforrásokat.

  • A horizontális skálázás kezelése az Rugalmas adatbázis ügyfélkódtárhasználatával történik.
  • A vertikális skálázás az Azure PowerShell-parancsmagok használatával történik a szolgáltatási szint módosításához vagy az adatbázisok rugalmas készletbe helyezéséhez.

Horizontális skálázás

Sharding egy olyan technika, amely nagy mennyiségű azonosan strukturált adatot oszt el számos független adatbázis között. Különösen népszerű a felhőfejlesztők körében, akik szoftvert mint szolgáltatást (SAAS) kínáló megoldásokat hoznak létre végfelhasználóknak vagy vállalkozásoknak. Ezeket a végfelhasználókat gyakran "bérlőknek" nevezik. Számos okból lehet szükség horizontális skálázásra:

  • Az adatok teljes mennyisége túl nagy ahhoz, hogy beleférjen az egyes adatbázisok korlátaiba
  • A teljes számítási feladat tranzakciós átviteli sebessége meghaladja az egyes adatbázisok képességeit
  • A bérlők fizikai elkülönítést igényelhetnek egymástól, ezért minden bérlőhöz külön adatbázisokra van szükség
  • Az adatbázisok különböző szakaszainak megfelelőségi, teljesítménybeli vagy geopolitikai okokból különböző földrajzi helyeken kell elhelyezkedniük.

Más esetekben, például az elosztott eszközökről történő adatbetöltés esetén a horizontális skálázás használható az ideiglenesen rendszerezett adatbázisok halmazának kitöltésére. Egy külön adatbázis például minden napra vagy hétre dedikáltan használható. Ebben az esetben a horizontális skálázási kulcs lehet egy egész szám, amely a dátumot képviseli (minden szegmenses tábla összes sorában jelen van), és az alkalmazásnak a dátumtartományhoz tartozó adatokat lekérő lekérdezéseket a megfelelő tartományt lefedő adatbázisok részhalmazához kell irányítania.

A horizontális skálázás akkor működik a legjobban, ha egy alkalmazás minden tranzakciója egy szegmenskulcs egyetlen értékére korlátozható. Ez biztosítja, hogy az összes tranzakció egy adott adatbázishoz legyen helyi.

Több bérlős és egy bérlős

Egyes alkalmazások a legegyszerűbb módszert használják arra, hogy minden bérlőhöz külön adatbázist hozzanak létre. Ez a megközelítés az egybérlős szeletelési minta, amely elkülönítést, biztonsági mentési/visszaállítási képességet és erőforrás-skálázást biztosít a bérlő szintjén. Az önálló bérlői horizontális skálázás esetén minden adatbázis egy adott bérlőazonosító-értékkel (vagy ügyfélkulcs-értékkel) van társítva, de ennek a kulcsnak nem kell szerepelnie az adatokban. Az alkalmazás feladata, hogy minden kérést a megfelelő adatbázishoz irányítson , és az ügyfélkódtár egyszerűsítheti ezt a feladatot.

egybérlős és több-bérlős diagram.

Más forgatókönyvek több bérlőt csomagolnak össze adatbázisokba ahelyett, hogy külön adatbázisokba osztanák őket. Ez a minta egy tipikus több-bérlős horizontális skálázási minta - és ennek az lehet az oka, hogy egy alkalmazás nagy számú kis bérlőt kezel. Több-bérlős skálázás esetén az adatbázistáblák sorai mind úgy vannak kialakítva, hogy a bérlőazonosítót vagy a horizontális skálázási kulcsot azonosító kulcsot hordozzák. Az alkalmazásszint feladata a bérlői kérések átirányítása a megfelelő adatbázisba, és ezt a rugalmas adatbázis-ügyfélkódtár is támogatja. Emellett a sorszintű biztonság segítségével szűrheti, hogy az egyes bérlők mely sorokat érhetik el – a részletekért lásd rugalmas adatbáziseszközökkel és sorszintű biztonságirendelkező több-bérlős alkalmazásokat. Az adatok adatbázisok közötti újraelosztására szükség lehet a több-bérlős fragmentációs mintázat esetében, amit a rugalmas adatbázis szétválasztás-összevonási eszköz segít elő. Ha többet szeretne megtudni a rugalmas készleteket használó SaaS-alkalmazások tervezési mintáiról, tekintse meg Több-bérlős SaaS-adatbázis bérlői mintáit.

Adatok áthelyezése többről egy-bérlős adatbázisokra

SaaS-alkalmazások létrehozásakor általában a szoftver próbaverzióját kínálják a leendő ügyfeleknek. Ebben az esetben költséghatékony, ha több-bérlős adatbázist használ az adatokhoz. Ha azonban egy potenciális ügyfél ügyfél lesz, az egybérlős adatbázis jobb, mivel jobb teljesítményt nyújt. Ha az ügyfél a próbaidőszak során hoz létre adatokat, az felosztásos-egyesítési eszköz használatával helyezze át az adatokat a multibérlős adatbázisból az új egybérlős adatbázisba.

Megjegyzés

Több-bérlős adatbázisokból egyetlen bérlőre történő visszaállítás nem lehetséges.

Minták és oktatóanyagok

Az ügyfélkódtárat bemutató mintaalkalmazásért lásd: Elastic Database-eszközök használatának első lépései.

Ha meglévő adatbázisokat szeretne átalakítani az eszközök használatára, olvassa el Meglévő adatbázisok áttelepítése avertikális felskálázásához című témakört.

A rugalmas készlet jellemzőinek megtekintéséhez tekintse meg rugalmas készlet ár- és teljesítménybeli szempontjait, vagy hozzon létre egy új készletet rugalmas készletekkel.

Még nem használ rugalmas adatbázis-eszközöket? Tekintse meg első lépések útmutatónkat. Ha kérdése van, lépjen kapcsolatba velünk a Microsoft Q&Az SQL Database kérdésoldalán, és a funkciókérésekért, adjon hozzá új ötleteket, vagy szavazzon a meglévő ötletekre a SQL Database visszajelzési fórumában.