Minuet: A Scalable Distributed Multiversion B-Tree Írta: Benjamin Sowell, Wojciech Golab, Mehul A. Shah Feldolgozta: Fokin Miklós, Hodosy Gábor, Tóth Tamás

B+ fa Minden csúcsra: – Maximum n gyerek – Minimum [(n + 1) / 2] gyerek – k gyerekre: k - 1 kulcs Belső csúcsok (nem levél): kulcsok a kereséshez Levél csúcsok: (kulcs – érték) párok, mutató a következő levél csúcsra => intervallumon is gyorsan lehet keresni

Probléma ismertetése Adatkezelő rendszerek két fő feladata: Tranzakciók gyors futtatása - néhány elem olvasása/írása Hosszan futó adatelemzések – kimutatások Jelenlegi rendszerek: Egy időben csak egyiket tudják Mindkettőt egy időben nem tudják hatékonyan Adatbázist futtatnak Elemzés: egész adatbázist lementik, ezen futtatják => Nehézkes működés

Minuet rendszer felépítése Kliensek: proxikkal kommunikálnak Proxi: Kliens nevében tranzakció Memnode-okkal kommunikál Memnode: Adatok elosztottan Adatok hozzáférése: Sinfonia-n keresztül

Sinfonia keretrendszer Memnode-ok adataihoz hozzáférést biztosít Adatok látszólag fix memóriacímeken Minitranzakció Csúcs(ok) olvasása/írása (akár feltételekhez kötve) Hibakezelést végez => tekinthetjük az adatokat helyesnek Két fázisú: – Első fázis: feltételek ellenőrzése, érintett terület zárolása – Feltételek nem teljesülnek: output: melyek nem – Memóriacím zárolva van: újra próba automatikusan – Második fázis: írás/olvasás

Dinamikus tranzakció Minitranzakciók: Adatok elérése a levélben nehézkes Bejárt út minden csúcsára zárolás, lekérés => Dinamikus tranzakciókba foglalás Dinamikus tranzakció - két halmaz: olvasási, írási Műveletek: írás, olvasás Olvasás akármelyik halmazból Írás az írási halmazban Adatot nem talál a halmazokban => minitranzakció Tranzakció végén: – Olvasási halmaz elemeit ellenőrzi, nem változtak-e => szekvencia számok a csúcsokra – Írási halmaz összes elemét kiírja Olvasás akármelyik halmazból

További javítások Proxik: belső csúcsok cache-elése => elég egyben ellenőrizni (konzisztenciának annyi) Minden memnode-nál: összes belső csúcs szekvencia száma =>helyben lehet ellenőrizni az elérési utat => egy lekérés az egész

Dirty read Probléma: (*)-ot olvassuk Közben új értéket beszúrunk (*) nem volt módosítva, de megváltozott a szülője Olvasás sikertelen - pedig helyes lenne Dinamikus tranzakció műveleteihez:Dirty read Csúcs olvasása olvasási halmazba rakás nélkül (így nem kell ellenőrizni, változott-e) Fa bejárása levelek fölötti szintig Dirty read-del Levél olvasása szokásos módon

Fence key Probléma 11-es értékre keresünk A-ban keresnénk Azóta B-be került Tranzakció nem fogja megtalálni Megoldás: fence key-k Csúcsokhoz: leszármazott kulcsok alsó és felső határa Csúcs módosul -> fence key-k is Keresett kulcs nincs a csúcs határai között -> sikertelen próba

Snapshot Konzisztens pillanatkép a fáról Csúcs legújabb verziója – tip snapshot – módosítható (többi nem) Mindegyik csúcshoz snapshot id (szig. monoton növekvő) Létrehozás: lemásoljuk a gyökeret Csúcs írása: – Csúcs.snapshot_id = tip_snapshot_id => felülírás – Csúcs.snapshot_id  tip_snapshot_id => Másolat Szülő mutatóját módosítani kell => másolás felterjesztése első friss csúcsig Max: előre megadott n db snapshot, ez előttieket töröljük

Snapshot borrowing Probléma: snapshot létrehozás Minden memnode-nál frissítjük: – Tip snapshot id-t – Tip snapshot gyökér címét Költséges Javítás: snapshot borrowing Több tranzakció akar egyszerre létrehozni új snapshotot Helyette közösen hoznak létre 1 új snapshotot Megvalósítás: központi szerveren

Szerteágazó verziók Minden verzióhoz fővonal: legelső elágazásokat követve az ág vége Alapértelmezésben a fővonal adja meg az olvasási/írási halmaz célját Saját követendő ágat is meg lehet adni külön Snapshot katalógus: minden verzióhoz: – Gyökér címe – Legelső elágazás (ha nincs, akkor NULL) Katalógus levelei: – Összes memnode-nál másolatok – Cache-elés proxiknál

Kérdések?

Köszönöm a figyelmet!