Barangolások a 4 Tera feletti adattárházak világában

Kővári Attila 2010. december 14.

A tanfolyami beharangozó után folytassuk ott ahol előtte abahagytuk: a referencia adattárház architektúránál. Az apropót az adja, hogy nemrég Prágában jártam egy tréningen, ahol megtanultuk, hogy hogyan lehet a nulláról felépíteni, feltölteni és üzemeltetni egy többtíz terás adattárházat. Ennek a tapasztalatairól szeretnék beszámolni elsősorban arra koncentrálva, hogy mit használhatunk a tanultakból a hazai méretekre jellemzőbb "kisebb" adattárházak építése esetén is. Kezdjünk is hozzá:

Scan-re kell optimalizálni, nem seek-re

Egy tipikus adattárház lekérdezés jellemzően sok adatot olvas fel a diszkről azokat aggregálja majd az eredményt elküldi a felhasználónak. Éppen ezért a hardvert, az oprendszert és az adatbáziskezelőt is erre a nagytömegű adatok gyors beolvasására kell optimalizálni. Nem arra, hogy a fej gyorsan megtalálja a keresett rekordot (mint pl a vállalatirányítási rendszerek esetén), hanem arra, hogy a fej minél kevesebbet ugráljon és ha egyszer bepozícionálta magát akkor, minél több adatot olvasson fel a fej környékéről. (Megj.: Ez a Scan-re optimalizálás egyébként áthatja az egész módszertant, sokszor elő fog még jönni, mint szempont.)

Ha a diszkhez nyúlunk, akkor olvassunk be mindent amit a fej környéken találunk

A referencia adattárház architektúrát úgy alakították ki, hogy ha az SQL Server a diszkhez fordul adatért, akkor már ne csak a kért adatot olvassa fel, hanem a kért adatok körzetében található adatokat is.

„Ha a fej már úgy is érinti a lemezt akkor olvassuk be a környékén lévő adatokat, hiszen úgy is szükség lesz rá" És ez igaz is hiszen a tipikus adattárház lekérdezés legalább egy hónap adatait magába foglalja, és elég nagy a valószínűsége annak, hogy a kiolvasott adat mellett található adatra is szükség lesz. (Az elgondolás azonban csak úgy működik hatékonyan, ha a lemezen fizikailag egymáshoz közel találhatóak az összetartozó adatok. Azaz nem töredezett az adatbázis, de erről majd egy kicsit később.)

Mindehhez a referencia architektúra a diszkrendszerek előre olvasását használja ki (Storage pre-fetch), azaz azt, hogy a hardverek cache-elhetik a fej környéki adatokat. Ezt még kiegészítve az SQL Server előreolvasási képességével (Read-Ahead) és RAID-1 tömbökből adódó kettős olvasással az SQL Szerver egy olvasási szálon többszörösét tudja lekérdezni az 512K-s korlátnak.

Töredezettség minimalizálása (Fragmentation)

Ahogy a fájl rendszer, úgy az adatbázis is lehet töredezett. (Töredezett egy adatbázis, ha az összetartozó adatok nem sorfolytonosan helyezkednek el a diszken) Töredezett lehet maga az adatbázis fájl is, de töredezett lehet a PAGE is, az Extent is. (és az index is)

A töredezettség több szempontból is káros: Az érthető, hogy ha mondjuk egy táblányi adat felolvasához ide-oda kell ugrálnia fejnek akkor lassabb lesz a lekérdezés, mintha sorfolytonosan fel tudta volna olvasni a lemezről. De nem csak ez jelent problémát.

Az SQL Server is és a diszk alrendszer is több adatok olvas fel, mint amennyit az SQL server kér (lásd Storage pre-fetch , Read Ahead). Ennek örülünk, de ha olyan adatokat olvas így be, amelyekre nincs is szükség (például egy másik tábla adatait), akkor ez inkább káros, mint hasznos. Épp ezért fontos, hogy ne legyen töredezett a tábla, az összetartozó adatok helyezkedjenek el egymás mellett a lemezen.

Mi okozhat töredezettséget? Az Update, Delete mind mind töredezettséget okoznak, de töredezettséget okozhat a párhuzamos Insert is. Míg az első kettő sokszor nem okoz problémát, mert pl.: ritkán törlünk, addig a párhuzamos írás már inkább jelenthet gondot. Sajnos nem fér bele az időbe, hogy leírjam, hogy hogyan lehet a párhuzamos írással is fentartani a töredezettlenséget, (mert máshogy kell eljárni ősfeltöltés és a napi betöltések során, máshogy kell őrizni a töredezettséget partícionált és nem partícionált környezetben, máshogy kell eljárnunk ha Heap, és ha clustered indexes ténytáblákat töltünk, stb). A lényeg hogy az ilyen többterás környezetben ésszel, vagy nem kell használni a párhuzamos insert-et, mert amit megnyerünk a betöltési időn annak többszörösét veszíthetjük el a lekérdezéskor

Tömörítés

Újra és újra előjön ez a téma: Az adatbázis tömörítés elsődleges célja a lekérdezések gyorsítása. Persze örülünk annak is, hogy kevesebb helyet foglal az adat a diszken, de igazából annak örülünk, hogy a tömörítés eredményeképpen gyorsulnak a lekérdezések. Miért? Mert a lassú diszkrendszertől elvesszük a terhelés egy részét és odaadjuk az amúgy is alacsony kihasználtságú processzornak.

Egyebek

Mindezek mellett még természetesen fontos a partícionálás, a minimálisan naplózott beszúrás és az is hogy a rendezett adatoknál egyezzen meg az adat logikai és fizikai sorrendje is, de ezek már-már triviálisnak tekinthetők. Bár mondjuk az nem biztos hogy triviális, hogy a minimális naplózás lassabb diszkrendszereken nem feltétlenül fog sebességnövekedést eredményezni, vagy hogy hogyan lehet biztosítani az adatok fizikai rendezettségét. De ha itt nem fejezem be a cikket, akkor sosem lesz vége...

Zárszó

E cikk csak arról szólt, hogy mi mindent lehet hasznosítani a „kis" adattárház esetén is, de a tanfolyam nem csak erről, illetve nem is erről szólt. Inkább arról, hogy hogyan kell felépíteni és üzemeltetni egy ilyen referencia adattárház architektúra alapján összeállított 4 -48 terás adattárházat. Hogyan, milyen tömbökbe kell a diszkeket rendezni, azokra hogyan kell elhelyezni az adatbázis fájlokat, hogyan kell konfigurálni az oprendszert, milyen startup paraméterekkel kell indítani az SQL, milyen szempontokat kell figyelembe venni a párhuzamos insert-ek megtervezésekor az ősfeltöltés és a napi betöltések során és még sorolhatnám. Csupa olyan téma, amire a kis adattárházak még nem érzékenyek ám a 4 tera feletti adattárházak már nagyon.

Megtanultuk, hogy olcsó hardverkomponensekből is össze lehet állítani nagyon komoly adattárházat, de megtanultuk azt is hogy ez korántsem egy egyszerű dolog. Mindenesetre a kiképzést megkaptuk, úgyhogy az ilyen irányú hazai kompetencia is rendelkezésre áll.

Kapcsolódó anyagok: