Javaslatok adatparticionáláshoz

Cikk
11/15/2023

Az Azure Well-Architected Framework megbízhatósági ellenőrzőlistájára vonatkozó javaslatra vonatkozik:

RE:06	Implementáljon egy időben és megbízható skálázási stratégiát az alkalmazás, az adatok és az infrastruktúra szintjén.

Kapcsolódó útmutató:Skálázás

Ez az útmutató az üzembe helyezhető adatbázis- és adattárolási technológia adatparticionálási stratégiájának kialakítására vonatkozó javaslatokat ismerteti. Ez a stratégia segít az adattulajdon megbízhatóságának javításában.

Kulcsfontosságú tervezési stratégiák

Számos nagy léptékű megoldásban a partíciók az adatok felosztására szolgálnak, így azok külön kezelhetők és elérhetők. Az adatok particionálása javítja a méretezhetőséget, csökkenti a versengést és optimalizálja a teljesítményt. Adatparticionálás implementálása az adatok használati minta szerinti elosztásához. Archiválhatja például a régebbi adatokat olcsó adattárban. Gondosan válassza ki a particionálási stratégiát az előnyök maximalizálása és a kedvezőtlen hatások minimalizálása érdekében.

Megjegyzés

Ebben a cikkben a particionálás kifejezés alatt az adatok külön adattárakba való fizikai felosztásának folyamatát értjük. Ez eltér SQL Server táblaparticionálástól.

Miért kell particionálni az adatokat?

A skálázhatóság javítása. Ha egyetlen adatbázisrendszert skáláz fel, az adatbázis végül eléri a fizikai hardverkorlátot. Ha több partícióra osztja az adatokat, és mindegyik partíció külön kiszolgálón van üzemeltetve, szinte határozatlan időre horizontálisan felskálázhatja a rendszert.
A teljesítmény javítása. Az adathozzáférési műveletek minden partíción kisebb mennyiségű adaton hajthatók végre a nem particionált adatokhoz képest. Az adatok particionálása a rendszer hatékonyabbá tétele érdekében. Az egyszerre több partíciót érintő műveletek párhuzamosan futtathatóak.
A biztonság javítása. Bizonyos esetekben a bizalmas és nem érzéketlen adatokat különböző partíciókra különítheti el, és különböző biztonsági vezérlőket alkalmazhat a bizalmas adatokra.
A működési rugalmasság megteremtése. Az adatok particionálhatók a műveletek finomhangolásához, a felügyeleti hatékonyság maximalizálásához és a költségek minimalizálásához. Definiálhat például felügyeleti, figyelési, biztonsági mentési és visszaállítási stratégiákat, valamint egyéb felügyeleti feladatokat az egyes partíciók adatainak fontossága alapján.
A használati mintának megfelelő adattárak használata. Az egyes partíciókat különböző típusú adattárakban helyezheti üzembe az adattár által kínált költségek és beépített funkciók alapján. Például nagy bináris adatokat tárolhat blobtárolóban, és strukturált adatokat tárolhat egy dokumentum-adatbázisban. További információ: Az adattármodellek ismertetése.
A rendelkezésre állás javítása. Az egyetlen meghibásodási pont elkerülése érdekében több kiszolgálón is elkülönítheti az adatokat. Ha egy példány meghibásodik, csak az abban a partícióban lévő adatok nem érhetők el. A műveletek más partíciókon folytatódnak. Ez a szempont kevésbé releváns a szolgáltatásként nyújtott felügyelt platform (PaaS) adattárai esetében, mivel beépített redundanciával rendelkeznek.

Partíciók tervezése

Az adatok particionálásának három tipikus stratégiája van:

Horizontális particionálás (vagy más néven horizontális skálázás). Ebben a stratégiában minden partíció külön adattár, de minden partíció ugyanazzal a sémával rendelkezik. Minden partíciót szegmensnek nevezünk, és az adatok egy részhalmazát tartalmazza, például ügyfélrendelések halmazát.
Vertikális particionálás. Ebben a stratégiában mindegyik partíció az adattárban tárolt elemek mezőinek egy alhalmazát tartalmazza. A mezők a használati mintáik alapján vannak felosztva. Például a gyakran használt mezők az egyik, a kevésbé gyakran használtak egy másik partícióba kerülhetnek.
Funkcionális particionálás. Ebben a stratégiában az adatok a rendszer minden egyes kötött környezetének adatai alapján vannak összesítve. Egy e-kereskedelmi rendszer például az egyik partícióban tárolhatja a számlaadatokat, a termékleltár adatait pedig egy másikban.

Particionálási séma tervezésekor érdemes lehet kombinálni ezeket a stratégiákat. Például az adatokat először feloszthatja szegmensekre, majd az egyes szegmensekben lévő adatokat vertikálisan tovább particionálhatja.

Horizontális particionálás

