Windows - Adatbázisok partícionálása

Az adatbázisok partícionálása, azaz több darabra bontása akkor működik megfelelően, ha a tagkiszolgálón lévő adatok lekérdezéséhez az SQL utasítást közvetlenül a megfelelő tagkiszolgálóhoz címezzük. A táblák csoportokat alkotnak kapcsolataik szerint. Ha például veszünk egy személyt, akkor az ő adatai megtalálhatók egy személyi törzs adattáblában, és pl. alkalmazottakat nyilvántartó táblában is. A partíciók akkor a legeredményesebbek, ha ezek a logikailag összetartozó adatok ugyanazon a tagkiszolgálón helyezkednek el.

Szimmetrikus partíciók

A partícionálás legeredményesebb változata a szimmetrikus elosztás:

Összekapcsolódó adatok egyazon tagkiszolgálón való elhelyezésével az SQL parancsok átirányításának szüksége csökkenthető, ha egyáltalán elő is fordul ilyen. Egy elosztott nézet tervezési célja a 80/20-as szabállyal kezdődik: tervezzük úgy a partíciókat, hogy a legtöbb SQL utasítás irányítható legyen tagszerverre, ahol legalább az adatok 80%-a helyezkedjen el, és az elosztott lekérdezéseknek 20%-nál kevesebb adatra legyen szükségük. Úgy tesztelhetjük ezt le, hogy nézzük meg, hogy vajon a partíció, ahol minden sor rendelkezésre áll, tartalmazza-e az idegen kulcsos sorokat is. Amely adatbázistervben ez megvalósul, ott érdemes partícionálni.
Az adatok egyenletesen oszlanak el a tagkiszolgálók között. Például képzeljünk el egy országos szervezetet, amely megyékre tagolt, és a szervezet alkalmazottai csak a saját megyéjükben működhetnek, valamint az ügyfelek is a legtöbbször saját megyéjükben intézik dolgaikat. A megye, az ügyfelek és az alkalmazottak táblája felosztható megyénként. Néhány lekérdezésnek szüksége lehet több megyéből származó adatokra, de a legtöbb lekérdezést az adott szerver ki tudja szolgálni, hiszen csak a saját adatait kérték le. A felhasználó beviteli környezete alapján irányítja az alkalmazás az SQL parancsokat a megfelelő régió tagkiszolgálójához.

Aszimmetrikus partíciók

Habár ideális esetben a szimmetrikus felosztás a cél, a legtöbb alkalmazásnak bonyolult adatlekérdezési formái vannak, ami gátolja a szimmetrikus partícionálás lehetőségeit. Az aszimmetrikus partíciók eredménye, hogy néhány tagkiszolgáló nagyobb szerepet vállal a többinél. Például az adatbázisnak csak néhány táblája lehet felosztva, ennélfogva a többi, nem felosztott tábla az eredeti szerveren marad. Aszimmetrikus partíciók képesek a szimmetrikus partíciók teljesítményének nagy részét nyújtani, ami az alábbi előnyöket jelenti:

Drámaian növeli a teljesítményt egy adatbázisnál - ahol nem lehet szimmetrikus partícionálást alkalmazni - az, ha néhány tábláját aszimmetrikusan felosztják.
Tökéletes felosztása egy meglévő rendszernek ismétlődő aszimmetrikus fejlesztések sorozatával. Minden lépésben a felosztásra kiválasztott táblák azok, amelyek általában a legnagyobb teljesítményjavulást eredményezik.

Egy aszimmetrikus megközelítésben, az eredeti szerveren mindig marad néhány tábla, ami nem fér bele a felosztási sémába. A teljesítménye ezeknek a visszamaradó tábláknak általában növekszik az eredeti rendszerhez képest, mert a tagkiszolgálóra kerülnek a kiválasztott táblák, és ezzel csökkentik az eredeti szerver igénybevételét.

Sok adatbázis felosztható többféleképpen. A megvalósítás során választott speciális felosztásnak a legjobbnak kell lennie, hogy ezzel megfeleljen az üzleti rétegben gyakori rendszerességgel futtatatott SQL utasítások elvárásainak.

Elosztottan partícionált nézetek

Tervezhetjük úgy is a felosztást, hogy a cél kiválasztásához szabályrendszert készítünk, amit az alkalmazás használni tud, hogy eldöntse, melyik tagkiszolgálóhoz érdemes fordulnia az SQL utasításaival a legeredményesebb feldolgozás érdekében. Az üzleti szolgáltatás rétegnek össze kell vetnie a felhasználói adatokat ezekkel a szabályokkal, hogy megtalálja a megfelelő tagkiszolgálót az utasítás feldolgozáshoz.

Az alábbi négy területet kell áttekintenünk, amikor megtervezzük az elosztottan partícionált nézetek csoportját ahhoz, hogy ezt kivitelezzük elosztott adatbázis kiszolgálókon:

