Javaslatok adatparticionáláshoz

Cikk
11/15/2023

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

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

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

Ez az útmutató ismerteti azokat a javaslatokat, amelyekkel adatparticionálási stratégiát tervezhet az üzembe helyezhető adatbázis- és adattárolási technológia számára. Ez a stratégia segít javítani az adattulajdon megbízhatóságát.

Főbb tervezési stratégiák

Számos nagy léptékű megoldásban a partíciók az adatok megosztására szolgálnak, hogy azok külön kezelhetők és elérhetők legyenek. 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 mintával való megosztásához. A régebbi adatokat például olcsó adattárban archiválhatja. 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.

Feljegyzé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 különbözik az SQL Server táblaparticionálásától.

Az adatokat a következőre particionálhatja:

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 található, szinte határozatlan ideig skálázhatja a rendszert.
A teljesítmény javítása. Az adathozzáférési műveleteket minden partíción kisebb mennyiségű adat hajtja 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ékeny 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ása, a felügyeleti hatékonyság maximalizálása és a költségek minimalizálása érdekében. A felügyeleti, monitorozási, biztonsági mentési és visszaállítási stratégiákat és egyéb felügyeleti feladatokat például az egyes partíciók adatainak fontossága alapján határozhatja meg.
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 dokumentumadatbázisban. További információt az adattármodellek ismertetése című témakörben talál.
A rendelkezésre állás javítása. 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ókban is folytatódnak. Ez a szempont kevésbé releváns a szolgáltatásként felügyelt platform (PaaS) adattárak esetében, mivel beépített redundanciával rendelkeznek.

Válassza ki a megfelelő particionálási stratégiát

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, például ügyfélrendeléseket tartalmaz.
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 összesítése annak megfelelően történik, hogy a rendszer minden egyes kötött környezete hogyan használja fel az adatokat. 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.

Érdemes kombinálni ezeket a stratégiákat particionálási séma tervezésekor. 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 vízszintes particionálás vagy horizontális horizontális particionálás látható. 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 egyenletesebb legyen a szegmensek között.

A szegmenseknek nem kell azonos méretűnek lenniük. Sokkal fontosabb a kérések számának egyensúlyba hozása. Előfordulhat, hogy egyes szegmensek nagyok, de a szegmens minden elemében alacsony a hozzáférési műveletek száma. Előfordulhat, hogy más szegmensek kisebbek, de a szegmens minden egyes eleméhez gyakrabban fér hozzá. 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 partíciók közötti egyenletes elosztásához.

Válasszon egy skálázási kulcsot, amely minimalizálja a nagy szegmensek felosztását, a kis szegmensek nagyobb partíciókba való kombinálását vagy a séma módosítását. Ezek a műveletek időigényesek, és előfordulhat, hogy egy vagy több szegmenst offline állapotba kell helyeznie.

Ha a szegmensek replikálva vannak, 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 adatelkonytalanságok 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 használata a gyakran használt elemek beolvasásával kapcsolatos 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 egy elem 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észletszámot é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ó rendezett dátum külön partícióban van, mivel ezt a két elemet gyakran használják együtt.

Tekintse meg a függőleges 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 (részvényszint és utolsó rendelés dátuma). Az adatok lassú áthelyezése jó választás egy alkalmazás számára a memóriában való gyorsítótárazáshoz.
A bizalmas adatokat külön partíción, hozzáadott biztonsági vezérlőkkel tárolhatja.
A függőleges 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 oszloporientált adattárakhoz, például a HBase-hez és a Cassandra-hoz. Ha egy oszlopgyűjtemény adatai valószínűleg nem változnak, fontolja meg az SQL Server oszloptárolóinak használatát.

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 másik gyakori funkciója az írásvédett 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 elválasztja az ügyféladatoktól.

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, hogy az adatok el legyenek osztva a maximális méretezhetőség érdekében. Az adatokat azonban particionálással is el kell végeznie, hogy ne lépje 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:

Elemezze az alkalmazást az adathozzáférési minták, például az egyes lekérdezések által visszaadott eredményhalmaz mérete, a hozzáférés gyakorisága, az eredendő késés és a kiszolgálóoldali számítási feldolgozási követelmények megértéséhez. Sok esetben néhány fő entitás igényli a feldolgozási erőforrások többségét.
Ezzel az elemzéssel meghatározhatja a jelenlegi és jövőbeli méretezhető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. Vízszintes particionáláshoz válassza ki a megfelelő szegmenskulcsot az 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, szükség lehet a particionálási stratégia finomítására vagy az adatok további felosztására. 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 egy elemzés előre jelez. Előfordulhat, hogy újra 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 infrastruktúra-határok alapján osztanak ki erőforrásokat. Győződjön meg arról, hogy a kijelölt 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 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 a tárfiókok 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 tartalmaznia kell a teljes adatkészlet kis részét. 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ényekkel 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, a halmozott erőforrás-felhasználás jelentős lehet.
A lassú teljesítményt okozó adatok particionálása.
- Korlátozza az egyes partíciók méretét, hogy a lekérdezések válaszideje a célon belül maradjon.
- Ha vízszintes 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 tárolni az adatokat, amelyek földrajzilag közel vannak azokhoz az alkalmazásokhoz és felhasználókhoz, amelyek hozzáférnek azokhoz.
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, horizontális particionálást adhat hozzá. Az egyetlen particionálási stratégia általában megfelelő, de bizonyos esetekben hatékonyabb a két stratégia kombinálása.
A teljesítmény javítása érdekében futtassa párhuzamosan a lekérdezéseket a partíciók között.

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

