MapReduce paradigma a CAP-tétel kontextusában. Adatb haladóknak. Balassi Márton Adatbázisok haladóknak 2012.

Hasonló dokumentumok
Elosztott adatbázis-kezelő formális elemzése

GENERÁCIÓS ADATBÁZISOK A BIG DATA KÜLÖNBÖZŐ TERÜLETEIN

MMK-Informatikai projekt ellenőr képzés 4

Hadoop és használata az LPDS cloud-on





Szárnyas Gábor (BME) diáinak felhasználásával.

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

A Facebook adattárháza. Trencséni Márton info99

Hálózatba kapcsolt adatbázisok. Erős Levente, TMIT 2011.




Webes alkalmazások fejlesztése 11. előadás. Alkalmazások felhőben Giachetta Roberto

Webes alkalmazások fejlesztése 11. előadás. Alkalmazások felhőben. Alkalmazások felhőben Számítástechnikai felhő







Gartner: Hype Cycle for Big Data NoSQL Database Management Systems





Weblog elemzés Hadoopon 1/39

Nagy adathalmazok elosztott feldolgozása. Dr. Hajdu András, Debreceni Egyetem, Informatikai Kar

Élet az SQL-en túl: Az adatfeldolgozás legújabb trendjei. Földi Tamás


























































Big Data adattárházas szemmel. Arató Bence ügyvezető, BI Consulting


Virtuális Obszervatórium. Gombos Gergő



Adatbázis rendszerek I


Big Data tömeges adatelemzés gyorsan

Komponens alapú szoftverfejlesztés 10. előadás. Elosztott alkalmazások architektúrái. Elosztott alkalmazások architektúrái

MongoDB THE NOSQL DATABASE. Készítette: Hugyák Tamás v2.1.1



Átírás:

MapReduce paradigma a CAP-tétel kontextusában Balassi Márton balassi.marton@gmail.com 2012. október 30. Adatbázisok haladóknak 2012. 2012. október 30.

Miről lesz szó? Elosztott adatfeldolgozásról általában Motiváció, kontraszt a hagyományossal Brewer-sejtés, CAP-tétel MapReduce paradigma Elosztott fájlrendszer (DFS) Map és Reduce Hadoop Példák Kérdések, válaszok 2012. október 30. Balassi Márton 2.

Elosztott adatfeldolgozás: motiváció Mi történik, ha fel kell dolgoznunk az internet adatmennyiségét? Legyen 5*10 10 dokumentum, átlagosan 20 Kbyte tartalommal: Pbyte nagyságrend Az I/O kapacitás a legerősebb vasak esetében sem haladja meg a Gbyte/sec nagyságrendet: ~1 évig tart a beolvasás Megoldás: Scale up helyett Scale out, azaz inkább több commodity vasat hasznosítunk 2012. október 30. Balassi Márton 3.

Más rendszerek kontextusában SQL (structured query language) Scale out/up Key/Values Pairs Offline batch processing DFS 2012. október 30. Balassi Márton 4.

Brewer-sejtés: elméleti határ Építhetünk-e egyszerre konzisztens, nagyrendelkezésre állású és partíciótűrésű rendszert? 2012. október 30. Balassi Márton 5.

CAP-tétel Az ördög a részletekben rejlik 2012. október 30. Balassi Márton 6.

Konzisztencia (Consistency) Létezik egy teljes rendezés az összes rendszerbeli operáció között, amely biztosítja, hogy úgy fussanak le, mintha ezt egyetlen példányban tennék Azaz: Megköveteljük az elosztott közös tártól, hogy úgy működjön, mintha egyetlen node-on futna, egyesével kiszolgálva az operációkat Szemléletesen annyit tesz, hogyha kliens A 1-est, majd 2- est ír egy X helyre, akkor kliens B nem olvashatja később ezt az 1-est, mint a 2-est. 2012. október 30. Balassi Márton 7.

Rendelkezésre állás (Availability) Minden működő node-nak válaszolnia kell az általa a kliensektől kapott kérésekre. De a modell része, hogy a válasz megérkezése végtelenül sok időbe telhet Azaz: Végül minden operáció terminál. A visszaadott érték helyességét viszont semmi nem garantálja. 2012. október 30. Balassi Márton 8.

Partíciótűrés (Partition tolerance) A rendszer képessége, hogy működőképes maradjon partíciók jelenlétében, akkor is, ha partíciókat törlünk vagy adunk hozzá. Maga a cikk,,elfelejti definiálni. De mi is az a,,partíció? Tekintjük a node-ok diszjunkt halmazokba, azaz,,komponensekbe való felosztását. Azt mondjuk, hogy különböző komponensek közötti csomagok elvesznek. Gyakorlatilag ez pontosan annyi, hogy csomagok a nodeok között,, elveszhetnek. 2012. október 30. Balassi Márton 9.

Lynch aszinkron modellje I/O auomata Fairness Kompozíció 2012. október 30. Balassi Márton 10.

CAP-tétel és bizonyítása Az aszinkron modellben nem konstruálható olyan read/write adatobjektum, amely garantálja a rendelkezésre állás és a konzisztencia feltételeit minden fair esetben. 2012. október 30. Balassi Márton 11.

CAP-tétel és bizonyítása Az aszinkron modellben nem konstruálható olyan read/write adatobjektum, amely garantálja a rendelkezésre állás és a konzisztencia feltételeit minden fair esetben. 2012. október 30. Balassi Márton 12.

CAP-tétel és bizonyítása Az aszinkron modellben nem konstruálható olyan read/write adatobjektum, amely garantálja a rendelkezésre állás és a konzisztencia feltételeit minden fair esetben. 2012. október 30. Balassi Márton 13.

CAP-tétel és NoSQL eszközök 2012. október 30. Balassi Márton 14.

MapReduce paradigma 2012. október 30. Balassi Márton 15.

WordCount példa

WordCount példa

WordCount példa (Hadoop)

WordCount példa (Hadoop)

MeanNaive példa

MeanCombine példa

Hadoop folyamatok NameNode (Secondary NameNode) DataNode JobTracker TaskTracker

A gyakorlatban A bit of hands on Hadoop WordCount HDFS kezelés Webes UI Szimulációk kezelése

Összefoglalás helyett CAP MapReduce Elosztott Hadoop HDFS

Köszönöm a figyelmet! Balassi Márton marton@db.bme.hu 2012. október 30. Balassi Márton Adatbázisok haladóknak 2012. 2012. október 30.