Állapítsuk meg az SQL utasítások mintáit, amelyeket az alkalmazás futtat. Készítsünk egy listát a futtatott utasításokról egy tipikus feldolgozási folyamat alatt. Osszuk fel a listát SELECT, UPDATE, INSERT és DELETE kategóriákra, és rendezzük a listákat kategóriánként a futtatások gyakorisága szerint. Ha az utasítások tárolt eljárásokra hivatkoznak, akkor használjuk az alap SELECT, INSERT, UPDATE és DELETE utasításokat a tárolt eljárásokból. Ha felosztunk egy általános SQL 2000 adatbázist, használhatjuk a Profiler eszközt, hogy egy ilyen listát kapjunk. Az SQL utasításgyakoriság használata indokolt megközelítés egy tipikus online tranzakciós feldolgozásnál (OLTP), vagy Web oldal adatbázisánál, ahol az elosztottan partícionált nézetekkel tudunk a legjobban dolgozni. Ezek a rendszerek azáltal jellemezhetők, hogy sajátos SQL utasításokkal rendelkeznek, amelyek általában kis mennyiségű adatot kérdeznek le egy döntéstámogatási, vagy OLAP rendszerben, amikor a lekérdezések típusait összehasonlítjuk. Amikor minden SQL utasítás egy kis mennyiségű adathoz köthető, a használatuk gyakoriságának vizsgálata a rendszer adatforgalmának tárgyilagos megközelítését eredményezi. Több rendszerben azonban van néhány utasításcsoport, amely nagy mennyiségű adathoz köthető. Nekünk erősen kell terhelnünk ezeket a lekérdezéseket, hogy felmérjük nagyméretű adatigényeiket.
Határozzuk meg, hogy hogyan kapcsolódnak a táblák egymáshoz. Az a szándékunk, hogy megtaláljuk azon táblák csoportjait, amelyek feloszthatók ugyanazon dimenzióban, (például résszám, vagy részlegszám) így minden sor, ami az egyedi előforduláshoz kapcsolódik ebben a dimenzióban, ugyanarra a tagkiszolgálóra kerüljön. Például meghatározhatunk egy módszert az adatbázis felosztásra régió szerint. Támogatásként minden táblánál, amelynek nincs régiószám kulcsa, el kell valahogy végezni a felosztást a régióval rokon módon. Ilyen módon egy adatbázisnál mindenütt, ahol a Vasarlok tábla nem tartalmaz régiószám oszlopot, ha a régiók valamely megyerendszer szerint definiáltak, a Vasarlok.Megye oszlopot használhatjuk a vásárlók felosztására a régióval összefüggő módon. Explicit vagy implicit távoli kulcsok lesznek az első átvizsgálandó elemek a felosztási módok keresésénél, mivel ezek kapcsolatot határozhatnak meg táblák között. Vizsgáljuk meg az explicit távoli kulcs definíciókat annak meghatározására, hogy miként használják a lekérdezések egy tábla sorait más táblában lévő sorok megtalálására. Szintén vizsgáljuk meg az implicit távoli kulcsokat, vagy annak módszerét, hogy az utasítások a sor értékei alapján hogyan kötődnek más táblákhoz a JOIN utasítás segítségével, amikor nincs meghatározott távoli kulcs definíció. Meg kell vizsgálni az alkalmazás által generált SQL utasításokat, hogy vajon van-e olyan utasítás, amely táblákat kapcsol össze nem kulcs mezőkkel, ugyanis az implicit távoli kulcsok nincsenek egyértelműen tárolva az adatbázis sémában. Ezek az implicit távoli kulcsok tipikusan indexeltek, hogy növeljék a kapcsolatok teljesítményét, tehát szintén vizsgáljuk meg az adatbázis index definícióit.
Vessük össze az SQL utasítások gyakoriságát a távoli kulcsok vizsgálata kapcsán definiált felosztással. Válasszuk azt a felosztást, amely a legjobb támogatást nyújtja alkalmazásunk vegyes SQL utasításainak. Ha néhány táblacsoport többféleképpen is felosztható, vizsgáljuk meg az SQL utasítások gyakoriságát, hogy eldöntsük melyik partícionálás tesz eleget a legtöbb utasításnak. Azok a táblák, amelyekre az utasítások leggyakrabban vonatkoznak egyben az egyedüliek, amelyek szerint elsőként partícionálni akarunk. Rangsoroljuk a felosztásokat, amelyek a táblákra való hivatkozások gyakorisága szerint készültek. Az SQL utasítások mintái szintén befolyásolják a döntést, hogy vajon mely táblákat osszuk fel:

Osszunk fel egy táblát, ha az utasítások több mint 5%-a egy táblára INSERT, UDATE vagy DELETE utasítással hivatkozik, és a tábla felosztható az általunk választott dimenzió szerint.
Tartsunk teljes másolatokat a táblákról minden tagkiszolgálón, ha több mint 5%-a a táblákra vonatkozó utasításoknak INSERT, UPDATE vagy DELETE utasítás. Szintén szükséges definiálni, hogy a módosítások hogyan történjenek meg, hogy az összes másolatra is kiterjedjenek. Ha magas tranzakciós sértetlenség szükségeltetik, akkor készítsünk triggereket, amelyek elosztott módosításokat végeznek minden másolaton egy elosztott tranzakció környezetén belül. Ha ez a fajta integritás nem szükséges, akkor használjuk valamelyik replikációs mechanizmust, hogy gondoskodjunk a módosítások elterjedéséről.
Ne osszuk fel vagy másoljuk le a táblát, ha több mint 5%-a a parancsoknak INSERT, UDATE vagy DELETE utasítás és a tábla nem osztható fel a választott dimenzióban.

Definiáljunk SQL utasítás útválasztó szabályokat. Az útválasztó szabályoknak képeseknek kell lenniük meghatározni, hogy melyik tagkiszolgáló tudja a legeredményesebben feldolgozni az egyes SQL utasításokat. Kapcsolatot kell létesíteniük a felhasználó beviteli környezete és a tagkiszolgáló között, amely az adatok többségét tartalmazza az utasítás végrehajtáshoz. Az alkalmazásnak a felhasználó által megadott adatokat össze kell vetniük ezekkel a szabályokkal, hogy kiválasszák melyik tagkiszolgáló az illetékes a végrehajtásban.

Adatbázisok partícionálása

Adatbázis optimalizálás 2. rész