Horizontális particionálási minta

Egy adattárat horizontális partíció- vagy szilánkkészletté oszthat fel. Ezzel javíthatja a skálázhatóságot nagy adatmennyiségek tárolásakor és elérésekor.

Kontextus és probléma

Az egyetlen kiszolgáló által futtatott adattárolókra az alábbi korlátozások vonatkozhatnak:

• Tárolóhely. A nagyméretű felhőalkalmazások adattára várhatóan hatalmas mennyiségű adatokat fog tartalmazni, és adatok mennyisége idővel jelentősen megnőhet. Egy kiszolgáló jellemzően korlátozott méretű lemezterületet biztosít, a meglévő lemezeket azonban kicserélheti nagyobbakra, vagy további lemezekkel bővítheti a gépet az adatmennyiség növekedésével. A rendszer viszont végül el fog érni egy korlátot, amikor már nem lehet könnyen növelni a kiszolgáló tárolókapacitását.

• Számítási erőforrások. A felhőalkalmazásoknak nagyszámú egyidejű felhasználót kell támogatniuk, akik mindegyike az adattárban lévő információkat lekérő lekérdezéseket futtat. Előfordulhat, hogy az adattárat üzemeltető egyetlen kiszolgáló nem tudja biztosítani a terhelés támogatásához szükséges számítási teljesítményt, ami hosszabb válaszidőt eredményez a felhasználók számára, és gyakori hibákhoz vezet, amikor az alkalmazások időtúllépést próbálnak tárolni és lekérni az adatokat. Lehetséges memória hozzáadása vagy processzorok frissítése, de a rendszer akkor éri el a korlátot, ha nem lehet tovább növelni a számítási erőforrásokat.

• Hálózati sávszélesség. Az egyetlen kiszolgálón futó adattárak teljesítményét végső soron az a sebesség határozza meg, amellyel a kiszolgáló képes a kérések fogadására és a válaszok elküldésére. Előfordulhat, hogy a hálózati forgalom mennyisége meghaladja a kiszolgálóhoz való csatlakozáshoz használt hálózat kapacitását, ami sikertelen kéréseket eredményez.

• Földrajzi hely. Jogi, megfelelőségi vagy teljesítménnyel kapcsolatos okokból, vagy pedig az adatelérés késésének csökkentése érdekében szükséges lehet az adott felhasználók által létrehozott adatokat a felhasználó régiójában tárolni. Ha a felhasználók különböző országokban vagy régiókban vannak, előfordulhat, hogy nem lehet egyetlen adattárolóban tárolni az alkalmazás összes adatát.

A nagyobb lemezkapacitás, feldolgozási teljesítmény, több memória és hálózati kapcsolat hozzáadásával történő függőlegesen skálázás késleltetheti néhány ilyen korlátozás hatását, valószínűleg azonban csak ideiglenes megoldást jelent. A nagyszámú felhasználót és nagy mennyiségű adatot támogató kereskedelmi felhőalkalmazásoknak szinte végtelen skálázásra kell képesnek lenniük, így a függőleges skálázás nem feltétlenül a legjobb megoldás.

Megoldás

Ossza fel az adattárat horizontális partíciókra vagy szegmensekre. Mindegyik szegmens ugyanazzal a sémával rendelkezik, azonban az adatok saját különálló részhalmazát tartalmazzák. A szegmensek adattárnak számítanak (sok különböző típusú entitás adatait tartalmazhatják), amelyek a tárolócsomópontként működő kiszolgálón futnak.

Ez a minta az alábbi előnyökkel jár:

• A rendszer horizontális skálázásához további tárolócsomópontokon futó további szegmenseket adhat hozzá.

• A rendszer azonnali használatra kész hardvert használhat az egyes tárolócsomópontokhoz szükséges speciális és költséges számítógépek helyett.

• A számítási feladatoknak a szegmensek közötti elosztásával csökkentheti a versengést és növelheti teljesítményt.

• A felhőben a szegmensek fizikailag közel helyezhetők el az adatokat elérő felhasználókhoz.

Amikor az adatárat szegmensekre osztja, döntse el, mely adatok kerüljenek az egyes szegmensekbe. A szegmensek általában olyan elemeket tartalmaznak, amelyek az adatok egy vagy több attribútuma által meghatározott tartományba esnek. Ezek az attribútumok alkotják a szegmenskulcsot (amelyet néha partíciókulcsnak is neveznek). A szegmenskulcsnak statikusnak kell lennie. Nem alapulhat olyan adatokon, amelyek változhatnak.

