RDBMS fejlesztési irányok. Ferris Wheel (óriáskerék) Jim Gray törvényei. Elosztott adatbázisok problémái. Elosztott adatbázisok

Átírás

1 1 RDBMS fejlesztési irányok Column store Tömb adatmodell JIT fordító és vektorizált végrehajtás Ferris wheel (óriáskerék) Elosztott adatbázisok Ferris Wheel (óriáskerék) Optimalizált scan műveletek Table scan, index scan Adattárházak alapvető funkciója, optimalizálni kell Sokáig tart, nagy IO költség Egyszerre több query is olvashatja ugyanazt a táblát Miért kell ehhez többször betölteni az adatot? Viszont a queryk nem egyszerre indulnak A queryk újrahasznosítják a másik által már elindított scaneket Nem az elején kezdik a scant, hanem felülnek a már futó scan műveletekre A tábla végére érve a scan tovább fut elölről Akkor van vége, ha épp nincsen olyan query, ami még további sorokat szeretne olvasni Jim Gray törvényei Scale-out: Az adatfeldolgozás csak masszív párhuzamosítással oldható meg Az számolást kell vinni az adathoz és nem az adatot a számoláshoz 6 Elosztott adatbázisok Adat particionálás (sharding) Vertikális particionálás Kulcs tartományok külön szervereken Funkcionális particionálás Függőleges particionálás Bizonyos oszlopok külön szervereken Replikáció Magas rendelkezésre állás (redundancia) Terheléselosztás Nem kell külön back-up + ezek kombinációi Elosztott adatbázisok problémái Lassú hálózat Szerveren belül nagyon gyors IO Racken belül közös switch Rackek között más lassabb kapcsolat Geo-redundáns rendszerek: nagy késleltetésű hálózat Co-location awareness A rendszer kihasználja az adatok közeliségét A feladatokat úgy kell szervezni, hogy az minimális hálózaton keresztüli adatmozgatással járjon Replikáció Az adatokról több másolat készül, külön-külön szerverekre Ugyanakkor az adatírási műveletek bonyolultak lesznek Hogyan tarthatóak a replikák szinkronban, úgy, hogy az ne rontsa a teljesítményt? 1

2 7 Elosztott műveletek Feltesszük: a tábla több szerver között van elosztva Scan Be kell olvasni minden sort pontosan egyszer Sort Shardonként sorba rendezés, majd merge sort Key lookup Az indexek szintén shardolhatók Adott kulcstartomány adott shardon Join? Ez általánosságban kemény dió Elosztott JOIN Elmélet régen kidolgozva Általános esetben nem oldható meg optimálisan Optimalizálási probléma Minimális adatmozgatás legyen a hálózaton át Hogyan kell ehhez az adatokat és a végrehajtást szervezni? A JOIN queryről nehezen mondható meg az eredményhalmaz számossága! Kevés implementáció Gyakran nem is az RDBMS része, hanem felső réteg Korlátozott funkcionalitással MySQL cluster SQL Azure Microsoft Parallel Data Warehouse stb Elosztott JOIN ötletek Mindent tükrözzünk le mindenhova Párhuzamosítható futás Sok tárhelyet igényel, de egyszerű megvalósítani A kisebb táblát másoljuk oda, ahol a nagyobb van Mi van akkor, ha van WHERE feltétel is? Okos statisztikák kellenek Akár statisztika készítése menet közben Előre mintavételezett táblák A kicsi, ritkán írt táblákat eleve tükrözzük le minden shardra Elosztott JOIN ötletek 2 Particionáljunk idegen kulcs szerint Ha tudjuk, hogy a tábla mindig joinban fog szerepelni Ekkor az INNER JOIN egy shardon belül elvégezhető Lazy-JOIN A ritkán használt oszlopokat más, nagy kapacitású, de lassabb tárterületre tesszük Előbb lefuttatjuk a JOIN-okat (semi join), majd utána gyűjtjük hozzá a többi oszlopot Ekkor elegendő első körben csak a JOIN-hoz szükséges oszlopokat mozgatni (vagy tükrözni) 11 Elosztott JOIN ötletek 3 Alkalmazzunk okos cache-elést Ha már egy táblát valahova lemásoltunk, akkor egy darabig tartsuk is meg ott A hatékony cache-elés nagyban függ a futtatott query-ktől Milyen oszlopok, milyen sorok? Mennyire szűrnek a WHERE feltételek N. Li (2012) Több táblás JOIN tovább bonyolódik Nem mindegy a sorrend Gond, ha a JOIN ciklikus Graywulf Szalay Sándor Johns Hopkins Egyetem, Baltimore ELTE közreműködéssel SQL Server klaszterek tudományos célú felhasználása Load-balancing, probabilistic join, distributed join, array database stb. SkyQuery, turbulencia, stb. DataScope: klaszter DB + GPU integrációval 2