Az alkalmazások rendelkezésre állásának javítása érdekében particionálási adatok. A particionálás biztosítja, hogy a teljes adathalmaz egyetlen meghibásodási ponttal se rendelkezzen, é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 fontosságú működési adatokat, például a naplófájlokat.

A kritikus adatokat magas rendelkezésre állású partíciókban tárolja, é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 el 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óadatokat tartalmazó partíciókról, mint a naplózási vagy nyomkövetési adatokat tartalmazó partíciókról.

Az egyes partíciók kezelése. Partíciók tervezése 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 is 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 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áskód optimalizálása partíciók használatára

A particionálás összetettebbé teszi a rendszer kialakítását és fejlesztését. Az adatok particionálása a rendszerterv alapvető része, még akkor is, ha a rendszer kezdetben csak egyetlen partíciót tartalmaz. Ha utógondolatként kezeli a particionálást, az kihívást jelent, mert már rendelkezik egy élő rendszerrel, amit fenn kell tartania. Az alábbiakat 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 a migrálás során továbbra is használni szeretnék a rendszert.

Bizonyos esetekben a particionálás nem fontos, mert a kezdeti adatkészlet kicsi, és egyetlen kiszolgáló könnyen kezelheti. Egyes számítási feladatok partíciók nélkül is el tudnak menni, de számos kereskedelmi rendszernek ki kell terjednie a felhasználók számának növekedésével.

Egyes kis adattárak a particionálás előnyeit is élvezhetik. Előfordulhat például, hogy egyidejűleg több száz ügyfél fér hozzá egy kis adattárhoz. Ha ebben a 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:

A partíciók közötti adathozzáférési műveletek minimalizálása. Próbálja meg egy partícióban tartani a leggyakoribb adatbázisműveletek adatait a partíciók közötti adathozzáférési műveletek minimalizálása érdekében. 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 több partíciót is le kell kérdeznie, 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 megközelítést, például ha az egyik lekérdezés eredményét a következő lekérdezésben használja.

Statikus referenciaadatok replikálás. Ha a lekérdezések viszonylag statikus referenciaadatokat, például irányítószámtáblákat vagy terméklistákat használnak, fontolja meg az adatok replikálását az összes partíción, hogy csökkentse a különböző partíciókban a különálló keresési műveleteket. Ez a megközelítés csökkentheti annak valószínűségét is, hogy a referenciaadatok gyakori adathalmazokká váljanak, és a teljes rendszerből nagy mennyiségű adat forgalmúvá váljon. 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 egy kulcson, majd egy idegen kulcson alapuló egymást követő lekérdezéseket hajt végre. Ehelyett érdemes replikálni a vonatkozó adatokat vagy megszüntetni azok normalizáltságát. Ha keresztpartíciós illesztésekre van szükség, futtassa a párhuzamos lekérdezéseket a partíciókon, és csatlakozzon az alkalmazáson belüli adatokhoz.

Végső konzisztencia támogatása. Annak kiértékelése, hogy az erős konzisztencia követelmény-e. Az elosztott rendszerek 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 a frissítések sikeres befejezését. Az alkalmazáslogika az adatok lekérdezéséből eredő inkonzisztenciákat is kezeli, miközben egy végül konzisztens művelet fut.

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 be 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 meg tudják adni a partíciót. Másrészt a vízszintes particionálás megnehezítheti az elemek elhelyezését, mivel minden szegmens ugyanazt a sémát használja. Egy tipikus megoldás egy olyan térkép karbantartása, amely az elemek szegmenshelyé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.

Időnként újraegyensúlyozza a szegmenseket. 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 implementálnak 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 particionálási rendszerek többsége 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. Ezek a feladatok magukban foglalják az adatok betöltését, az adatok biztonsági mentését és visszaállítását, az adatok átrendezését, valamint a rendszer megfelelő és hatékony működésének biztosítását.

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.
Adatok betöltése több partícióba, és új, más forrásokból származó adatok hozzáadása. 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 havonta archiválja és törölje az adatokat. 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 automatikusan megkísérelheti 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 forróvá válnak, ami túlzott versengéshez vezet. Vagy 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ókat két fázisban lehet újraegyensúlyozni:

Ú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ésekor, amelyet offline migrálásnak nevezünk. Az adattártól függően előfordulhat, hogy használat közben migrálja az 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 offlineként. A partíciókat írásvédettként jelölheti meg, hogy az alkalmazások az áthelyezés közben is elolvashassá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 hozása.
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 nem jelöli meg az eredeti partíciót offlineként. Az áttelepítési folyamat részletességétől függően , például elemek és szegmensek szerinti elemenként, az ügyfélalkalmazások adatelérési kódjának két helyen, az eredeti partíción és az új partíción kell olvasnia és írnia az adatokat.

Az Azure megkönnyítése

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 több SQL-adatbázisra kiterjedő szegmensekre. 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 metaadatai a benne található szegmenseket ismertetik. A szegmensek lehetnek egyetlen adatelem vagy egy olyan elemcsoport, amely ugyanazt a szegmenskulcsot használja. Egy több-bérlős alkalmazásban például a szegmenskulcs lehet a bérlőazonosító, és a bérlő összes adata ugyanabban a szegmensben lehet.

Az alkalmazások felelősek az adatkészletek 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ó rejtve van az SQL Database Rugalmas adatbázis funkciójának ügyfélkönyvtárában található API-k sorozata mögött, amelyek a Java és a .NET számára érhetők el.

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

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álást az adatok különböző régiókban lévő adatbázisokba való folyamatos másolására.

Másik lehetőségként az SQL Database vagy az Azure Data Factory SQL-adatszinkronizálás használatával replikálhatja a szegmenstérkép-kezelő adatbázisát régiók között. 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ényel prémium szintű 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 minden szegmens a saját szegmensében tartható.

Töltse le a diagram Visio-fájlját.
A tartomány-szegmenstérképek egy egybefüggő kulcsértékeket társítanak egy szegmenshez. Csoportosíthatja például a bérlők egy csoportjának adatait, mindegyik saját kulccsal, ugyanabban a szegmensben. Ez a séma olcsóbb, 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 szilánkokat ugyanabban a szegmensben is kombinálhatja, 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 használatával szegmenseket adhat hozzá és távolíthat el az adatmennyiség növekedésével és zsugorításával. Az ügyfélalkalmazások dinamikusan és transzparens módon 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. Emellett befolyásolhatja a szegmensek hozzáadásának vagy eltávolításának sebességét, vagy azt, hogy az adatokat a szegmensek között újra kell particionálásra végezni. Vegye figyelembe a következő szempontokat:

Csoportosítsa az ugyanabban a szegmensben együtt használt adatokat, és kerülje a több szegmensből származó adatokat elérő műveleteket. 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 az 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 rendszert tervezzen, amely nem rendelkezik függőségekkel a szegmensek között. Az adatbázis hivatkozási integritási korlátozásai, eseményindítói és tárolt eljárásai nem hivatkozhatnak egy másik objektumra.
Fontolja meg az adatok szegmensek közötti replikálását, ha olyan referenciaadatokkal rendelkezik, amelyeket a lekérdezések gyakran használnak. Ez a megközelítés szükségtelenné teszi az adatok adatbázisok közötti összekapcsolására. 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.
Használja ugyanazt a sémát ugyanazon szegmenstérképhez tartozó szegmensek esetében. Ezt az útmutatást az SQL Database nem kényszeríti ki, 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. Lehet, hogy el kell kivonatnia a szilánkkulcsokat. Ha szegmenseket helyez el földrajzilag, győződjön meg arról, hogy a kivonatolt kulcsok az adatokhoz hozzáférő felhasználók közelében tárolt szegmensekben tárolt szegmensekre vannak leképezve.

Partíció az Azure Blob Storage-ban

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. Lapblobok használata 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-tárfiók tárolójában van tárolva. 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 ki vannak osztva a rendszer terhelésével. A blobok több kiszolgálón is eloszthatók a hozzájuk való hozzáférés ská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 történő túlzott forgalomhoz vezethet. Megakadályozza a rendszer hatékony terheléselosztását. Ha például olyan napi műveletek vannak, amelyek egy blobobjektumot használnak időbélyeggel (például yyyy-mm-dd), a művelet összes forgalma egyetlen partíciókiszolgálóra kerül. Ehelyett egy háromjegyű kivonatot tartalmazó előtagot adjon meg a névnek. További információ: Partícióelnevezési konvenció.

Egyetlen blokk vagy lap írása atomi művelet, de a blokkokat, oldalakat vagy blobokat átfogó műveletek nem. Ha konzisztenciát szeretne biztosítani, amikor az írási műveleteket blokkok, lapok és blobok között hajtják végre, blobbérlet használatával vegye ki az írási zárolást.

Megfontolások

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 konzisztensen propagálásra kerülnek 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 fordulhatnak elő, 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 a partíciók közötti lekérdezésre van szükség, és a partíciók újraegyensúlyozása esetén, ha az adatok egyenetlenül nőnek.

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

Tekintse meg a javaslatok teljes készletét.

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

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

Javaslatok adatparticionáláshoz

Főbb tervezési stratégiák