A horizontális skálázás fizikailag rendezi az adatokat. Ha egy alkalmazás adatokat tárol és kér le, a horizontális skálázási logika az alkalmazást a megfelelő szegmenshez irányítja. A horizontális skálázási logika megvalósítható az alkalmazás adatelérési kódjának részeként, vagy pedig az adattároló rendszer valósíthatja meg, ha transzparens módon támogatja a horizontális skálázást.

Az adatok fizikai helyének a horizontális skálázási logikában való meghatározásával magas szinten szabályozható, hogy az egyes szegmensek mely adatokat tartalmazzák. Emellett lehetővé teszi azt is, hogy az adatok az alkalmazás üzleti logikájának átdolgozása lehessen migrálhatók, ha a szegmensekben lévő adatokat később újra el kellene osztani (például akkor, ha a szegmensek kiegyensúlyozatlanná válnak). Ennek ára a további adatelérési terhelés, amelyre az adatok helyének meghatározásához van szükség az adatok lekérésekor.

Az optimális teljesítmény és skálázhatóság biztosítása érdekében olyan módon kell felosztani az adatokat, amely megfelel az alkalmazás által végrehajtott lekérdezések típusának. Sok esetben nem valószínű, hogy a horizontális skálázási séma pontosan megfelel minden lekérdezés követelményeinek. Egy több-bérlős rendszerben például előfordulhat, hogy egy alkalmazásnak bérlői adatokat kell lekérnie a bérlőazonosító használatával, de előfordulhat, hogy más attribútum, például a bérlő neve vagy helye alapján is meg kell keresnie ezeket az adatokat. Az ilyen helyzetek kezelése érdekében a leggyakrabban végrehajtott lekérdezéseket támogató szegmenskulccsal rendelkező horizontális skálázási stratégiát valósítson meg.

Ha a lekérdezések rendszeresen kérnek le adatokat az attribútumértékek kombinációjával, valószínűleg meghatározhat egy összetett szegmenskulcsot az attribútumok összekapcsolásával. Másik megoldásként egy mintával, például az indextábla használatával teheti lehetővé az adatok gyors keresését olyan attribútumok alapján, amelyekre a szegmenskulcs nem terjed ki.

Horizontális skálázási stratégiák

A szegmenskulcs kiválasztása és az adatok szegmensek közötti elosztási módjának meghatározása három gyakori stratégia használatával történik. Vegye figyelembe, hogy nem kell egy-az-egyhez típusú levelezést létrehozni a szegmensek és az őket üzemeltető kiszolgálók között – egyetlen kiszolgáló több szegmenst is üzemeltethet. A stratégiák az alábbiak:

A keresési stratégia. Ebben a stratégiában a horizontális skálázási logika olyan összerendelést valósít meg, amely az adatkéréseket az adatokat tartalmazó szegmenshez irányítja a szegmenskulccsal. Egy több-bérlős alkalmazásban a bérlő összes adata egy szegmensben tárolható, a bérlőazonosítót használva szegmenskulcsként. Ugyanazon a szegmensen osztozhat több, azonban egy adott bérlő adatai nem oszlanak meg több szegmens között. Az ábra a bérlőadatok bérlőazonosítókon alapuló horizontális skálázását mutatja be.

A szegmenskulcs értéke és az adatok fizikai tárolója közötti megfeleltetés olyan fizikai szegmenseken alapulhat, ahol minden szegmenskulcs értéke egy fizikai partícióra van leképezve. A szegmensek újraegyensúlyozásának egy rugalmasabb módszere a virtuális particionálás, ahol a szegmenskulcsok értéke ugyanahhoz a virtuális szegmenshez van megfeleltetve, ami kevesebb fizikai partíciót képez le. Ebben a megközelítésben egy alkalmazás egy virtuális szegmensre hivatkozó szegmenskulcs-érték használatával keresi meg az adatokat, a rendszer pedig transzparens módon leképezi a virtuális szegmenseket a fizikai partíciókra. A virtuális szegmensek és a fizikai partíciók közötti megfeleltetés anélkül változhat, hogy az alkalmazás kódját módosítani kellene a szegmenskulcsok eltérő értékeinek használatához.