3 13 Web 2.0 Keresők, óriásáruházak, közösségi oldalak Néha exponenciális növekedés A nagy vasak nem bővíthetők a végtelenségig Hatalmas adatmennyiség Kevésbé strukturált adatok Magas rendelkezésre állás Nem baj, ha nem teljesen konzisztens RDBMS 16 Elosztott rendszerek Elosztott rendszerekre nagy igény lett nódus olcsó szerverekből Shared nothing megközelítés A nódusok meghibásodás a napi rutin része RDBMS-nél máig implementálatlan a több gépre történő scale-out Fő probléma: elosztott JOIN Próbálkozások vannak, pl. MySQL Cluster, Graywulf stb. Egy egyszerűbb út: új megközelítésű adatbázisok nosql (not only SQL) Sürgős fejlesztési kényszer Az RDBMS nagyon bonyolult, nem lehet gyorsan bővíteni a funkcionalitás Legyen sokkal egyszerűbb, de elosztott! Min lehet spórolni? Nem SQL nyelv Nem deklaratív programozási modell (imperatív) Nem relációs adatmodell Nincsenek általános scan és join műveletek Az ACID tranzakciós modell egyszerűsítése BASE (ld. később) 18 Két fontos terület Nagy mennyiségű adat feldolgozása Rendszeres műveletek Sok adat redukálása, scan Nagy számú felhasználó kiszolgálása Terhelés megosztása Random műveletek Adatok replikálása Adatbiztonsági okokból Terhelésmegosztás miatt Hadoop Google cikk alapján, Apache projekt, teljesen Java Hadoop Distributed File System Elosztott fájlrendszer, replikáció több gép között Nagy fájlokra (n 64Mb optimalizálva) Feladatütemező Sokgépes környezetben biztosítja a feladatok particionált futtatását Co-location-aware A feladatoknak párhuzamosíthatóknak kell lenniük Vagy túl bonyolult megírni, vagy ehelyett: Egyszerű építőkockákkal lehet csak dolgozni 3

4 20 Map/Reduce Feladatok megfogalmazása Filter, Map és Reduce függvény implementálható Ebből kell összerakni a programot A futtatás az adat kis darabjain történik A feldolgozandó adatcsomagokat az ütemező osztja ki Az adathalmaz többi részét egy-egy függvény nem láthatja Egy program több Filter/Map/Reduce rétegből állhat A rétegek a HDFS-re való írással osztják meg egymás között az adatokat Map/Reduce Filter Előzetes szűrést végez az adatokon Map Az előzetesen megszűrt adathalmaz minden elemére meghívódik Transzformációs műveleteket végez a következő reduce lépés számára Reduce Egy komplett adatcsomagot dolgoz fel A kapott adatok kombinációjából új adatokat állít elő A bemeneti adatok több partícióról, shardról is származhatnak 21 Map/Reduce Nagy előny szinte korlátlan scale-out működik Nagy hátrány: túl alacsony szintű, de pl.: PIG: magas szintű nyelv Hadoophoz Hive: Query nyelv + indexek Hadoophoz Nem új technológia, csak újra felfedezték Map/Reduce vs. RDBMS Amit MapReduce-szal meg lehet oldani, azt RDBMS-sel is A nehéz elosztott JOIN-okat a MapReduce sem tudja Hadoop fájlrendszer helyett legyenek táblák stb. nosql adatmodellek Key-Value (Redis, MongoDB, Scalien) Value lehet sokféle Dokumentum (bináris, xml stb.) String, lista, hash-tábla stb. BigTable (Google, Hbase, Cassandra) Sorok kulccsal Oszlopcsaládok (előre definiált) Oszlopok (nem előre definiált) Valójában key-value kompozit kulccsal Lehet még gráf, objektum stb. nosql alapok Alapműveletek adat megtalálása kulcs alapján egyetlen kulcshoz tartozó érték módosítása Tranzakciók egyszerűek egyetlen kulcs értékének a módosítása atomi a tranzakciók egylépésesek, nem párhuzamosítottak nincsen szükség a bonyolult izolációs rendszerre Nincsen scan művelet Kereséshez mindenképp kell index Indexeket karban kell tartani Van, hogy kézzel kell megoldani, de gyakran gyári támogatás is van 4

5 Konzisztencia Biztonsági mentés helyett replikáció Az adatok több példányban tárolódnak Mi biztosítja, hogy a replikák konzisztensek maradnak? Kell valami replikációs protokoll Általában aszinkron C Konzisztencia ablak Mennyi idő után válik a rendszer konzisztenssé Rendelkezésre állás Az adatok folyton elérhetőek Több belépési pont Nincsen egyetlen kritikus elem sem Geo-redundancia A válasz legyen gyors Minimális késleltetés Még akkor is, ha a visszaadott adat nem konzisztens A Partíció tűrés Elosztott rendszer Hálózati kapcsolat (lassú, törékeny) P Több belépési pont A rendszer akkor is működőképes marad, ha egyes részei nem látják egymást Elosztott funkcionalitás Pl. Facebook felhasználó bejelentkezés, fénykép megosztás, levelesláda CAP-tétel A háromból egyszerre csak kettő teljesíthető! A C P Tranzakciós modell lazítása BASE ACID elosztott rendszernél nagyon drága (2PC) Hiba esetén nem lehet tranzakciót érvényesíteni Helyette: BASE basically available, soft-state, eventually consistent Eleve olyan rendszert feltételez, ahol vannak hibák A hibákat optimista módon kezeli A tranzakciók hatásai nem egy időben jelennek meg ehhez kellene a kétlépéses érvényesítés üzenet formájában, véges idő alatt terjednek BA: Basically available Főleg CP rendszer esetében Legalább a rendszer egy része maradjon elérhető Soft-state A változások véges ideig tartó üzenetekkel történnek A rendszer állapota akkor is változhat, ha épp nincsen input Minden adatra lehet egy érvényességi idő Ha ez lejárt, akkor meg kell vizsgálni, hogy konzisztens-e még Eventually consistent Főleg AP rendszer esetében A változások aszinkron propagálnak (gossip protokollok) Egy idő után konzisztenssé válik Konzisztencia ablak 5

6 Konfliktusok feloldása Hiba miatt inkonzisztens állapot Fel kell oldani Többségi szavazáson múló algoritmusok Pl. Paxos Node-ok quorumokba szerveződve szavaznak Időbélyegzőn alapuló algoritmusok Mindig a legfrissebb adat tekintendő Deklaratív nyelv, optimalizáló RDBMS BigTable Hadoop Optimalizált scan Elsődleges kulcs szerinti elérés Indexek szerinti keresés Join műveletek Párhuzamos végrehajtás Egyszerű sharding Tranzakciók Többlépéses tranzakciók Durability ACID BASE backup/log replikáció replikáció Egyszerű load balancing Nem strukturált adat Szabványos API 6