Az alapprobléma. Az SQL querydeklaratív Azt mondjuk meg, hogy mit akarunk eredménynek Nem azt, hogy milyen fizikai műveletek történjenek

Átírás

1 1

2 2 Az alapprobléma Az SQL querydeklaratív Azt mondjuk meg, hogy mit akarunk eredménynek Nem azt, hogy milyen fizikai műveletek történjenek Rendelkezésre álló információk Maga az SQL lekérdezés Táblák, oszlopok, kulcsok sémája, tárolási módja Nem-klaszterezett indexek Index statisztika (hisztogram a kulcsértékek eloszlásáról) Memória mérete Processzorok száma A szerver a lehetséges fizikai műveletek sokaságát implementálja Sok kombináció vezet azonos eredményre Mi alapján választ?

3 3 A lekérdezés-optimalizáló Olyan algoritmus, ami az SQL lekérdezés alapján előáll egy végrehajtási tervvel Lehetőleg optimálissal Csak azzal tud dolgozni, ami rendelkezésre áll pl. új indexet (általában) nem épít de pl. sorba rendezés műveletet gyakran beiktat Sorra veszi a lehetséges végrehajtási terveket Fizikai operátorok többféle kombinációja A fizikai operációkhoz erőforrás-igény alapján költséget rendel (IO, memória, CPU, tempdb használati igény) A legolcsóbb végrehajtási tervet próbálja megtalálni Mennyiben lehet beleszólni? Klaszterezett indexeket megfelelő kulcs szerint szervezzük Ha jó indexeket tervezünk, akkor jobb tervet tud találni A fizikai operátorokat expliciten elő lehet írni (join hint)

4 4 Index kiválasztása Elsődleges kiválasztási szempontok Tartalmazza az összes oszlopot, ami a lekérdezés végrehajtásához kell (beágyazott oszlopok!) Megfelelő sorrendben legyen rendezve A lehető legkisebb legyen a lehetséges indexek közül IO igény meghatározása Az oszlopok számát a lekérdezés és a kiválasztott index megadja Az indexstatisztika alapján megbecsülhető a beolvasandó sorok száma Szekvenciális és random elérés szerint is lehet súlyozni

5 Demo 5

6 6

7 7 Jim Gray törvényei adattárházak tervezésére Nagyon sok adat -> egy szerver nem elég Scale-out megközelítés: nagyobb gép helyett több gép Könnyű bővíthetőségre kell törekedni Az adatokat nem akarjuk kimozgatni a szerverből A számítást kell az adatokhoz vinni, és nem az adatokat a számítást végző processzorokhoz A megoldandó problémákat igyekezzünk deklaratív módon (SQL) megfogalmazni A lekérdezések előre nem ismertek Általánosságban kell az indexeket tervezni Mi a 20 legfontosabb query, amit mindenképp tudnia kell? A kutatók minél hamarabb használni akarják Gyors fejlesztést igényel Mégse rohanjunk előre Mindig lépésenként, működő verzióról működőre

8 Adattárház építés menete Forrás adatok értelmezése Adatbázis séma megtervezése Indexek megtervezése Adat layout megtervezése Indexek felépítése Adatokok betöltése Adatbázis létrehozása Kliens alkalmazások / Felhasználói felület

9 Tudományos adatok formátuma Legtöbb helyen még mindig szöveges fájlok Történeti okokból tudományáganként nagyon sokfajta szabványos adatformátum létezik Pl. csillagászat: FITS (Flexible Image Transfer) Sok projekt ad-hoc formátumot használ, rosszabb esetben binárisat Adatbázis építésekor az első lépés mindig az adatok beolvashatóvá tétele

10 Adatok betöltése Rossz: INSERT utasítások tömkelege Nem effektív Mindent szöveggé kell formázni Közepes Kliens könyvtár használatával (program vagy script) ADO.NET, ODBC, JDBC stb. A kliens könyvtár jelentős overhead lehet Soronként történik, tranzakcióban Ilyen esetben mindig expliciten kell kezelni a tranzakciókat, és a betöltést soros darabokban végezni! A bemeneti adatfájlokat nem kell előzetesen konvertálni Részletes logika építhető a betöltő programba