A tartományalapú stratégia. Ez a stratégia csoportosítja a kapcsolódó elemeket ugyanabban a szegmensben, és szilánkkulcs alapján rendeli őket – a szegmenskulcsok szekvenciálisak. Ez olyan alkalmazások esetén hasznos, amelyek gyakran kérnek le elemeket tartománylekérdezésekkel (olyan lekérdezésekkel, amelyek adott tartományba eső szegmenskulcsok adatelemeit adják vissza). Ha például egy alkalmazásnak rendszeresen meg kell keresnie egy adott hónap összes megrendelését, akkor ezek az adatok gyorsabban lekérhetők, ha egy hónap összes megrendelésének a tárolása dátum és idő szerint rendezve történik ugyanabban a szegmensben. Ha az egyes megrendeléseket eltérő szegmensben tárolná, egyenként kellene lekérni azokat nagyszámú pontlekérdezés (egyetlen adatelemet visszaadó lekérdezés) végrehajtásával. A következő ábra az adatok egymást követő halmazának (tartományának) szegmensben való tárolását mutatja be.

Ebben a példában a szegmenskulcs egy összetett kulcs, amelynek a legjelentősebb eleme a megrendelés hónapja, amelyet a megrendelés napja és ideje követ. A megrendelések adatainak rendezése értelemszerűen történik új megrendelések létrehozásakor és a szegmenshez való hozzáadásukkor. Néhány adattár támogatja a két részből álló szegmenskulcsokat, amelyek a szegmenset azonosító partíciókulcs-elemet és a szegmensben lévő elemet egyedi módon azonosító sorkulcsot tartalmaznak. A szegmens általában a sorkulcs sorrendjének megfelelően tárolja az adatokat. A tartománylekérdezésekkel lekérhető és az együtt csoportosítandó elemek olyan szegmenskulcsot használhatnak, amelynek partíciókulcsa a szegmenskulccsal egyező értékű, sorkulcsa azonban egyedi értékkel rendelkezik.

A kivonatolási stratégia. Ennek a stratégiának az a célja, hogy csökkentse a kritikus pontok esélyét (olyan szegmensek, amelyek aránytalanul nagy mennyiségű terhelést kapnak). A stratégia olyan módon osztja el az adatokat a szegmensek között, amely egyensúlyt teremt az egyes szegmensek mérete és a szegmensekre háruló átlagos terhelés között. A horizontális skálázási logika az elemet tároló szegmenst az adatok egy vagy több attribútumának kivonata alapján számítja ki. A kiválasztott kivonatolási függvénynek egyenletesen kell elosztania az adatokat a szegmensek között, lehetőleg valamilyen véletlenszerű elem bevezetésével a számításba. A következő ábra a bérlőadatoknak a bérlőazonosítók kivonata alapján történő horizontális skálázását mutatja be.

A kivonatolási stratégia más horizontális skálázási stratégiákkal szemben nyújtott előnyeinek megértéséhez fontolja meg, hogy egy több-bérlős alkalmazás, amely egymás után regisztrálja az új bérlőket, hogyan rendelheti hozzá a bérlőket az adattárbeli szegmensekhez. A tartományalapú stratégia használatakor az 1–n bérlők adatainak mindegyikét az A szegmens tárolná, az n+1–m bérlők adatainak mindegyikét a B szegmens tárolná, és így tovább. Ha a legutóbb regisztrált bérlők a legaktívabbak is, a legtöbb adattevékenység kevés szegmensben történik, ami kritikus pontokat okozhat. Ezzel szemben a kivonatolási stratégia a bérlőazonosítójuk kivonata alapján rendeli a bérlőket a szegmensekhez. Ez azt jelenti, hogy az egymást követő bérlők valószínűleg különböző szegmensekhez lesznek rendelve, ami elosztja a szegmensek közötti terhelést. Az előző ábra ezt mutatja be az 55. és az 56. bérlőre vonatkozásában.

A három horizontális skálázási stratégia az alábbi előnyökkel és megfontolandó szempontokkal jár:

• Keresési stratégia. Nagyobb mértékű vezérlést nyújt a szegmensek konfigurálásának és használatának módja felett. A virtuális szegmensek használata csökkenti az adatok újraegyensúlyozásakor fellépő terhelést, mert új fizikai partíciók adhatók hozzá a számítási feladatok kiegyenlítése érdekében. A virtuális szegmens és a szegmenst megvalósító fizikai partíciók közötti összerendelés anélkül módosítható, hogy az hatással lenne az adatok tárolására és lekérésére szolgáló szegmenskulcsot használó alkalmazáskódra. A szegmenshelyek keresése további többletterhelést jelenthet.

• Tartományalapú stratégia. Könnyen megvalósítható, és jól működik a tartománylekérdezésekkel, mert azok gyakran több adatelemet kérhetnek le egyetlen szegmensből egyetlen művelet során. Ez a stratégia egyszerűbb adatkezelést kínál. Ha például egy adott régió felhasználói ugyanabban a szegmensben találhatók, a frissítések a helyi terhelés és az igényminta alapján ütemezhetők az egyes időzónákban. Ez a stratégia azonban nem biztosít optimális terheléselosztást a szegmensek között. A szegmensek újraegyensúlyozása nehéz feladat, és előfordulhat, hogy akkor sem oldja meg az egyenetlen terhelés problémáját, ha a tevékenységek többsége szomszédos szegmenskulcsokhoz kapcsolódik.

• Kivonatolási stratégia. Ez a stratégia nagyobb eséllyel teszi lehetővé az egyenletesebb adat- és terheléselosztást. A kérések továbbítása közvetlenül végezhető a kivonatolási függvény használatával. Nem kell leképezést fenntartani. Vegye figyelembe, hogy a kivonat kiszámítása többletterhelést okozhat. Emellett nehéz a szegmensek újraegyensúlyozása.

A leggyakoribb horizontális skálázási rendszerek a fent leírt megközelítések egyikét valósítják meg, figyelembe kell vennie azonban az alkalmazások üzleti követelményeit és az alkalmazások adathasználatának mintáit is. Például egy több-bérlős alkalmazásban:

• Az adatok horizontális skálázását végezheti számítási feladatok alapján. A kevéssé permanens bérlők adatait különálló szegmensekbe különítheti el. Ennek eredményeként növekedhet a többi bérlő adatelérésének sebessége.

• Az adatok horizontális skálázását végezheti a bérlők helye alapján. Egy adott földrajzi régióban található bérlők adatait biztonsági mentés és karbantartás céljából offline állapotba helyezheti az alacsony forgalmú időszakban, míg a többi régióban lévő bérlők adatai online és elérhetők maradnak a bérlők munkaidejében.

• A nagy értékű bérlők saját privát, nagy teljesítményű, könnyen betöltött szegmensekhez rendelhetők, míg az alacsonyabb értékű bérlők várhatóan sűrűbb, forgalmasabb szegmenseket osztanak meg.

• A nagyfokú adatelkülönítést és adatvédelmet igénylő bérlők adatai teljesen különálló kiszolgálón tárolhatók.

Skálázási és adatáthelyezési műveletek

Minden horizontális skálázási stratégia a horizontális leskálázás, a horizontális felskálázás, az adatáthelyezés és az állapotfenntartás kezelésének különböző képességeivel és összetettségi szintjével jár.

A keresési stratégia a skálázási és adatáthelyezési műveletek online vagy offline, felhasználói szinten való végrehajtását teszi lehetővé. A módszer felfüggeszt néhány vagy minden felhasználói tevékenységet (esetleg a csúcsidőn kívüli időszakokban), az adatokat az új virtuális partícióra vagy fizikai szegmensre helyezi át, módosítja a leképezéseket, érvényteleníti vagy frissíti az ezen adatokat tároló gyorsítótárakat, majd engedélyezi a felhasználói tevékenység folytatását. Az ilyen típusú működés gyakran központilag kezelhető. A keresési stratégia megköveteli, hogy az állapot rendkívül jól gyorsítótárazható és replikabarát legyen.

A tartományalapú stratégia némileg korlátozza a skálázási és adatáthelyezési műveleteket, amelyeket általában akkor kell végrehajtani, amikor az adattár egy része vagy egésze offline állapotban van, mert az adatokat fel kell osztani és egyesíteni kell a szegmensek között. Előfordulhat, hogy a szegmensek újraegyensúlyozása céljából végrehajtott adatáthelyezés nem oldja meg az egyenetlen terhelés problémáját, ha a tevékenységek többsége szomszédos szegmenskulcsokhoz vagy az ugyanabban a tartományban lévő adatazonosítókhoz kapcsolódik. A tartományalapú stratégiához bizonyos állapot fenntartására is szükség lehet a tartományok fizikai partíciókra való leképezéséhez.

A kivonatolási stratégia összetettebbé teszi a skálázási és adatáthelyezési műveleteket, mivel a partíciókulcsok a szegmenskulcsok vagy adatazonosítók kivonatai. A kivonatolási függvényből vagy a megfelelő leképezések biztosítása érdekében módosított függvényből kell meghatározni az egyes szegmensek új helyét. A kivonatolási stratégiához azonban nincs szükség állapot fenntartására.

Problémák és megfontolandó szempontok

A minta megvalósítása során az alábbi pontokat vegye figyelembe:

• A horizontális skálázás kiegészíti a particionálás többi formáját, például a függőleges particionálást és a funkcionális particionálást. Egy szegmens például tartalmazhat függőlegesen particionált entitásokat, egy funkcionális partíció pedig megvalósítható több szegmensként. További információ a particionálással kapcsolatban: Adatparticionálási útmutató.

