Adatparticionálási útmutató

Azure Blob Storage

Számos nagy léptékű megoldásban az adatok partíciókra vannak osztva, amelyek külön kezelhetők és érhetők el. A particionálás javíthatja a skálázhatóságot, csökkentheti a versengést és optimalizálhatja a teljesítményt. Egy olyan mechanizmust is kínálhat, amellyel az adatokat fel lehet osztani a használati minták mentén. Például a régebbi adatok olcsóbb adattárolókban archiválhatók.

A particionálási stratégiát azonban gondosan kell kiválasztani az előnyök maximalizálása érdekében, a káros hatások minimalizálása mellett.

Megjegyzés:

Ebben a cikkben az particionálási kifejezés azt jelenti, hogy az adatok fizikailag külön adattárakba oszthatóak. Ez nem ugyanaz, mint SQL Server tábla particionálása.

Miért érdemes adatokat particionálni?

• Skálázhatóság javítása. Ha egyetlen adatbázisrendszert skáláz fel, az végül eléri a fizikai hardverkorlátot. Ha több partícióra osztja az adatokat, és mindegyik külön kiszolgálón található, szinte határozatlan ideig skálázhatja fel a rendszert.

• Javítja a teljesítményt. Az egyes partíciók adathozzáférési műveletei kisebb mennyiségű adaton keresztül történnek. A megfelelő módon végzett particionálás hatékonyabbá teheti a rendszert. Egynél több partíciót érintő műveletek párhuzamosan is futtathatók.

• 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.

• Működési rugalmasság biztosítása. A particionálás számos lehetőséget kínál a műveletek finomhangolására, a felügyeleti hatékonyság maximalizálására és a költségek minimalizálására. Az egyes partíciók adatainak fontossága alapján például különböző stratégiákat határozhat meg a felügyeleti, monitorozási, biztonsági mentési és visszaállítási, valamint egyéb felügyeleti feladatokhoz.

• Hasonlítsa össze az adattárat a használati mintával. A particionálás lehetővé teszi, hogy minden partíció más típusú adattárban legyen üzembe helyezve a költségek és az adattár által kínált beépített funkciók alapján. A nagy bináris adatok például blobtárolóban tárolhatók, míg strukturáltabb adatok tárolhatók egy dokumentumadatbázisban. További információ: A megfelelő adattár kiválasztása.

• A rendelkezésre állás javítása. Az adatok több kiszolgáló közötti elkülönítése elkerüli az egyetlen meghibásodási pontot. Ha egy példány meghibásodik, csak az abban a partícióban lévő adatok nem érhetők el. A más partíciókon végzett műveletek folytathatók. A szolgáltatásként felügyelt platform (PaaS) adattárai esetében ez a szempont kevésbé releváns, mivel ezek a szolgáltatások beépített redundanciával vannak kialakítva.

Partíciók tervezése

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