11 11 Adatok betöltése bulk mőveletek Jó: Bulk Insert Nagy mennyiségű adat betöltésére optimalizálva Bináris vagy szöveges adatból A bemeneti fájl formátuma kötött Emiatt az adatokat előzetesen konvertálni kell Minimális naplózás Egyéb bulk eszközök (adott terméktől függő) Pl. SQL Server: bpc parancs (import/export)

12 Adatbetöltés elsı lépései Tudományos adatgyűjtő rendszerek adatai mindig hibásak -> sok ellenőrzés kell! Forrásadatok letöltése, fájlok konzisztenciájának ellenőrzése Forrásadatok konvertálása olyan formátumra, amit a bulk insert elfogad, ellenőrzés Betöltési csomagokba szervezés A betöltés táblánként megy Érdemes ~100 GB-onként húzni egy határt A határ kövesse az elsődleges kulcsot

13 Adatbetöltés betöltı táblákba Betöltő-táblák létrehozása Ez nem a végső tábla Betöltés indexek nélkül A betöltés gyorsabb, ha nincsen semmilyen kulcs A kulcs, vagy szükséges indexes később gyorsan létrehozhatók a kis méretű betöltő táblán Bulk Insert futtatása táblánként az egész betöltési csomagra esetleg futtatható több csomag párhuzamosan

14 14 Betöltı táblák kondicionálása Betöltött adatok konzisztenciájának ellenőrzése Azonosítók egyediségének ellenőrzése Értékek intervallumának ellenőrzése Idegen kulcsok ellenőrzése Fedő index építése a betöltő-táblára, ami a leendő elsődleges kulcs oszlopai tartalmazza Jelentősen felgyorsítja a klaszterezett index építését, ha nincsen SORT művelet

15 15 Adatok konzisztenciája Tudományos adatok mindig hibásak Ha kulcsot építünk, előfordulhat Nem egyedi, aminek annak kellene lennie Az idegen kulcs nem létező elsődleges kulcsra mutat Intervallumon kívüli értékek is szerepelnek A szerver csak hibaüzenetet küld, de azt nem tudjuk meg, hogy a hiba melyik sorban van Manuális lekérdezésekkel elvégezni az ellenőrzéseket, amik azt is megadják, hogy hol a hiba Szükség esetén a konvertáló scriptek módosítása Az adatfájlokat gyakran kézzel kell javítani

16 Adatok másolása végleges táblákba Ha az összes betöltési csomag elkészült és minden teszt lefutott Végleges táblák létrehozása klaszterezett indexszel Mindenképp az adatok bemásolása előtt Később nem lehet rátenni (ezek nagyon nagy táblák) Adatok átmásolása speciális query segítségével Minimális logolást biztosítani kell Nem-klaszterezett indexek felépítése

17 17 Merge mőveletek Ha nem biztosítható, hogy a betöltőtáblák az elsődleges kulcs diszjunk intervallumait tartalmazzák Ilyenkor a nagy táblába sorokat kell beszúrni a már meglevők közé (összefésülés) Ez nagyon drága művelet Ellenőrizni kell, hogy a kulcs létezik-e Helyet kell csinálni az új soroknak (page split) Logolni kell Érdemes az index fill factort alacsonynak választani

18 Best practices Vizuális eszközök helyett scriptek Source control alá vonható Megjegyzésekkel látható el Metaadatokat is tartalmazhat (ld. később) Text formátum előnye Bináris forrásfájl helyett érdemes szöveges fájlokat használni a bulk inserthez, mert kezdetben sokkal könnyebb megtalálni a hibákat; később lehet váltani Betöltés kisebb egységekben Ha valami elromlik betöltés közben, sokkal könnyebb a hibát megtalálni és a betöltést megismételni Indexek tesztelése építés előtt Az SQL szerver ugyan teszteli az egyediséget, de nem tudja megmondani, hogy hol a hiba; érdemes saját queryvel tesztelni Idegen kulcsok tesztelése Az SQL szerver képes idegen kulcs kapcsolat automatikus ellenőrzésére, de ez rontja a bulk insert teljesítményét; érdemes saját queryvel tesztelni Off-line indexek Az nem-klaszterezett indexek átmenetileg kikapcsolhatóak, érdemes ezt a funkciót használni