• Tartsa fenn az egyensúlyt a szegmensek között, hogy mindegyik hasonló mértékű I/O-forgalmat kezeljen. Adatok beszúrásakor és törlésekor rendszeresen újra kell egyensúlyozni a szegmenseket az egyenletes eloszlás biztosítása és a kritikus pontok esélyének csökkentése érdekében. Az újraegyensúlyozás drága művelet lehet. Az újraegyensúlyozás szükségességének csökkentése érdekében a növekedést szem előtt tartva tervezzen: győződjön meg arról, hogy mindegyik szegmens elegendő szabad hellyel rendelkezik-e a várt mennyiségű módosítás kezeléséhez. Stratégiákat és szkripteket is ki kell fejlesztenie a szegmensek gyors újraegyensúlyozására, ha az szükségessé válik.

• Stabil adatokat használjon a szegmenskulcshoz. Ha a szegmenskulcs megváltozik, előfordulhat, hogy a kulcsnak megfelelő adatelemnek mozognia kell a szegmensek között, így növekszik a frissítési műveletek által végzett munka mennyisége. Ezért ne alapozza a szegmenskulcsot olyan információkra, amelyek változhatnak. Ehelyett nem változó vagy jellegükből adódóan kulcsot formáló attribútumokat keressen.

• Gondoskodjon arról, hogy a szegmenskulcsok egyediek legyenek. Kerülje például az automatikusan növekvő mezők szegmenskulcsként való használatát. Egyes rendszerekben az automatikusan létrehozott mezők nem koordinálhatók a szegmensek között, ami azt eredményezheti, hogy a különböző szegmensekben lévő elemek ugyanazt a szegmenskulcsot tartalmazzák.

  Problémákat okozhatnak az egyéb olyan mezők automatikusan növekvő értékei is, amelyek nem szegmenskulcsok. Ha például automatikusan növekvő mezőkkel hoz létre egyedi azonosítókat, akkor két különböző szegmensben lévő két különböző elemhez ugyanaz az azonosító lehet hozzárendelve.

• Előfordulhat, hogy nem lehet olyan szegmenskulcsot tervezni, amely megfelel az adatokra irányuló minden lehetséges lekérdezés követelményeinek. Az adatok horizontális skálázásával támogassa a leggyakrabban végrehajtott lekérdezéseket, és szükség esetén hozzon létre másodlagos indextáblákat azon lekérdezések támogatásához, amelyek a szegmenskulcs részét nem képező attribútumokon alapuló feltételek használatával kérdezik le az adatokat. További információ: indextábla minta.

• A csak egy szegmenst elérő lekérdezések hatékonyabbak, mint az adatokat több szegmensből lekérő lekérdezések, ezért ne valósítson meg olyan horizontális skálázási rendszert, amely azt eredményezi, hogy az alkalmazások a különböző szegmensekben tárolt adatokat egyesítő nagyszámú lekérdezést hajtanak végre. Ne feledje, hogy egyetlen szegmens több entitástípus adatait is tartalmazhatja. Érdemes lehet denormalizálni az adatokat, hogy a gyakran együtt lekérdezett kapcsolódó entitások (például az ügyfelek és az általuk kezdeményezett megrendelések adatai) ugyanazon a szegmensben legyenek az alkalmazások által végrehajtott különálló olvasások számának a csökkentéséhez.

  Ha az egyik szegmensben lévő entitás egy másik szegmensben tárolt entitásra hivatkozik, az első entitás sémájának részeként adja meg a második entitás szegmenskulcsát. Ez hozzájárulhat a szegmenseken található kapcsolódó adatokra hivatkozó lekérdezések teljesítményének a javításához.

• Ha egy alkalmazásnak az adatokat több szegmensből lekérő lekérdezéseket kell végrehajtania, lehet, hogy az adatok lekérhetők párhuzamos tevékenységek használatával. Erre példa az elosztott lekérdezés, ahol a rendszer több szegmens adatait kéri le párhuzamosan, majd egyetlen eredményben összesíti azokat. Ez a megközelítés azonban elkerülhetetlenül összetetté teszi a megoldások adatelérési logikáját.

• Sok alkalmazás esetén hatékonyabb lehet több kisméretű szegmens létrehozása, mint kevés nagyméretű használata, mert ez több lehetőséget kínál a terheléselosztáshoz. Ez akkor is hasznos lehet, ha várhatóan az egyik fizikai helyről egy másikra kell szegmenseket migrálnia. A kis szegmensek gyorsabban áthelyezhetők, mint a nagyok.