Az alábbi képen egy példa látható a horizontális particionálásra vagy horizontális skálázásra. Ez a példa a termékleltár adatait a termékkulcson alapuló szegmensekre osztja. Minden egyes szegmens a szegmenskulcsok betűrend szerint egybefüggő tartományát (A–G és H–Z) tartalmazza. Horizontális skálázás esetén a terhelés több számítógépre oszlik, ami csökkenti a versengést és javítja a teljesítményt.

A legfontosabb tényező a választott horizontális skálázási kulcs. A rendszer beüzemelését követően a kulcs nehezen módosítható. A kulcsnak biztosítania kell az adatok particionálását, hogy a számítási feladat a lehető leg egyenletesen elosztható legyen a szegmensek között.

A szegmenseknek nem kell azonos méretűnek lenniük. A kérések számának egyensúlyba hozása fontosabb. Egyes szegmensek nagyok lehetnek, de a szegmens minden egyes eleme kevés hozzáférési műveletből áll. Más szegmensek kisebbek lehetnek, de a szegmens minden eleme gyakrabban érhető el. Azt is fontos biztosítani, hogy egyetlen szegmens ne lépje túl az adattár kapacitási és feldolgozási erőforrásainak méretezési korlátait.

Kerülje a gyakori elérésű partíciók létrehozását, amelyek hatással lehetnek a teljesítményre és a rendelkezésre állásra. Ha például egy ügyfél nevének első betűjét használja, az kiegyensúlyozatlan eloszlást hozhat létre, mivel egyes betűk gyakoribbak, mint mások. Ehelyett használjon ügyfél-azonosító kivonatot az adatok egyenletes elosztásához a partíciók között.

Válasszon egy horizontális skálázási kulcsot, amely minimálisra csökkenti a nagy szegmensek felosztásának, a kis szegmensek nagyobb partíciókra való egyesítésének vagy a séma módosításának szükségességét. Ezek a műveletek időigényesek, és előfordulhat, hogy egy vagy több szegmens offline állapotba helyezését igénylik.

Szegmensek replikálása esetén a replikák egy részét online állapotban tarthatja, míg mások felosztása, egyesítése vagy újrakonfigurálása történik. A rendszer azonban korlátozhatja az újrakonfigurálás során végrehajtható műveleteket. Előfordulhat például, hogy a replikákban lévő adatok írásvédettként vannak megjelölve az adatkonkonsztenciák elkerülése érdekében.

További információ: Horizontális skálázási minta.

Vertikális particionálás

A vertikális particionálás leggyakoribb felhasználási célja a gyakran használt elemek beolvasásával járó I/O- és teljesítményköltségek csökkentése. Az alábbi képen egy példa látható a függőleges particionálásra. Ebben a példában az elemek különböző tulajdonságai különböző partíciókban vannak tárolva. Az egyik partíció a gyakrabban elért adatokat tartalmazza, beleértve a termék nevét, leírását és árát. Egy másik partíció készletadatokat tartalmaz, beleértve a készletek számát és az utolsó megrendelt dátumot.

Ebben a példában az alkalmazás rendszeresen lekérdezi a termék nevét, leírását és árát, amikor megjeleníti a termék részleteit az ügyfeleknek. A készletszám és az utolsó rendelés dátuma külön partícióban van, mivel ezt a két elemet gyakran használják együtt.

Tekintse meg a vertikális particionálás alábbi előnyeit:

A viszonylag lassan mozgó adatokat (terméknév, leírás és ár) elkülönítheti a dinamikusabb adatoktól (készletszint és utolsó rendelés dátuma). Az adatok lassú áthelyezése jó választás az alkalmazások számára a memóriában való gyorsítótárazáshoz.
A bizalmas adatokat külön partíción tárolhatja, további biztonsági vezérlőkkel.
A vertikális particionálás csökkentheti a szükséges egyidejű hozzáférés mennyiségét.

A vertikális particionálás az entitások szintjén működik a tárolóban, részlegesen normalizálja az entitásokat, és széles elemekből keskeny elemekké bontja le azokat. Ideális az olyan oszloporientált adattárakhoz, mint a HBase és a Cassandra. Ha egy oszlopgyűjtemény adatai valószínűleg nem változnak, fontolja meg az oszloptárolók használatát SQL Server.

Funkcionális particionálás

Ha egy alkalmazás minden különálló üzleti területén azonosítható egy határos környezet, a funkcionális particionálás javíthatja az elkülönítést és az adathozzáférési teljesítményt. A funkcionális particionálás egy másik gyakori felhasználási célja az írási-olvasási adatok és az írásvédett adatok elkülönítése. Az alábbi képen a funkcionális particionálás áttekintése látható, amely a leltáradatokat az ügyféladatoktól elkülönítve tartalmazza.

Ez a particionálási stratégia csökkentheti az adatelérési versengést a rendszer egyes részei között.

Partíciók tervezése a méretezhetőség érdekében

Fontos figyelembe venni az egyes partíciók méretét és számítási feladatait. Egyensúlyozza ki őket úgy, hogy az adatok el legyenek osztva a maximális méretezhetőség érdekében. Ugyanakkor particionálja is az adatokat, hogy azok ne lépik túl egyetlen partíciótároló skálázási korlátait.