19 19

20 Metaadatok adattárházakban Tudományos adatok pontosan kell tudni, hogy mit jelentenek a számok mértékegység, de pl. vákuum vagy levegőben mért hullámhossz? automatikus mértékegység konverzió? származtatott mennyiségek képletek alapján? mérési utasítás: milyen számolással kaptuk meg az adatot? az adatok minőségét, megbízhatóságát is ismerni kell A metaadatokat emberek és programok számára is érthetővé akarjuk tenni Adatok programok általi értelmezhetősége fontos Tudományterületenként szabványosítani kell Nem csak az adatformátumra, a metaadatokra, ontológiákra is vonatkozik Adatok könnyű megoszthatósága Szemantikus információkra van szükség Az adatsémáról plusz információt tárolunk Az adatmodell összekapcsolása a valósággal

21 21 Ontológia Definiálunk egy univerzumot Az általunk modellezni kívánt valóságot írja le Az univerzum fogalmait összegyűjtjük A fogalmakra kategorizálási szempontokat alkotunk A fogalmakat hierarchiába vagy gráfba szervezzük Az ontológia alapján hierarchikus fogalom-azonosítók (content descriptor) Metaadatok alapeleme lesz Fogalom lehet Entitás: valami fizikailag vagy logikailag létező Konkrét vagy absztrakt Mért mennyiség, fizikai törvény (képlet) Tulajdonság: egy entitás valamilyen jellemzője Ez pl. lehet egy mennyiség mérési utasítása Reláció: entitásokat összekapcsoló fogalom Pl. tartalmazás, birtoklás stb.

22 22 Provenance Provenance szó eredeti jelentése műtárgyak származása, eredete, története Tudományos adatoknál is fontos az adatok származása Ha a netről szedünk valamit, tudni kell, hogy mennyire megbízható Pontosan kell ismerni a származtatott mennyiségek kiszámításának módját Ha a felhasználó maga transzformálja az adatokat, akkor szeretné visszakövetni, hogy hogyan jutott az adott eredményre

23 23 Metaadatok A táblák oszlopait kiegészítő információval látjuk el Hierarchikus, ontológián alapuló azonosítók Programok számára értelmezhető Mértékegységek Provenance információ Minőséget jelző információ Minimum mérési hiba Emberek számára érthető részletes leírás Weboldalon megjeleníthető Szemantikus rendszerek Ma még gyerekcipőben Célok intelligens kliens programok adattárházak automatikus összekapcsolása

24 24 Metaadatok adatbázisokban Az oszlop neve nem elég SQL Server Extended properties A séma minden egyes eleméhez rendelhető SQL lekérdezésekkel olvasható Érdemes a metaadatokat a scriptekben megírni Pl. megjegyzésekbe kódolva (XML comments) Egyszerű parser kiolvassa és beteszi az adatbázisba Metaadatok az adattárház felhasználói felületén Dokumentáció automatikus generálása

25 25 Adattárházat központi nyilvántartása Registry: az egész rendszer elemeiről tartalmaz információt Hardver Milyen gépek, hol, milyen hálózattal, diszkkel stb. Szoftver konfiguráció Adatbázisok Hol milyen adat érhető el Hova kell irányítani egy adott számítási feladatot, ahol lehetőleg minden adat rendelkezésre áll Szolgáltatások Hol milyen programok, keresési lehetőségek állnak rendelkezésre A registry kereshető Adott típusú adatot szolgáltató adatbázisok Adott feladatot megvalósító szolgáltatások Jövőbeli cél: Egy deklaratívan megfogalmazott problémát az egymással automatikusan együttműködő adattárházak a szemantikus információk segítségével képesek lényeges emberi beavatkozás nélkül megoldani Ehhez a registryt használják kiindulásul