• Gondoskodjon róla, hogy az egyes szegmenstároló csomópontok erőforrásai elegendőek legyenek a skálázhatósági követelmények kezelésére az adatméret és a feldolgozási sebesség tekintetében. További információ: "Partíciók tervezése a méretezhetőséghez" című szakasz az adatparticionálási útmutatóban.

• Vegye fontolóra a referenciaadatok replikálását minden szegmensre. Ha egy szegmensből adatokat lekérő művelet statikus vagy lassan mozgó adatokra is hivatkozik ugyanazon lekérdezés részeként, adja hozzá ezeket az adatokat a szegmenshez. Az alkalmazás ezután könnyedén le tudja kérni a lekérdezés összes adatát anélkül, hogy további adatváltást kellene végrehajtania egy különálló adattárral.

  Ha a több szegmensben tárolt referenciaadatok megváltoznak, a rendszernek szinkronizálnia kell ezeket a változásokat minden szegmensben. A rendszer valamilyen fokú inkonzisztenciát tapasztalhat az ilyen szinkronizálás során. Ez esetben úgy kell megterveznie az alkalmazásokat, hogy képesek legyenek ennek kezelésére.

• Nehéznek bizonyulhat a hivatkozások integritásának és a szegmensek közötti konzisztenciának a fenntartása, ezért minimálisra kell csökkentenie a több szegmensben lévő adatokra hatással lévő műveletek számát. Ha egy alkalmazásnak több szegmensben található adatokat kell módosítania, mérje fel, hogy valóban szükség van-e az adatok teljes konzisztenciájára. Ehelyett egy, a felhőben gyakran alkalmazott megközelítés a végső konzisztencia megvalósítása. Az egyes partíciók adatainak frissítése külön történik, és az alkalmazáslogikának felelősséget kell vállalnia a frissítések mindegyikének sikeres befejezéséért, valamint egy végül konzisztensnek bizonyuló művelet futása során az adatok lekérdezéséből fakadó inkonzisztencia kezeléséért. A végül bekövetkező konzisztenciával kapcsolatos további információkat az adatkonzisztenciát ismertető szakaszban találja.

• Sok szegmens konfigurálása és kezelése kihívást jelenthet. Az olyan feladatokat, mint a monitorozás, biztonsági mentés, konzisztencia-ellenőrzés és naplózás, különálló, lehetőség szerint több helyen található szegmenseken és kiszolgálókon kell végezni. Ezek a feladatok valószínűleg megvalósíthatók szkriptekkel vagy más automatizálási megoldásokkal, azonban lehet, hogy ezek nem küszöbölik ki teljesen a további felügyeleti követelményeket.

• A szegmensek földrajzi helyhez köthetők, hogy az általuk tárolt adatok közel legyenek az adatokat használó alkalmazások példányaihoz. Ez a módszer jelentősen javíthatja a teljesítményt, azonban további szempontokat kell figyelembe venni olyan feladatok esetén, amelyeknek több, különböző helyeken található szegmenst kell elérniük.

Mikor érdemes ezt a mintát használni?

Akkor használja ezt a mintát, ha egy adattárat valószínűleg egy adott tárolócsomópont számára elérhető erőforrásokon túl kell skálázni, vagy amikor javítani szeretné a teljesítményt egy adattárban tapasztalható versengés csökkentésével.

Számítási feladatok tervezése

Az építészeknek értékelniük kell, hogyan használható a horizontális skálázási minta a számítási feladat kialakításában az Azure Well-Architected Framework pilléreiben foglalt célok és alapelvek kezelésére. Példa:

Mint minden tervezési döntésnél, fontolja meg az ezzel a mintával bevezethető többi pillér céljaival szembeni kompromisszumokat.

Példa

Fontolja meg egy olyan webhelyet, amely kiterjedt információgyűjteményt jelenít meg a világszerte közzétett könyvekről. Az ebben a számítási feladatban katalógusba foglalt lehetséges könyvek száma és a tipikus lekérdezési/használati minták ellentrafikálják egyetlen relációs adatbázis használatát a könyvadatok tárolásához. A számítási feladat tervezője úgy dönt, hogy több adatbázispéldányon szilánkokra szilánkozza az adatokat a szilánkkulcshoz tartozó statikus Nemzetközi Standard Könyvszám (ISBN) használatával. Pontosabban az ISBN ellenőrző számjegyét (0 –10) használják, mivel 11 lehetséges logikai szegmenst adnak meg, és az adatok meglehetősen kiegyensúlyozottak lesznek az egyes szegmensek között. Először is úgy döntenek, hogy a 11 logikai szegmenst három fizikai szegmens-adatbázisba helyezik. A keresési skálázási módszert használják, és a kulcs-kiszolgáló leképezési adatait egy szegmenstérkép-adatbázisban tárolják.