Kövesse az alábbi lépéseket, amikor partíciókat tervez a méretezhetőség érdekében:

Az alkalmazás elemzésével megismerheti az adathozzáférési mintákat, például az egyes lekérdezések által visszaadott eredményhalmaz méretét, a hozzáférés gyakoriságát, az eredendő késést és a kiszolgálóoldali számítási feldolgozási követelményeket. Sok esetben néhány fő entitás igényli a feldolgozási erőforrások nagy részét.
Ezzel az elemzéssel meghatározhatja a jelenlegi és jövőbeli skálázhatósági célokat, például az adatméretet és a számítási feladatot. Ezután ossza el az adatokat a partíciók közt a skálázhatósági célok teljesítéséhez. A horizontális particionáláshoz válassza ki a megfelelő szegmenskulcsot a egyenletes elosztás biztosításához. További információ: Horizontális skálázási minta.
Győződjön meg arról, hogy minden partíció rendelkezik elegendő erőforrással az adatméret és az átviteli sebesség skálázhatósági követelményeinek kezeléséhez. Az adattártól függően az egyes partíciókra korlátozható a tárterület, a feldolgozási teljesítmény vagy a hálózati sávszélesség. Ha a követelmények valószínűleg túllépik ezeket a korlátokat, előfordulhat, hogy finomítania kell a particionálási stratégiát, vagy fel kell osztania az adatokat. Előfordulhat, hogy két vagy több stratégiát kell kombinálnia.
Monitorozza a rendszert annak ellenőrzéséhez, hogy az adatok a várt módon oszlanak-e el, és hogy a partíciók képesek-e kezelni a terhelést. A tényleges használat nem mindig egyezik meg azzal, amit az elemzés előre jelez. Előfordulhat, hogy újra ki kell egyensúlyoznia a partíciókat, vagy újra kell terveznie a rendszer egyes részeit a szükséges egyensúly eléréséhez.

Egyes felhőkörnyezetek az infrastruktúra határai alapján foglalnak le erőforrásokat. Győződjön meg arról, hogy a kiválasztott határ korlátai elegendő helyet biztosítanak az adatmennyiség, az adattárolás, a feldolgozási teljesítmény és a sávszélesség várható növekedéséhez.

Ha például az Azure Table Storage-t használja, az egyetlen partíció által egy adott időszakban kezelhető kérések mennyisége korlátozott. További információ: Standard szintű tárfiókok méretezhetőségi és teljesítménycéljai. Az elfoglalt szegmensek több erőforrást igényelhetnek, mint amennyit egyetlen partíció képes kezelni. Előfordulhat, hogy újra kell particionolnia a szegmenst a terhelés szétosztásához. Ha ezeknek a tábláknak a teljes mérete vagy átviteli sebessége meghaladja egy tárfiók kapacitását, előfordulhat, hogy több tárfiókot kell létrehoznia, és el kell osztania a táblákat ezeken a fiókokon.

Partíciók tervezése a lekérdezési teljesítményhez

A lekérdezési teljesítményt kis adathalmazok használatával és párhuzamos lekérdezések futtatásával növelheti. Minden partíciónak a teljes adathalmaz kis részét kell tartalmaznia. A mennyiség csökkenésével javulhat a lekérdezések teljesítménye. A particionálás azonban nem alternatíva a megfelelő adatbázis-kialakítás és -konfiguráció helyett. Győződjön meg arról, hogy implementálja a szükséges indexeket.

Kövesse az alábbi lépéseket, amikor partíciókat tervez a lekérdezési teljesítményhez:

Vizsgálja meg az alkalmazás követelményeit és teljesítményét.
- Üzleti követelmények használatával határozza meg a kritikus lekérdezéseket, amelyeknek mindig gyorsan kell végrehajtaniuk.
- Monitorozza a rendszert a lassan végrehajtott lekérdezések azonosításához.
- Határozza meg a leggyakrabban végrehajtott lekérdezéseket. Még ha egyetlen lekérdezés is minimális költséggel rendelkezik, az összesített erőforrás-felhasználás jelentős lehet.
Particionálja a lassú teljesítményt okozó adatokat.
- Korlátozza az egyes partíciók méretét, hogy a lekérdezések válaszideje a célon belül maradjon.
- Ha horizontális particionálást használ, úgy tervezheti meg a szegmenskulcsot, hogy az alkalmazás könnyen kiválaszthassa a megfelelő partíciót. Ez a specifikáció megakadályozza, hogy a lekérdezés minden partíciót beolvasson.
- Mérlegelje a partíciók elhelyezését. Próbáljon meg olyan partíciókban tartani az adatokat, amelyek földrajzilag közel vannak az azokhoz hozzáférő alkalmazásokhoz és felhasználókhoz.
Ha egy entitás átviteli sebességre és lekérdezési teljesítményre vonatkozó követelményekkel rendelkezik, használja az entitáson alapuló funkcionális particionálást. Ha ez a foglalás továbbra sem felel meg a követelményeknek, hozzáadhat horizontális particionálást. Az egyetlen particionálási stratégia általában megfelelő, de bizonyos esetekben hatékonyabb mindkét stratégia kombinálása.
Futtassa párhuzamosan a lekérdezéseket a partíciók között a teljesítmény javítása érdekében.