• Horizontális felosztás (más néven darabolá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 adott részhalmazát tartalmazza, például egy adott ügyfélcsoport összes megrendelését.

• Függőleges particionálás. Ebben a stratégiában minden partíció az adattárban lévő elemek mezőinek egy részét tartalmazza. A mezők a használati mintájuknak megfelelően vannak elosztva. Előfordulhat például, hogy a gyakran elért mezők egy függőleges partícióban helyezkednek el, míg a kevésbé gyakran elértek egy másikban.

• Funkcionális particionálás. Ebben a stratégiában az adatokat a rendszer minden egyes határolt kontextusa által használt módja szerint összesítik. 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.

Ezek a stratégiák kombinálhatók, és azt javasoljuk, hogy a particionálási séma tervezésekor vegye figyelembe őket. Az adatokat például szegmensekre oszthatja, majd függőleges particionálással tovább oszthatja az egyes szegmensekben lévő adatokat.

Horizontális particionálás (horizontális skálázás)

Az 1. ábra vízszintes particionálást vagy shardingot mutat be. Ebben a példában a termékleltár adatai szegmensekre vannak osztva a termékkulcs alapján. Minden szegmens betűrendbe rendezve tárolja a szegmenskulcsok (A-G és H-Z) egymással összefüggő tartományának adatait. A horizontális skálázás több számítógépre szórja a terhelést, ami csökkenti a versengést és javítja a teljesítményt.

1. ábra – Adatok horizontális particionálása (horizontális particionálása) partíciókulcs alapján.

A legfontosabb tényező a shardolási kulcs kiválasztása. A rendszer működése után nehéz lehet módosítani a kulcsot. 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. Egyes szilánkok nagyon nagyok lehetnek, de mindegyik elemhez kevés hozzáférési művelet tartozik. Más szegmensek kisebbek lehetnek, de minden elemhez sokkal gyakrabban férnek hozzá. Azt is fontos biztosítani, hogy egyetlen szegmens ne lépje túl az adattár skálázási korlátait (a kapacitás és az erőforrások feldolgozása szempontjából).

Kerülje a "terhelt" partíciók létrehozását, amelyek hatással lehetnek a teljesítményre és a rendelkezésre állásra. Az ügyfél nevének első betűje például kiegyensúlyozatlan eloszlást okoz, mivel egyes betűk gyakoribbak. Ehelyett használjon egy ügyfél-azonosító kivonatát az adatok egyenletesebb elosztásához a partíciók között.

Válasszon egy skálázási kulcsot, amely minimálisra csökkenti a nagy szegmensek felosztására, a kisebb szegmensek nagyobb partíciókra való felosztására vagy a séma módosítására vonatkozó jövőbeli követelményeket. Ezek a műveletek nagyon időigényesek lehetnek, és szükség lehet egy vagy több szegmens offline állapotba helyezésére a végrehajtásuk során.

Ha a szegmensek replikálva vannak, előfordulhat, hogy egyes replikák online állapotban vannak, míg mások felosztása, egyesítése vagy újrakonfigurálása történik. Előfordulhat azonban, hogy a rendszernek korlátoznia kell 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 adatelkonzisztenciák elkerülése érdekében.

A horizontális particionálásról további információt a horizontális particionálási mintában talál.

Függőleges 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. A 2. ábra a függőleges particionálás példáját mutatja be. 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érhető adatokat tartalmazza, beleértve a termék nevét, leírását és árát. Egy másik partíció készletadatokat tartalmaz: a készletszámot és az utolsóként rendezett dátumot.

2. ábra – Adatok függőleges particionálása a használati mintával.

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óként rendezett dátum egy külön partícióban van tárolva, mivel ezt a két elemet gyakran használják együtt.

A függőleges particionálás egyéb előnyei:

• A viszonylag lassan mozgó adatok (terméknév, leírás és ár) elválaszthatók a dinamikusabb adatoktól (részvényszint és utolsó rendelés dátuma). A lassan mozgó adatok jó jelöltek arra, hogy egy alkalmazás a memóriában gyorsítótárazza őket.

• A bizalmas adatok külön partíción, extra biztonsági vezérlőkkel tárolhatók.

• 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 adattár entitásszintjén működik, részben normalizálva egy entitást, hogy egy széles elemről szűk elemekre bontsa. 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, érdemes lehet SQL Server oszloptárolókat is használni.

Funkcionális particionálás

Ha egy alkalmazás minden különálló üzleti területének határos környezete azonosítható, a funkcionális particionálással javítható az elkülönítés és az adathozzáférés teljesítménye. A funkcionális particionálás másik gyakori funkciója az írható-olvasható adatok és az írásvédett adatok elkülönítése. A 3. ábra a funkcionális particionálás áttekintését mutatja be, ahol a leltáradatok el vannak választva az ügyféladatoktól.

3. ábra – Adatok funkcionális particionálása határolt környezet vagy altartomány szerint.

Ez a particionálási stratégia segíthet csökkenteni az adathozzáférési versengést a rendszer különböző részeiben.

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, és kiegyensúlyozni őket, hogy az adatok elosztása a maximális méretezhetőség érdekében legyen. 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.

A méretezhetőség érdekében a partíciók tervezésekor kövesse az alábbi lépéseket:

1. 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.
2. 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özött, hogy megfeleljen a méretezhetőségi célnak. A horizontális particionáláshoz fontos a megfelelő szegmenskulcs kiválasztása, hogy a elosztás egyenletes legyen. További információkért tekintse meg a szeletelési mintát.
3. Győződjön meg arról, hogy minden partíció rendelkezik elegendő erőforrással a méretezhetőségi követelmények kezeléséhez az adatméret és az átviteli sebesség tekintetében. Az adattártól függően partíciónként 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, esetleg két vagy több stratégiát kombinálva.
4. 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. Ha igen, lehetséges a partíciók újraegyensúlyozása, vagy a rendszer egyes részeinek újratervezése a szükséges egyensúly eléréséhez.

Egyes felhőkörnyezetek az infrastruktúra határait tekintve 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 adatok mennyiségének várható növekedéséhez az adattárolás, a feldolgozási teljesítmény és a sávszélesség tekintetében.

Ha például Azure táblatárolót használ, akkor a kérések mennyisége korlátozott, amelyet egyetlen partíció kezelhet egy adott időszakban. (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. Ha igen, előfordulhat, hogy a szegmenst újra kell particionolni a terhelés szétterítéséhez. 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ény gyakran növelhető kisebb adatkészletek használatával és párhuzamos lekérdezések futtatásával. Minden partíciónak tartalmaznia kell a teljes adatkészlet kis részét. Ez a mennyiségcsökkenés javíthatja a lekérdezések teljesítményét. A particionálás azonban nem alternatíva az adatbázisok megfelelő tervezésére és konfigurálására. Győződjön meg például arról, hogy rendelkezik a szükséges indexekkel.

A partíciók lekérdezési teljesítményhez való tervezésekor kövesse az alábbi lépéseket:

1. 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.
   • Keresse 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.

2. A lassú teljesítményt okozó adatok particionálása:

   • Korlátozza az egyes partíciók méretét, hogy a lekérdezés válaszideje a célon belül legyen.
   • 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 megakadályozza, hogy a lekérdezésnek minden partíción át kelljen vizsgálnia.
   • Fontolja meg egy partíció helyét. Ha lehetséges, 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.

3. Ha egy entitás átviteli sebességre és lekérdezési teljesítményre vonatkozó követelményekkel rendelkezik, az entitás alapján használjon funkcionális particionálást. Ha ez továbbra sem felel meg a követelményeknek, alkalmazzon horizontális particionálást is. A legtöbb esetben elegendő egyetlen particionálási stratégia, de bizonyos esetekben hatékonyabb a két stratégia kombinálása.

4. A teljesítmény javítása érdekében fontolja meg a lekérdezések párhuzamos futtatását a partíciók között.

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

Az adatok particionálása javíthatja az alkalmazások rendelkezésre állását azáltal, hogy biztosítja, hogy a teljes adathalmaz ne képezze egyetlen meghibásodási pontot, és hogy az adathalmaz egyes részhalmazai egymástól függetlenül kezelhetők legyenek.

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

Milyen kritikus fontosságúak az adatok az üzleti műveletek szempontjából. Határozza meg, hogy mely adatok a kritikus üzleti információk, például a tranzakciók, és mely adatok kevésbé kritikus fontosságú operatív adatok, például naplófájlok.

• Fontolja meg a kritikus adatok magas rendelkezésre állású partíciókban való tárolását egy megfelelő biztonsági mentési tervvel.

• 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 azokat megfelelő gyakorisággal együtt lehessen biztonsági másolatot készíteni. Előfordulhat például, hogy a tranzakcióadatokat tartalmazó partíciókról gyakrabban kell biztonsági másolatot készíteni, mint a naplózási vagy nyomkövetési adatokat tartalmazó partíciókról.

Az egyes partíciók kezelése. A partíciók tervezése a független felügyelet és karbantartás támogatására 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 túl nagyok ahhoz, hogy a tervezett karbantartás ne fejeződjön be ebben az időszakban.

A kritikus adatok partíciók közötti replikálása. Ez a stratégia javíthatja 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. Ebben az időszakban a különböző partíciók különböző adatértékeket tartalmaznak.

Alkalmazástervezési szempontok

A particionálás összetettebbé teszi a rendszer kialakítását és fejlesztését. Fontolja meg a particionálást a rendszertervezés alapvető részeként, még akkor is, ha a rendszer kezdetben csak egyetlen partíciót tartalmaz. Ha a particionálást utószkenvedésként kezeli, az nagyobb kihívást jelent, mert már rendelkezik egy élő rendszerrel, amely karbantartható:

• Módosítani kell az adatelérési logikát.
• Előfordulhat, hogy nagy mennyiségű meglévő adatot kell migrálni, hogy azokat eloszthassa a partíciók között.
• A felhasználók várhatóan továbbra is használhatják a rendszert a migrálás során.

Bizonyos esetekben a particionálás nem számít fontosnak, mert a kezdeti adatkészlet kicsi, és egyetlen kiszolgáló könnyen kezelhető. Ez bizonyos számítási feladatokra igaz lehet, de számos kereskedelmi rendszernek ki kell terjednie a felhasználók számának növekedésével.

Ráadásul nem csak a nagy adattárak élvezik a particionálás előnyeit. Előfordulhat például, hogy egyidejű ügyfelek százai férnek hozzá nagy mértékben egy kis adattárhoz. Az adatok particionálása ebben a helyzetben segíthet csökkenteni a versengést és javítani az átviteli sebességet.

Az adatparticionálási séma tervezésekor vegye figyelembe a következő szempontokat:

A partíciók közötti adathozzáférési műveletek minimalizálása. Ahol lehetséges, tartsa az adatokat a leggyakoribb adatbázis-műveletekhez az egyes partíciókban, hogy minimálisra csökkentse a partíciók közötti adathozzáférési műveleteket. A partíciók közötti lekérdezések időigényesebbek lehetnek, mint az egyetlen partíción belüli lekérdezések, de az egyes lekérdezések partícióinak optimalizálása 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. (Előfordulhat, hogy ez a megközelítés bizonyos esetekben nem lehetséges, például amikor az egyik lekérdezés eredménye a következő lekérdezésben lesz felhasználva.)

Fontolja meg a statikus referenciaadatok replikálását. 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ók különálló keresési műveleteit. 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 forgalma legyen. A referenciaadatok módosításainak szinkronizálása azonban további költségekkel jár.

A partíciók közötti illesztések minimalizálása. Ahol lehetséges, minimalizálja a hivatkozási integritás követelményeit a függőleges és funkcionális partíciókon. 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ásnak általában egy kulcs, majd egy idegen kulcs alapján kell egymást követő lekérdezéseket végrehajtania. Ehelyett fontolja meg a releváns adatok replikálását vagy denormalizálásá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.

Fogadja el az idővel kialakuló konzisztenciát. Annak kiértékelése, hogy az erős konzisztencia valóban 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, hogy a frissítések sikeresen befejeződnek. Emellett kezeli azokat az inkonzisztenciákat is, amelyek az adatok lekérdezéséből eredhetnek, miközben egy végül konzisztens művelet fut.

Fontolja meg, hogy a lekérdezések hogyan találják meg 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, akkor is jelentős hatással van a teljesítményre, 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 természetesen meg tudják adni a partíciót. A vízszintes particionálás viszont megnehezítheti az elemek helyének elhelyezését, mivel minden szegmens ugyanazt a sémát használja. Tipikus megoldás egy térkép karbantartására, amely adott elemek szegmenshelyének keresésére szolgál. Ez a térkép implementálható az alkalmazás horizontális skálázási logikájában, vagy az adattár által karbantartható, ha támogatja a transzparens horizontális skálázást.

Fontolja meg a szegmensek rendszeres újraegyensúlyozását. A horizontális particionálással a szegmensek újraelosztása segíthet az adatok méret és számítási feladat szerinti egyenletes elosztásában 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 azonban egy összetett feladat, amely gyakran egyéni eszköz vagy folyamat használatát igényli.

Partíciók replikálása. Ha minden partíciót replikál, az nagyobb védelmet nyújt a hibák ellen. Ha egyetlen replika meghibásodik, a lekérdezések egy működő példány felé irányíthatók.

Ha eléri a particionálási stratégia fizikai korlátait, előfordulhat, hogy a méretezhetőséget egy másik szintre kell kiterjesztenie. Ha például a particionálás az adatbázis szintjén van, előfordulhat, hogy több adatbázisban kell partíciókat keresnie vagy replikálnia. Ha a particionálás már az adatbázis szintjén van, és a fizikai korlátozások problémát jelentenek, az azt jelentheti, hogy több üzemeltetési fiók partícióit kell megkeresnie vagy replikálnia.

Kerülje azokat a tranzakciókat, amelyek több partíciót érintenek az adatokkal. 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, valószínűleg az alkalmazáslogika részeként kell implementálnia, mert a particionálási rendszerek többsége nem nyújt natív támogatást.

Minden adattárhoz szükség van valamilyen üzemeltetési felügyeleti és monitorozási tevékenységre. A feladatok köre az adatok betöltésétől, az adatok biztonsági mentésétől és visszaállításától, az adatok átrendezésétől és a rendszer megfelelő és hatékony működésének biztosításától terjedhet.

Vegye figyelembe a működési felügyeletet befolyásoló alábbi tényezőket:

• A megfelelő felügyeleti és üzemeltetési feladatok implementálása az adatok particionálásakor. Ilyen feladat lehet például a biztonsági mentés és visszaállítás, az adatok archiválása, a rendszer figyelése és egyéb felügyeleti feladatok. A logikai konzisztencia fenntartása például a biztonsági mentési és visszaállítási műveletek során kihívást jelenthet.

• Hogyan töltheti be az adatokat több partícióba, és hogyan adhat hozzá más forrásokból érkező új adatokat. 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.

• Az adatok rendszeres archiválása és törlése. A partíciók túlzott növekedésének megakadályozása érdekében rendszeresen (például havonta) kell archiválnia és törölnie az adatokat. Előfordulhat, hogy az adatokat egy másik archív sémának megfelelően kell átalakítani.

• Az adatintegritási problémák megkeresése. É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 egy másikban lévő hiányzó adatokra hivatkoznak. 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 újraelosztá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ülheti bizonyos partíciók adatmennyiségét, ami miatt egyes partíciók megközelítik a kapacitáskorlátokat.

Egyes adattárak, például a Azure Cosmos DB, automatikusan újraegyensúlyozhatják a partíciókat. Más esetekben az újraegyensúlyozás egy olyan felügyeleti feladat, amely két szakaszból áll:

1. Új particionálási stratégia meghatározása.

   • Mely partíciókat kell felosztani (vagy esetleg kombinálni)?
   • Mi az új partíciókulcs?

2. Adatok áttelepítése a régi particionálási sémából az új partíciókészletbe.

Az adattártól függően előfordulhat, hogy az adatok áttelepíthetők a partíciók között, amíg használatban vannak. Ezt nevezzük online migrálásnak. Ha ez nem lehetséges, előfordulhat, hogy a partíciókat elérhetetlenné kell tennie az adatok áthelyezése közben (offline migrálás).

Offline áthelyezés

Az offline migrálás általában egyszerűbb, mert csökkenti a versengés esélyét. Az offline migrálás elméletileg az alábbiak szerint működik:

1. Jelölje meg a partíciót offline állapotúként.
2. Adat felosztása és egyesítése, majd áthelyezése az új partíciókra.
3. Ellenőrizze az adatokat.
4. Az új partíciók online állapotba hozása.
5. Távolítsa el a régi partíciót.

Az 1. lépésben egy partíciót írásvédettként is megjelölhet, így az alkalmazások az áthelyezés közben is olvashatják az adatokat.

Online migrálás

Az online migrálás összetettebb, de kevésbé zavaró. A folyamat hasonló az offline migráláshoz, kivéve, hogy az eredeti partíció nincs offlineként megjelölve. Az áttelepítési folyamat részletességétől függően (például elemek és szegmensek szerint) az ügyfélalkalmazások adatelérési kódjának két helyen, az eredeti partíción és az új partíción tárolt adatok olvasását és írását kell kezelnie.

Következő lépések

• További információ az adott Azure szolgáltatások particionálási stratégiáiról. További információ: Adatparticionálási stratégiák.
• A standard tárfiókok méretezhetőségi és teljesítménycéljai

Kapcsolódó erőforrások

• A megfelelő adattár kiválasztása

A következő tervezési minták lehetnek relevánsak a forgatókönyvhöz:

• A horizontális skálázási minta az adatok skálázására szolgáló gyakori stratégiákat ismerteti.

• Az indextábla mintája bemutatja, hogyan hozhat létre másodlagos indexeket adatokon keresztül. Az alkalmazások ezzel a módszerrel gyorsan lekérhetik az adatokat olyan lekérdezésekkel, amelyek nem hivatkoznak a gyűjtemény elsődleges kulcsára.

• A materializált nézetminta bemutatja, hogyan hozhat létre előre feltöltött nézeteket, amelyek adatokat összegznek a gyors lekérdezési műveletek támogatásához. Ez a módszer akkor lehet hasznos a particionált adattárakban, ha az összegzendő adatokat tartalmazó partíciók több helyen vannak elosztva.

Számos nagy léptékű megoldásban az adatok partíciókra vannak osztva, amelyek külön kezelhetők és érhetők el. A particionálás javíthatja a skálázhatóságot, csökkentheti a versengést és optimalizálhatja a teljesítményt. Egy olyan mechanizmust is kínálhat, amellyel az adatokat fel lehet osztani a használati minták mentén. Például a régebbi adatok olcsóbb adattárolókban archiválhatók.

A particionálási stratégiát azonban gondosan kell kiválasztani az előnyök maximalizálása érdekében, a káros hatások minimalizálása mellett.

Megjegyzés:

Ebben a cikkben az particionálási kifejezés azt jelenti, hogy az adatok fizikailag külön adattárakba oszthatóak. Ez nem ugyanaz, mint SQL Server tábla particionálása.

Miért érdemes adatokat particionálni?

• Skálázhatóság javítása. Ha egyetlen adatbázisrendszert skáláz fel, az végül eléri a fizikai hardverkorlátot. Ha több partícióra osztja az adatokat, és mindegyik külön kiszolgálón található, szinte határozatlan ideig skálázhatja fel a rendszert.

• Javítja a teljesítményt. Az egyes partíciók adathozzáférési műveletei kisebb mennyiségű adaton keresztül történnek. A megfelelő módon végzett particionálás hatékonyabbá teheti a rendszert. Egynél több partíciót érintő műveletek párhuzamosan is futtathatók.

• 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.

• Működési rugalmasság biztosítása. A particionálás számos lehetőséget kínál a műveletek finomhangolására, a felügyeleti hatékonyság maximalizálására és a költségek minimalizálására. Az egyes partíciók adatainak fontossága alapján például különböző stratégiákat határozhat meg a felügyeleti, monitorozási, biztonsági mentési és visszaállítási, valamint egyéb felügyeleti feladatokhoz.

• Hasonlítsa össze az adattárat a használati mintával. A particionálás lehetővé teszi, hogy minden partíció más típusú adattárban legyen üzembe helyezve a költségek és az adattár által kínált beépített funkciók alapján. A nagy bináris adatok például blobtárolóban tárolhatók, míg strukturáltabb adatok tárolhatók egy dokumentumadatbázisban. További információ: A megfelelő adattár kiválasztása.

• A rendelkezésre állás javítása. Az adatok több kiszolgáló közötti elkülönítése elkerüli az egyetlen meghibásodási pontot. Ha egy példány meghibásodik, csak az abban a partícióban lévő adatok nem érhetők el. A más partíciókon végzett műveletek folytathatók. A szolgáltatásként felügyelt platform (PaaS) adattárai esetében ez a szempont kevésbé releváns, mivel ezek a szolgáltatások beépített redundanciával vannak kialakítva.

Partíciók tervezése

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

• Horizontális felosztás (más néven darabolá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 adott részhalmazát tartalmazza, például egy adott ügyfélcsoport összes megrendelését.

• Függőleges particionálás. Ebben a stratégiában minden partíció az adattárban lévő elemek mezőinek egy részét tartalmazza. A mezők a használati mintájuknak megfelelően vannak elosztva. Előfordulhat például, hogy a gyakran elért mezők egy függőleges partícióban helyezkednek el, míg a kevésbé gyakran elértek egy másikban.

• Funkcionális particionálás. Ebben a stratégiában az adatokat a rendszer minden egyes határolt kontextusa által használt módja szerint összesítik. 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.

Ezek a stratégiák kombinálhatók, és azt javasoljuk, hogy a particionálási séma tervezésekor vegye figyelembe őket. Az adatokat például szegmensekre oszthatja, majd függőleges particionálással tovább oszthatja az egyes szegmensekben lévő adatokat.

Horizontális particionálás (horizontális skálázás)

Az 1. ábra vízszintes particionálást vagy shardingot mutat be. Ebben a példában a termékleltár adatai szegmensekre vannak osztva a termékkulcs alapján. Minden szegmens betűrendbe rendezve tárolja a szegmenskulcsok (A-G és H-Z) egymással összefüggő tartományának adatait. A horizontális skálázás több számítógépre szórja a terhelést, ami csökkenti a versengést és javítja a teljesítményt.

1. ábra – Adatok horizontális particionálása (horizontális particionálása) partíciókulcs alapján.

A legfontosabb tényező a shardolási kulcs kiválasztása. A rendszer működése után nehéz lehet módosítani a kulcsot. 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. Egyes szilánkok nagyon nagyok lehetnek, de mindegyik elemhez kevés hozzáférési művelet tartozik. Más szegmensek kisebbek lehetnek, de minden elemhez sokkal gyakrabban férnek hozzá. Azt is fontos biztosítani, hogy egyetlen szegmens ne lépje túl az adattár skálázási korlátait (a kapacitás és az erőforrások feldolgozása szempontjából).

Kerülje a "terhelt" partíciók létrehozását, amelyek hatással lehetnek a teljesítményre és a rendelkezésre állásra. Az ügyfél nevének első betűje például kiegyensúlyozatlan eloszlást okoz, mivel egyes betűk gyakoribbak. Ehelyett használjon egy ügyfél-azonosító kivonatát az adatok egyenletesebb elosztásához a partíciók között.

Válasszon egy skálázási kulcsot, amely minimálisra csökkenti a nagy szegmensek felosztására, a kisebb szegmensek nagyobb partíciókra való felosztására vagy a séma módosítására vonatkozó jövőbeli követelményeket. Ezek a műveletek nagyon időigényesek lehetnek, és szükség lehet egy vagy több szegmens offline állapotba helyezésére a végrehajtásuk során.

Ha a szegmensek replikálva vannak, előfordulhat, hogy egyes replikák online állapotban vannak, míg mások felosztása, egyesítése vagy újrakonfigurálása történik. Előfordulhat azonban, hogy a rendszernek korlátoznia kell 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 adatelkonzisztenciák elkerülése érdekében.

A horizontális particionálásról további információt a horizontális particionálási mintában talál.

Függőleges 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. A 2. ábra a függőleges particionálás példáját mutatja be. 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érhető adatokat tartalmazza, beleértve a termék nevét, leírását és árát. Egy másik partíció készletadatokat tartalmaz: a készletszámot és az utolsóként rendezett dátumot.

2. ábra – Adatok függőleges particionálása a használati mintával.

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óként rendezett dátum egy külön partícióban van tárolva, mivel ezt a két elemet gyakran használják együtt.

A függőleges particionálás egyéb előnyei:

• A viszonylag lassan mozgó adatok (terméknév, leírás és ár) elválaszthatók a dinamikusabb adatoktól (részvényszint és utolsó rendelés dátuma). A lassan mozgó adatok jó jelöltek arra, hogy egy alkalmazás a memóriában gyorsítótárazza őket.

• A bizalmas adatok külön partíción, extra biztonsági vezérlőkkel tárolhatók.

• 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 adattár entitásszintjén működik, részben normalizálva egy entitást, hogy egy széles elemről szűk elemekre bontsa. 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, érdemes lehet SQL Server oszloptárolókat is használni.

Funkcionális particionálás

Ha egy alkalmazás minden különálló üzleti területének határos környezete azonosítható, a funkcionális particionálással javítható az elkülönítés és az adathozzáférés teljesítménye. A funkcionális particionálás másik gyakori funkciója az írható-olvasható adatok és az írásvédett adatok elkülönítése. A 3. ábra a funkcionális particionálás áttekintését mutatja be, ahol a leltáradatok el vannak választva az ügyféladatoktól.

3. ábra – Adatok funkcionális particionálása határolt környezet vagy altartomány szerint.

Ez a particionálási stratégia segíthet csökkenteni az adathozzáférési versengést a rendszer különböző részeiben.

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, és kiegyensúlyozni őket, hogy az adatok elosztása a maximális méretezhetőség érdekében legyen. 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.

A méretezhetőség érdekében a partíciók tervezésekor kövesse az alábbi lépéseket:

1. 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.
2. 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özött, hogy megfeleljen a méretezhetőségi célnak. A horizontális particionáláshoz fontos a megfelelő szegmenskulcs kiválasztása, hogy a elosztás egyenletes legyen. További információkért tekintse meg a szeletelési mintát.
3. Győződjön meg arról, hogy minden partíció rendelkezik elegendő erőforrással a méretezhetőségi követelmények kezeléséhez az adatméret és az átviteli sebesség tekintetében. Az adattártól függően partíciónként 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, esetleg két vagy több stratégiát kombinálva.
4. 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. Ha igen, lehetséges a partíciók újraegyensúlyozása, vagy a rendszer egyes részeinek újratervezése a szükséges egyensúly eléréséhez.

Egyes felhőkörnyezetek az infrastruktúra határait tekintve 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 adatok mennyiségének várható növekedéséhez az adattárolás, a feldolgozási teljesítmény és a sávszélesség tekintetében.

Ha például Azure táblatárolót használ, akkor a kérések mennyisége korlátozott, amelyet egyetlen partíció kezelhet egy adott időszakban. (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. Ha igen, előfordulhat, hogy a szegmenst újra kell particionolni a terhelés szétterítéséhez. 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ény gyakran növelhető kisebb adatkészletek használatával és párhuzamos lekérdezések futtatásával. Minden partíciónak tartalmaznia kell a teljes adatkészlet kis részét. Ez a mennyiségcsökkenés javíthatja a lekérdezések teljesítményét. A particionálás azonban nem alternatíva az adatbázisok megfelelő tervezésére és konfigurálására. Győződjön meg például arról, hogy rendelkezik a szükséges indexekkel.

A partíciók lekérdezési teljesítményhez való tervezésekor kövesse az alábbi lépéseket:

1. 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.
   • Keresse 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.

2. A lassú teljesítményt okozó adatok particionálása:

   • Korlátozza az egyes partíciók méretét, hogy a lekérdezés válaszideje a célon belül legyen.
   • 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 megakadályozza, hogy a lekérdezésnek minden partíción át kelljen vizsgálnia.
   • Fontolja meg egy partíció helyét. Ha lehetséges, 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.

3. Ha egy entitás átviteli sebességre és lekérdezési teljesítményre vonatkozó követelményekkel rendelkezik, az entitás alapján használjon funkcionális particionálást. Ha ez továbbra sem felel meg a követelményeknek, alkalmazzon horizontális particionálást is. A legtöbb esetben elegendő egyetlen particionálási stratégia, de bizonyos esetekben hatékonyabb a két stratégia kombinálása.

4. A teljesítmény javítása érdekében fontolja meg a lekérdezések párhuzamos futtatását a partíciók között.

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

Az adatok particionálása javíthatja az alkalmazások rendelkezésre állását azáltal, hogy biztosítja, hogy a teljes adathalmaz ne képezze egyetlen meghibásodási pontot, és hogy az adathalmaz egyes részhalmazai egymástól függetlenül kezelhetők legyenek.

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

Milyen kritikus fontosságúak az adatok az üzleti műveletek szempontjából. Határozza meg, hogy mely adatok a kritikus üzleti információk, például a tranzakciók, és mely adatok kevésbé kritikus fontosságú operatív adatok, például naplófájlok.

• Fontolja meg a kritikus adatok magas rendelkezésre állású partíciókban való tárolását egy megfelelő biztonsági mentési tervvel.

• 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 azokat megfelelő gyakorisággal együtt lehessen biztonsági másolatot készíteni. Előfordulhat például, hogy a tranzakcióadatokat tartalmazó partíciókról gyakrabban kell biztonsági másolatot készíteni, mint a naplózási vagy nyomkövetési adatokat tartalmazó partíciókról.

Az egyes partíciók kezelése. A partíciók tervezése a független felügyelet és karbantartás támogatására 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 túl nagyok ahhoz, hogy a tervezett karbantartás ne fejeződjön be ebben az időszakban.

A kritikus adatok partíciók közötti replikálása. Ez a stratégia javíthatja 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. Ebben az időszakban a különböző partíciók különböző adatértékeket tartalmaznak.

Alkalmazástervezési szempontok

A particionálás összetettebbé teszi a rendszer kialakítását és fejlesztését. Fontolja meg a particionálást a rendszertervezés alapvető részeként, még akkor is, ha a rendszer kezdetben csak egyetlen partíciót tartalmaz. Ha a particionálást utószkenvedésként kezeli, az nagyobb kihívást jelent, mert már rendelkezik egy élő rendszerrel, amely karbantartható:

• Módosítani kell az adatelérési logikát.
• Előfordulhat, hogy nagy mennyiségű meglévő adatot kell migrálni, hogy azokat eloszthassa a partíciók között.
• A felhasználók várhatóan továbbra is használhatják a rendszert a migrálás során.

Bizonyos esetekben a particionálás nem számít fontosnak, mert a kezdeti adatkészlet kicsi, és egyetlen kiszolgáló könnyen kezelhető. Ez bizonyos számítási feladatokra igaz lehet, de számos kereskedelmi rendszernek ki kell terjednie a felhasználók számának növekedésével.

Ráadásul nem csak a nagy adattárak élvezik a particionálás előnyeit. Előfordulhat például, hogy egyidejű ügyfelek százai férnek hozzá nagy mértékben egy kis adattárhoz. Az adatok particionálása ebben a helyzetben segíthet csökkenteni a versengést és javítani az átviteli sebességet.

Az adatparticionálási séma tervezésekor vegye figyelembe a következő szempontokat:

A partíciók közötti adathozzáférési műveletek minimalizálása. Ahol lehetséges, tartsa az adatokat a leggyakoribb adatbázis-műveletekhez az egyes partíciókban, hogy minimálisra csökkentse a partíciók közötti adathozzáférési műveleteket. A partíciók közötti lekérdezések időigényesebbek lehetnek, mint az egyetlen partíción belüli lekérdezések, de az egyes lekérdezések partícióinak optimalizálása 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. (Előfordulhat, hogy ez a megközelítés bizonyos esetekben nem lehetséges, például amikor az egyik lekérdezés eredménye a következő lekérdezésben lesz felhasználva.)

Fontolja meg a statikus referenciaadatok replikálását. 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ók különálló keresési műveleteit. 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 forgalma legyen. A referenciaadatok módosításainak szinkronizálása azonban további költségekkel jár.

A partíciók közötti illesztések minimalizálása. Ahol lehetséges, minimalizálja a hivatkozási integritás követelményeit a függőleges és funkcionális partíciókon. 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ásnak általában egy kulcs, majd egy idegen kulcs alapján kell egymást követő lekérdezéseket végrehajtania. Ehelyett fontolja meg a releváns adatok replikálását vagy denormalizálásá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.

Fogadja el az idővel kialakuló konzisztenciát. Annak kiértékelése, hogy az erős konzisztencia valóban 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, hogy a frissítések sikeresen befejeződnek. Emellett kezeli azokat az inkonzisztenciákat is, amelyek az adatok lekérdezéséből eredhetnek, miközben egy végül konzisztens művelet fut.

Fontolja meg, hogy a lekérdezések hogyan találják meg 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, akkor is jelentős hatással van a teljesítményre, 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 természetesen meg tudják adni a partíciót. A vízszintes particionálás viszont megnehezítheti az elemek helyének elhelyezését, mivel minden szegmens ugyanazt a sémát használja. Tipikus megoldás egy térkép karbantartására, amely adott elemek szegmenshelyének keresésére szolgál. Ez a térkép implementálható az alkalmazás horizontális skálázási logikájában, vagy az adattár által karbantartható, ha támogatja a transzparens horizontális skálázást.

Fontolja meg a szegmensek rendszeres újraegyensúlyozását. A horizontális particionálással a szegmensek újraelosztása segíthet az adatok méret és számítási feladat szerinti egyenletes elosztásában 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 azonban egy összetett feladat, amely gyakran egyéni eszköz vagy folyamat használatát igényli.

Partíciók replikálása. Ha minden partíciót replikál, az nagyobb védelmet nyújt a hibák ellen. Ha egyetlen replika meghibásodik, a lekérdezések egy működő példány felé irányíthatók.

Ha eléri a particionálási stratégia fizikai korlátait, előfordulhat, hogy a méretezhetőséget egy másik szintre kell kiterjesztenie. Ha például a particionálás az adatbázis szintjén van, előfordulhat, hogy több adatbázisban kell partíciókat keresnie vagy replikálnia. Ha a particionálás már az adatbázis szintjén van, és a fizikai korlátozások problémát jelentenek, az azt jelentheti, hogy több üzemeltetési fiók partícióit kell megkeresnie vagy replikálnia.

Kerülje azokat a tranzakciókat, amelyek több partíciót érintenek az adatokkal. 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, valószínűleg az alkalmazáslogika részeként kell implementálnia, mert a particionálási rendszerek többsége nem nyújt natív támogatást.

Minden adattárhoz szükség van valamilyen üzemeltetési felügyeleti és monitorozási tevékenységre. A feladatok köre az adatok betöltésétől, az adatok biztonsági mentésétől és visszaállításától, az adatok átrendezésétől és a rendszer megfelelő és hatékony működésének biztosításától terjedhet.

Vegye figyelembe a működési felügyeletet befolyásoló alábbi tényezőket:

• A megfelelő felügyeleti és üzemeltetési feladatok implementálása az adatok particionálásakor. Ilyen feladat lehet például a biztonsági mentés és visszaállítás, az adatok archiválása, a rendszer figyelése és egyéb felügyeleti feladatok. A logikai konzisztencia fenntartása például a biztonsági mentési és visszaállítási műveletek során kihívást jelenthet.

• Hogyan töltheti be az adatokat több partícióba, és hogyan adhat hozzá más forrásokból érkező új adatokat. 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.

• Az adatok rendszeres archiválása és törlése. A partíciók túlzott növekedésének megakadályozása érdekében rendszeresen (például havonta) kell archiválnia és törölnie az adatokat. Előfordulhat, hogy az adatokat egy másik archív sémának megfelelően kell átalakítani.

• Az adatintegritási problémák megkeresése. É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 egy másikban lévő hiányzó adatokra hivatkoznak. 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 újraelosztá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ülheti bizonyos partíciók adatmennyiségét, ami miatt egyes partíciók megközelítik a kapacitáskorlátokat.

Egyes adattárak, például a Azure Cosmos DB, automatikusan újraegyensúlyozhatják a partíciókat. Más esetekben az újraegyensúlyozás egy olyan felügyeleti feladat, amely két szakaszból áll:

1. Új particionálási stratégia meghatározása.

   • Mely partíciókat kell felosztani (vagy esetleg kombinálni)?
   • Mi az új partíciókulcs?

2. Adatok áttelepítése a régi particionálási sémából az új partíciókészletbe.

Az adattártól függően előfordulhat, hogy az adatok áttelepíthetők a partíciók között, amíg használatban vannak. Ezt nevezzük online migrálásnak. Ha ez nem lehetséges, előfordulhat, hogy a partíciókat elérhetetlenné kell tennie az adatok áthelyezése közben (offline migrálás).

Offline áthelyezés

Az offline migrálás általában egyszerűbb, mert csökkenti a versengés esélyét. Az offline migrálás elméletileg az alábbiak szerint működik:

1. Jelölje meg a partíciót offline állapotúként.
2. Adat felosztása és egyesítése, majd áthelyezése az új partíciókra.
3. Ellenőrizze az adatokat.
4. Az új partíciók online állapotba hozása.
5. Távolítsa el a régi partíciót.

Az 1. lépésben egy partíciót írásvédettként is megjelölhet, így az alkalmazások az áthelyezés közben is olvashatják az adatokat.

Online migrálás

Az online migrálás összetettebb, de kevésbé zavaró. A folyamat hasonló az offline migráláshoz, kivéve, hogy az eredeti partíció nincs offlineként megjelölve. Az áttelepítési folyamat részletességétől függően (például elemek és szegmensek szerint) az ügyfélalkalmazások adatelérési kódjának két helyen, az eredeti partíción és az új partíción tárolt adatok olvasását és írását kell kezelnie.

Következő lépések

• További információ az adott Azure szolgáltatások particionálási stratégiáiról. További információ: Adatparticionálási stratégiák.
• A standard tárfiókok méretezhetőségi és teljesítménycéljai

Kapcsolódó erőforrások

• A megfelelő adattár kiválasztása

A következő tervezési minták lehetnek relevánsak a forgatókönyvhöz:

• A horizontális skálázási minta az adatok skálázására szolgáló gyakori stratégiákat ismerteti.

• Az indextábla mintája bemutatja, hogyan hozhat létre másodlagos indexeket adatokon keresztül. Az alkalmazások ezzel a módszerrel gyorsan lekérhetik az adatokat olyan lekérdezésekkel, amelyek nem hivatkoznak a gyűjtemény elsődleges kulcsára.

• A materializált nézetminta bemutatja, hogyan hozhat létre előre feltöltött nézeteket, amelyek adatokat összegznek a gyors lekérdezési műveletek támogatásához. Ez a módszer akkor lehet hasznos a particionált adattárakban, ha az összegzendő adatokat tartalmazó partíciók több helyen vannak elosztva.