Keresési szegmenstérkép

A szegmensleképezési adatbázis a következő szegmensleképezési táblát és adatokat tartalmazza.

SELECT ShardKey, DatabaseServer
FROM BookDataShardMap

| ShardKey | DatabaseServer |
|----------|----------------|
|        0 | bookdbshard0   |
|        1 | bookdbshard0   |
|        2 | bookdbshard0   |
|        3 | bookdbshard1   |
|        4 | bookdbshard1   |
|        5 | bookdbshard1   |
|        6 | bookdbshard2   |
|        7 | bookdbshard2   |
|        8 | bookdbshard2   |
|        9 | bookdbshard0   |
|       10 | bookdbshard1   |

Példa webhelykódra – egyszeri szegmens-hozzáférés

A webhely nem ismeri a fizikai szegmens-adatbázisok számát (ebben az esetben három), sem a szegmenskulcs adatbázispéldányhoz leképező logikáját, de a webhely tudja, hogy a könyv ISBN-jének ellenőrző számjegyét szilánkkulcsnak kell tekinteni. A webhely írásvédett hozzáféréssel rendelkezik a szegmenstérkép-adatbázishoz, és írásvédett hozzáféréssel rendelkezik az összes szegmensadatbázishoz. Ebben a példában a webhely a Azure-alkalmazás szolgáltatás rendszer által felügyelt identitását használja, amely a webhelyet üzemelteti az engedélyezéshez, hogy a titkos kulcsok ne legyenek a kapcsolati sztring.

A webhely a következő kapcsolati sztring van konfigurálva egy appsettings.json fájlban, például ebben a példában vagy az App Service alkalmazásbeállításokon keresztül.

{
  ...
  "ConnectionStrings": {
    "ShardMapDb": "Data Source=tcp:<database-server-name>.database.windows.net,1433;Initial Catalog=ShardMap;Authentication=Active Directory Default;App=Book Site v1.5a",
    "BookDbFragment": "Data Source=tcp:SHARD.database.windows.net,1433;Initial Catalog=Books;Authentication=Active Directory Default;App=Book Site v1.5a"
  },
  ...
}

Ha elérhetőek a kapcsolati adatok a szegmenstérkép-adatbázishoz, a webhely által a számítási feladat adatbázis-szegmenskészletére végrehajtott frissítési lekérdezés példája az alábbi kódhoz hasonlóan fog kinézni.

...

// All data for this book is stored in a shard based on the book's ISBN check digit,
// which is converted to an integer 0 - 10 (special value 'X' becomes 10).
int isbnCheckDigit = book.Isbn.CheckDigitAsInt;

// Establish a pooled connection to the database shard for this specific book.
using (SqlConnection sqlConn = await shardedDatabaseConnections.OpenShardConnectionForKeyAsync(key: isbnCheckDigit, cancellationToken))
{
  // Update the book's Library of Congress catalog information
  SqlCommand cmd = sqlConn.CreateCommand();
  cmd.CommandText = @"UPDATE LibraryOfCongressCatalog
                         SET ControlNumber = @lccn,
                             ...
                             Classification = @lcc
                       WHERE BookID = @bookId";

  cmd.Parameters.AddWithValue("@lccn", book.LibraryOfCongress.Lccn);
  ...
  cmd.Parameters.AddWithValue("@lcc", book.LibraryOfCongress.Lcc);
  cmd.Parameters.AddWithValue("@bookId", book.Id);

  await cmd.ExecuteNonQueryAsync(cancellationToken);
}

...

Az előző példakódban, ha 978-8-1130-1024-6 volt, akkor isbnCheckDigit 6-nak kell lennie.book.Isbn A hívás OpenShardConnectionForKeyAsync(6) általában gyorsítótár-feltöltési megközelítéssel lett megvalósítva. Lekérdezi a kapcsolati sztring ShardMapDb azonosított szegmenstérkép-adatbázist, ha nem rendelkezik a 6. szilánkkulcs gyorsítótárazott szegmensadataival. Az alkalmazás gyorsítótárából vagy a szegmens-adatbázisból a bookdbshard2 érték kerül a BookDbFragment kapcsolati sztring helyéreSHARD. A készletezett kapcsolat létrejön (újra) a bookdbshard2.database.windows.net, a megnyitás és a hívókódhoz való visszatérés gombra. A kód ezután frissíti az adatbázispéldány meglévő rekordját.

Példa webhelykódra – több szegmenses hozzáférés