Partíciók tervezése rendelkezésre álláshoz

Az alkalmazások rendelkezésre állásának javítása érdekében particionálja az adatokat. A particionálás biztosítja, hogy a teljes adatkészlet ne rendelkezzen egyetlen meghibásodási ponttal, és önállóan kezelheti az adathalmaz egyes részhalmazait.

Vegye figyelembe az alábbi tényezőket, amelyek befolyásolják a rendelkezésre állást:

Határozza meg az adatok kritikusságát. Azonosítsa a kritikus üzleti adatokat, például a tranzakciókat és a kevésbé kritikus működési adatokat, például a naplófájlokat.

Tárolja a kritikus adatokat a magas rendelkezésre állású partíciókban, és hozzon létre egy megfelelő biztonsági mentési tervet.
Külön felügyeleti és monitorozási eljárásokat hozhat létre a különböző adathalmazokhoz.
Helyezze az azonos kritikussági szintű adatokat ugyanabban a partícióban, hogy ugyanazon a gyakoriságon lehessen biztonsági másolatot készíteni róla. Előfordulhat például, hogy gyakrabban kell biztonsági másolatot készítenie a tranzakciós adatokat tartalmazó partíciókról, mint a naplózási vagy nyomkövetési adatokat tartalmazó partíciókról.

Egyéni partíciók kezelése. Tervezzen partíciókat a független felügyelet és karbantartás támogatására. Ez a gyakorlat számos előnnyel jár, például:

Ha egy partíció meghibásodik, önállóan helyreállítható anélkül, hogy más partíciók adataihoz hozzáférő alkalmazások kellenek.
Az adatok földrajzi terület szerinti particionálása lehetővé teszi, hogy az ütemezett karbantartási feladatok csúcsidőn kívül történjenek minden egyes helyen. Győződjön meg arról, hogy a partíciók nem olyan nagyok, hogy megakadályozzák a tervezett karbantartás befejezését ebben az időszakban.

Kritikus adatok replikálása partíciók között. Ez a stratégia javítja a rendelkezésre állást és a teljesítményt, de konzisztenciaproblémákat is okozhat. Időbe telik a módosítások szinkronizálása minden replikával. A szinkronizálás során a különböző partíciók különböző adatértékeket tartalmaznak.

Alkalmazáskialakítási szempontok

A particionálás összetettebbé teszi a rendszer kialakítását és fejlesztését. Az adatok particionálása a rendszer kialakításának alapvető része, még akkor is, ha a rendszer kezdetben csak egyetlen partíciót tartalmaz. Ha a particionálást utógondolatként kezeli, az kihívást jelent, mert már rendelkezik egy élő rendszerrel, amit fenn kell tartania. A következőket teheti:

Módosítania kell az adathozzáférési logikát.
Nagy mennyiségű meglévő adatot kell migrálnia, hogy eloszthassa azokat a partíciók között.
Problémákba ütközhet, mert a felhasználók várhatóan továbbra is használni szeretnék a rendszert a migrálás során.

Bizonyos esetekben a particionálás nem fontos, mert a kezdeti adatkészlet kicsi, és egyetlen kiszolgáló könnyen képes kezelni. Egyes számítási feladatok partíciók nélkül is használhatók, de számos kereskedelmi rendszernek a felhasználók számának növekedésével kell bővülnie.

Egyes kis adattárak esetében a particionálás is előnyös. Előfordulhat például, hogy egyidejűleg több száz ügyfél fér hozzá egy kis adattárhoz. Ha ilyen helyzetben particionálja az adatokat, az segíthet csökkenteni a versengést és javítani az átviteli sebességet.

Az adatparticionálási sémák kialakításakor vegye figyelembe a következő szempontokat:

Minimalizálja a partíciók közötti adathozzáférési műveleteket. Próbálja meg egy partícióban tartani a leggyakoribb adatbázis-műveletek adatait, hogy minimalizálja a partíciók közötti adathozzáférési műveleteket. Több időt vehet igénybe a partíciók közötti lekérdezés, nem pedig egyetlen partíción belüli lekérdezés. Az egyik lekérdezéscsoport partícióinak optimalizálása azonban hátrányosan befolyásolhatja a többi lekérdezéskészletet. Ha a partíciók között kell lekérdezést végeznie, minimalizálja a lekérdezési időt párhuzamos lekérdezések futtatásával és az eredmények összesítésével az alkalmazásban. Bizonyos esetekben nem használhatja ezt a módszert, például ha az egyik lekérdezés eredményét használja a következő lekérdezésben.

Statikus referenciaadatok replikálása. Ha a lekérdezések viszonylag statikus referenciaadatokat, például irányítószámtáblákat vagy terméklistákat használnak, érdemes lehet ezeket az adatokat az összes partícióban replikálni, hogy csökkentse a különböző partíciókban végzett különálló keresési műveleteket. Ez a megközelítés annak a valószínűségét is csökkentheti, hogy a referenciaadatok gyakran használt adathalmazokká válnak, és a teljes rendszerről nagy mennyiségű adatforgalmat bonyolítanak le. A referenciaadatok módosításainak szinkronizálása további költségekkel jár.

A partíciók közötti illesztések minimalizálása. Ahol csak lehetséges, a vertikális és funkcionális partíciókban minimalizálja a hivatkozásintegritás-igényeket. Ezekben a sémákban az alkalmazás felelős a hivatkozási integritás fenntartásáért a partíciók között. Az adatokat több partíción összekapcsoló lekérdezések nem hatékonyak, mert az alkalmazás általában egymást követő lekérdezéseket hajt végre, amelyek egy kulcson, majd egy idegen kulcson alapulnak. Ehelyett érdemes replikálni a vonatkozó adatokat vagy megszüntetni azok normalizáltságát. Ha partíciók közötti illesztésekre van szükség, futtasson párhuzamos lekérdezéseket a partíciókon, és csatlakoztassa az adatokat az alkalmazáson belül.

Végső konzisztencia támogatása. Értékelje ki, hogy az erős konzisztencia követelmény-e. Az elosztott rendszerek egyik gyakori megközelítése a végleges konzisztencia megvalósítása. Az egyes partíciók adatai külön frissülnek, és az alkalmazáslogika biztosítja, hogy a frissítések sikeresen befejeződnek. Az alkalmazáslogika az adatok lekérdezéséből eredő inkonzisztenciákat is kezeli egy végül konzisztens művelet futtatásakor.

Mérlegelje, hogyan találják meg a lekérdezések a megfelelő partíciót. Ha egy lekérdezésnek az összes partíciót át kell vizsgálnia a szükséges adatok megkereséséhez, az jelentősen befolyásolja a teljesítményt, még akkor is, ha több párhuzamos lekérdezés fut. Függőleges és funkcionális particionálás esetén a lekérdezések megadják a partíciót. Másrészt a horizontális particionálás megnehezítheti az elemek megtalálását, mivel minden szegmens ugyanazzal a sémával rendelkezik. Egy tipikus megoldás egy olyan térkép fenntartása, amely az elemek szegmenseinek helyének keresésére szolgál. Implementálja ezt a térképet az alkalmazás horizontális skálázási logikájában. Az adattár akkor is fenntarthatja, ha az adattár támogatja a transzparens horizontális skálázást.

A szegmensek időszakos újraegyensúlyozása. A horizontális particionálással a szegmensek újraegyensúlyozása segíthet az adatok méret és számítási feladat szerinti egyenletes elosztásában. A szegmensek újraegyensúlyozása a hotspotok minimalizálása, a lekérdezési teljesítmény maximalizálása és a fizikai tárolási korlátozások megkerülése érdekében. Ez a feladat összetett, és gyakran egyéni eszközt vagy folyamatot igényel.

Partíciók replikálása. Replikálja az egyes partíciókat, hogy további védelmet biztosítson a hibák ellen. Ha egyetlen replika meghibásodik, a rendszer egy működő példányra irányítja a lekérdezéseket.

A méretezhetőség kiterjesztése egy másik szintre. Ha eléri valamely particionálási stratégia fizikai korlátait, érdemes lehet a skálázhatóságot egy másik szintre kiterjeszteni. Például ha a particionálás az adatbázis szintjén valósul meg, a partíciókat esetleg több adatbázisban szükséges elhelyezni vagy replikálni. Ha a particionálás már az adatbázis szintjén van, és fizikai korlátozások vannak érvényben, előfordulhat, hogy több üzemeltetési fiók partícióit kell megkeresnie vagy replikálnia.

Kerülje a több partícióban lévő adatokat használó tranzakciókat. Egyes adattárak tranzakciós konzisztenciát és integritást alkalmaznak az adatokat módosító műveletekhez, de csak akkor, ha az adatok egyetlen partíción találhatók. Ha több partíció tranzakciós támogatására van szüksége, implementálja azt az alkalmazáslogika részeként, mert a legtöbb particionálási rendszer nem nyújt natív támogatást.

Minden adattárhoz bizonyos üzemeltetési felügyeleti és monitorozási tevékenységeket is végezni kell. Ilyen feladat például az adatok betöltése, az adatok biztonsági mentése és visszaállítása, az adatok átrendezése, valamint a rendszer megfelelő és hatékony működésének biztosítása.

Mérlegelje az üzemeltetési felügyeletet befolyásoló alábbi tényezőket:

Az adatok particionálásakor hajtsa végre a megfelelő felügyeleti és üzemeltetési feladatokat. Ilyen feladatok lehetnek a biztonsági mentés és visszaállítás, az adatok archiválása, a rendszer monitorozása, valamint egyéb felügyeleti feladatok. A biztonsági mentési és visszaállítási műveletek során például nehéz lehet fenntartani a logikai konzisztenciát.
Adatokat tölthet be több partícióba, és új, más forrásokból származó adatokat adhat hozzá. Előfordulhat, hogy egyes eszközök és segédprogramok nem támogatják a horizontális adatműveleteket, például az adatok megfelelő partícióba való betöltését.
Adatok rendszeres archiválása és törlése. A partíciók túlzott növekedésének megakadályozása érdekében archiválja és törölje az adatokat havonta. Előfordulhat, hogy át kell alakítania az adatokat egy másik archív sémának megfelelően.
Keresse meg az adatintegritási problémákat. Érdemes lehet rendszeres folyamat futtatásával megkeresni az adatintegritási problémákat, például az egyik partícióban lévő adatokat, amelyek a hiányzó információkra hivatkoznak egy másikban. A folyamat megpróbálhatja automatikusan kijavítani ezeket a problémákat, vagy létrehozhat egy jelentést manuális felülvizsgálatra.

Partíciók újraegyensúlyozása

A rendszer kifejlettségével előfordulhat, hogy módosítania kell a particionálási sémát. Előfordulhat például, hogy az egyes partíciók aránytalan mennyiségű forgalmat kapnak, és gyakorivá válnak, ami túlzott versengéshez vezet. Vagy előfordulhat, hogy alábecsülte bizonyos partíciók adatmennyiségét, ami miatt a partíciók megközelítik a kapacitáskorlátokat.

Egyes adattárak, például az Azure Cosmos DB automatikusan újraegyensúlyozhatják a partíciókat. Más esetekben a partíciók két szakaszban egyensúlyozhatók újra:

Új particionálási stratégia meghatározása.
- Mely partíciókat kell felosztani vagy kombinálni?
- Mi az új partíciókulcs?
Adatok áttelepítése a régi particionálási sémából az új partíciókészletbe.

Előfordulhat, hogy a partíciókat elérhetetlenné kell tennie az adatok áthelyezése során, ezt nevezzük offline migrálásnak. Az adattártól függően előfordulhat, hogy használat közben migrál adatokat a partíciók között. Ezt a technikát online migrálásnak nevezzük.

Offline migrálás

Az offline migrálás csökkenti a versengés esélyét. Offline migrálás végrehajtása:

Jelölje meg a partíciót offline állapotúként. A partíciókat megjelölheti írásvédettként, így az alkalmazások az áthelyezés közben is olvashatják az adatokat.
Egyesítés felosztása és az adatok áthelyezése az új partíciókra.
Az adatok ellenőrzése.
Az új partíciók online állapotba helyezése.
Távolítsa el a régi partíciót.

Online migrálás

Az online migrálás összetettebb, de kevésbé zavaró az offline migráláshoz képest. A folyamat hasonló az offline migráláshoz, de az eredeti partíciót nem offlineként jelöli meg. A migrálási folyamat részletességétől függően , például elemek és szegmensenkénti szegmensek szerint, előfordulhat, hogy az ügyfélalkalmazások adatelérési kódjának két helyen, az eredeti partíción és az új partíción lévő adatokat kell olvasnia és írnia.

Azure-beli segítségnyújtás

Az alábbi szakaszok az Azure-szolgáltatásokban tárolt adatok particionálására vonatkozó javaslatokat ismertetik.

Partíció az Azure SQL Database-ben

Az egyes SQL-adatbázisokban tárolható adatok mennyisége korlátozott. A feldolgozási sebességet architekturális tényezők és az adatbázis által támogatott egyidejű kapcsolatok száma korlátozzák.

A rugalmas készletek támogatják az SQL-adatbázisok horizontális skálázását. Rugalmas készletek használatával particionálhatja az adatokat olyan szegmensekre, amelyek több SQL-adatbázis között oszlanak meg. Az adatmennyiség növekedésével és zsugorításával szegmenseket is hozzáadhat vagy eltávolíthat. A rugalmas készletek a terhelés adatbázisok közötti elosztásával is csökkenthetik a versengést.

Minden egyes szegmens egy SQL-adatbázisként van megvalósítva. A szegmensek több adathalmazt is tartalmazhatnak. Minden adatkészletet shardletnek nevezünk. Minden adatbázis rendelkezik a benne található szegmenseket leíró metaadatokkal. A shardlet lehet egyetlen adatelem vagy egy olyan elemcsoport, amely ugyanazt a szegmenskulcsot használja. Egy több-bérlős alkalmazásban például a shardletkulcs lehet a bérlő azonosítója, és a bérlő összes adata ugyanabban a szegmensben lehet.

Az alkalmazások felelősek az adathalmazok shardlet kulccsal való társításáért. Egy külön SQL-adatbázis szolgál globális szegmenstérkép-kezelőként. Ez az adatbázis tartalmazza a rendszer összes szegmensét és szegmensét. Az alkalmazás csatlakozik a szegmenstérkép-kezelő adatbázisához a szegmenstérkép másolatának lekéréséhez. Helyileg gyorsítótárazza a szegmenstérképet, és a térkép használatával irányítja az adatkéréseket a megfelelő szegmensbe. Ez a funkció a Java és a .NET számára elérhető SQL Database Elastic Database szolgáltatásának ügyfélkódtárában található API-k egy sorozata mögött van elrejtve.

További információ a rugalmas készletekről: Horizontális felskálázás SQL Database.

A késés csökkentése és a rendelkezésre állás javítása érdekében replikálhatja a globális szegmenstérkép-kezelő adatbázist. A prémium tarifacsomagokkal konfigurálhatja az aktív georeplikációt úgy, hogy folyamatosan másolja az adatokat a különböző régiókban lévő adatbázisokba.

Másik lehetőségként használhatja a SQL-adatszinkronizálás-t SQL Database vagy Azure Data Factory a szegmenstérkép-kezelő adatbázis régiók közötti replikálásához. Ez a replikációs forma rendszeres időközönként fut, és akkor megfelelőbb, ha a szegmenstérkép ritkán változik, és nem igényli a prémium szintet.

Az Elastic Database két sémát kínál az adatok shardletekre való leképezésére és a szegmenseken való eltárolására:

A listaszilánktérképek egyetlen kulcsot társítanak egy shardlethez. Például egy több-bérlős rendszerben az egyes bérlők adatai egy egyedi kulccsal lehetnek társítva, majd egy külön shardletben tárolhatók. Az elkülönítés garantálása érdekében az egyes szegmensek a saját szegmenseiken belül tárolhatók.

Töltse le a diagram Visio-fájlját .
A tartomány-szegmenstérképek folytonos kulcsértékeket társítanak egy shardlethez. Csoportosíthatja például a bérlők egy csoportjának adatait, mindegyiket saját kulccsal, ugyanabban a szegmensben. Ez a séma kevésbé költséges, mint egy lista szegmenstérképe, mivel a bérlők megosztják az adattárolást, de kevesebb elkülönítést biztosítanak.

A diagram Visio-fájljának letöltése

Egyetlen szegmens több szegmens adatait is tartalmazhatja. Például listás shardletek használatával több nem egymást követő shardlet adatait is tárolhatja egyetlen szegmensben. A tartományshardleteket és a listashardleteket is keverheti ugyanabban a szegmensben, de ezek kezelése különböző térképeken keresztül történik. Az alábbi ábrán ez a megközelítés látható:

Töltse le a diagram Visio-fájlját .

Rugalmas készletek esetén az adatok mennyiségének növekedésével és zsugorításával szegmenseket adhat hozzá és távolíthat el. Az ügyfélalkalmazások dinamikusan és átláthatóan hozhatnak létre és törölhetnek szegmenseket a szegmenstérkép-kezelőben. A szegmensek eltávolítása azonban egy destruktív művelet, amelyet követően a szegmensben lévő összes adatot törölni kell.

Ha egy alkalmazásnak fel kell osztania egy szegmenst két különálló szegmensre, vagy egyesítenie kell a szegmenseket, használja az egyesítési eszközt. Ez az eszköz Azure-webszolgáltatásként fut, és biztonságosan migrálja az adatokat a szegmensek között.

A particionálási séma jelentősen befolyásolhatja a rendszer teljesítményét. Ez hatással lehet a szegmensek hozzáadásának vagy eltávolításának sebességére, vagy az adatok szegmensek közötti újraparticionálására. Vegye figyelembe a következő szempontokat:

Csoportosítsa az ugyanabban a szegmensben együtt használt adatokat, és kerülje azokat a műveleteket, amelyek több szegmensből férnek hozzá az adatokhoz. A szegmensek önálló SQL-adatbázisok, és az adatbázisközi illesztéseket az ügyféloldalon kell végrehajtani, amikor a műveletek több szegmenshez férnek hozzá.