Ritka esetben a webhely közvetlen, horizontális skálázású lekérdezést igényel, az alkalmazás az összes szegmensben párhuzamos kirakott lekérdezést hajt végre.

...

// Retrieve all shard keys
var shardKeys = shardedDatabaseConnections.GetAllShardKeys();

// Execute the query, in a fan-out style, against each shard in the shard list.
Parallel.ForEachAsync(shardKeys, async (shardKey, cancellationToken) =>
{
  using (SqlConnection sqlConn = await shardedDatabaseConnections.OpenShardConnectionForKeyAsync(key: shardKey, cancellationToken))
  {
    SqlCommand cmd = sqlConn.CreateCommand();
    cmd.CommandText = @"SELECT ...
                          FROM ...
                         WHERE ...";

    SqlDataReader reader = await cmd.ExecuteReaderAsync(cancellationToken);

    while (await reader.ReadAsync(cancellationToken))
    {
      // Read the results in to a thread-safe data structure.
    }

    reader.Close();
  }
});

...

A horizontálisan megosztott lekérdezések alternatívájaként ebben a számítási feladatban külsőleg karbantartott indexet használhat az Azure AI Searchben, például helykereséshez vagy összetett navigációs funkciókhoz.

Szegmenspéldányok hozzáadása

A számítási feladatokért felelős csapat tisztában van azzal, hogy ha az adatkatalógus vagy annak egyidejű használata jelentősen nő, háromnál több adatbázispéldányra lehet szükség. A számítási feladatokért felelős csapat nem számít arra, hogy dinamikusan hozzáadja az adatbázis-kiszolgálókat, és a számítási feladatok leállási ideje megmarad, ha egy új szegmensnek online állapotba kell jönnie. Az új szegmenspéldány online állapotba helyezéséhez a meglévő szegmensekből az új szegmensbe kell áthelyezni az adatokat, valamint frissíteni kell a szegmenstérkép-táblát. Ez a meglehetősen statikus megközelítés lehetővé teszi, hogy a számítási feladat magabiztosan gyorsítótárazza a szegmenskulcs-adatbázis-leképezést a webhely kódjában.

Ebben a példában a szegmenskulcs logikája 11 maximális fizikai szegmensből álló korlátot mutat. Ha a számítási feladatokat végző csapat terhelésbecslési teszteket végez, és kiértékeli, hogy végül több mint 11 adatbázispéldányra lesz szükség, invazív módosítást kell végezni a szegmenskulcs logikáján. Ez a változás magában foglalja a kódmódosítások gondos tervezését és az adatok új kulcslogikára való migrálását.

SDK-funkciók

Ahelyett, hogy egyéni kódot írnál a szegmenskezeléshez és a lekérdezési útválasztáshoz az Azure SQL Database-példányokhoz, értékeld ki az Elastic Database ügyfélkódtárat. Ez a kódtár támogatja a szegmenstérkép-kezelést, az adatfüggő lekérdezések útválasztását és a szegmensek közötti lekérdezéseket c# és Java nyelven is.

Következő lépések

Az alábbi útmutatók segíthetnek a minta megvalósításakor:

• Adatkonzisztencia – Ismertető. A különböző szegmensek között elosztott adatok konzisztenciájának megőrzéséhez lehet szükséges. A cikk összefoglalja az elosztott adatok konzisztenciájának megőrzésével kapcsolatos problémákat, és bemutatja a különböző konzisztenciamodellek előnyeit és hátrányait.
• Adatparticionálási útmutató. Az adattárak horizontális skálázása további problémákat vethet fel. Ez az útmutató az adattáraknak a skálázhatóság növelése, a versengés csökkentése és a teljesítmény optimalizálása érdekében a felhőben történő particionálásával kapcsolatos problémákat ismerteti.

Kapcsolódó erőforrások

A minta megvalósításakor az alábbi minták is relevánsak lehetnek:

• Index Table minta. A lekérdezések néha nem támogathatók teljes mértékben pusztán a szegmenskulcs kialakításának segítségével. Lehetővé teszi, hogy az alkalmazások gyorsan kérjenek le adatokat egy nagy adattárból a szegmenskulcstól eltérő kulcs megadásával.
• Tényleges táblán alapuló nézet minta. Bizonyos lekérdezési műveletek teljesítményének fenntartása érdekében célszerű materializált nézeteket létrehozni, amelyek egyesítik és összegzik az adatokat, különösen akkor, ha ezek az összegzett adatok a szegmensek között elosztott információkon alapulnak. Ismerteti, hogyan hozhatja létre és töltheti fel adatokkal ezeket a nézeteket.