Bár SQL Database nem támogatja az adatbázisközi illesztéseket, rugalmas adatbázis-eszközökkel több szegmenses lekérdezéseket hajthat végre. A több szegmensből álló lekérdezések egyedi lekérdezéseket küldenek az egyes adatbázisoknak, és egyesítik az eredményeket.
Olyan rendszer tervezése, amely nem rendelkezik függőségekkel a szegmensek között. Az egyik adatbázisban található hivatkozási integritási korlátozások, eseményindítók és tárolt eljárások nem hivatkozhatnak egy másik objektumra.
Fontolja meg az adatok szegmensek közötti replikálását, ha olyan referenciaadatokkal rendelkezik, amelyeket gyakran használnak a lekérdezések. Ez a megközelítés kiküszöbölheti az adatok adatbázisok közötti összekapcsolására vonatkozó igényt. Ideális esetben az ilyen adatoknak statikusnak vagy lassan mozgónak kell lenniük a replikációs munka minimalizálása és az elavultság esélyének csökkentése érdekében.
Ugyanazt a sémát használja ugyanazon szegmenstérképhez tartozó szegmensek esetében. Ezt az útmutatót nem kényszeríti ki a SQL Database, de az adatkezelés és a lekérdezés összetett, ha minden szegmens más sémával rendelkezik. Ehelyett hozzon létre különálló szegmenstérképeket az egyes sémákhoz. A különböző szegmensekhez tartozó adatokat ugyanabban a szegmensben tárolhatja.
Az adatokat ugyanabban a szegmensben tárolhatja, vagy végleges konzisztenciát valósíthat meg, ha az üzleti logikának tranzakciókat kell végrehajtania. A tranzakciós műveletek csak a szegmensekben lévő adatok esetében támogatottak, a szegmensek között nem. A tranzakciók a szegmensekre is kiterjedhetnek, ha ugyanahhoz a szegmenshez tartoznak.
Helyezze a szegmenseket azokhoz a felhasználókhoz, akik hozzáférnek az ezekben a szegmensekben lévő adatokhoz. Ezzel a stratégiával csökkenthetők a késések.
Kerülje a rendkívül aktív és viszonylag inaktív szegmensek kombinációját. Próbálja a terhelést egyenletesen elosztani a szegmensek között. Előfordulhat, hogy el kell kivonatnia a horizontálisan skálázási kulcsokat. Ha georedundáns szegmenseket keres, győződjön meg arról, hogy a kivonatolt kulcsok olyan szegmensekben tárolt szegmensekre vannak leképezve, amelyek az adatokhoz hozzáférő felhasználók közelében vannak tárolva.

Partíció Azure Blob Storage

A Blob Storage használatával nagy bináris objektumokat tárolhat. Használjon blokkblobokat olyan helyzetekben, amelyek nagy mennyiségű adat gyors feltöltését vagy letöltését igénylik. Lapblobokat használjon olyan alkalmazásokhoz, amelyek nem soros, hanem véletlenszerű hozzáférést igényelnek az adatok egyes részeihez.

Minden blokkblob vagy lapblob egy Azure Storage-fiók tárolójában található. Tárolók használatával csoportosíthatja az azonos biztonsági követelményekkel rendelkező kapcsolódó blobokat. A csoportosítás nem fizikai, hanem logikai alapon történik. A tárolókon belül minden egyes blob egyedi névvel rendelkezik.

A blob partíciókulcsa a fiók neve, a tároló neve és a blob neve. A partíciókulcs az adatok tartományokba való particionálására szolgál. Ezek a tartományok elosztott terhelést jelentenek a rendszerben. A blobok több kiszolgálón is eloszthatók a hozzájuk való hozzáférés vertikális felskálázásához. Egyetlen blobot csak egyetlen kiszolgáló tud kiszolgálni.

Ha az elnevezési séma időbélyegeket vagy numerikus azonosítókat használ, az egy partícióra irányuló túlzott forgalomhoz vezethet. Megakadályozza, hogy a rendszer hatékonyan kiegyensúlyozza a terhelést. Ha például napi műveletekkel rendelkezik, amelyek egy blobobjektumot használnak időbélyeggel (például ééé-hh-nd), a művelet összes forgalma egyetlen partíciókiszolgálóra kerül. Ehelyett előtagként adja meg a nevet egy háromjegyű kivonattal. További információ: Partícióelnevezési konvenció.

Egyetlen blokk vagy oldal írásának műveletei atomiak, de a blokkokra, oldalakra vagy blobokra kiterjedő műveletek nem. Ha konzisztenciát kell biztosítania a blokkok, lapok és blobok írási műveleteinek végrehajtásakor, blobbérlet használatával vegye ki az írási zárolást.

Megfontolandó szempontok

Az adatparticionálás olyan kihívásokat és összetettségeket mutat be, amelyeket figyelembe kell vennie.

A partíciók közötti adatszinkronizálás kihívást jelenthet. Győződjön meg arról, hogy az egyik partíció frissítései vagy módosításai időben és konzisztens módon vannak propagálva a többi partícióra.
A feladatátvételi és vészhelyreállítási folyamatok összetettek lesznek, ha több partíció biztonsági mentését és visszaállítását kell koordinálnia. Adatintegritási problémák akkor merülhetnek fel, ha egyes partíciók vagy biztonsági másolataik sérültek vagy nem érhetők el.
Az adatparticionálás hatással lehet a teljesítményre és a megbízhatóságra, ha partíciók közötti lekérdezésre van szükség, és ha az adatok egyenetlenül nőnek, újraegyensúlyozhatja a partíciókat.

Megbízhatósági ellenőrzőlista

Tekintse meg a javaslatok teljes készletét.

Megbízhatósági ellenőrzőlista

Javaslatok adatparticionáláshoz