CSR 5. mese: A PebblesDB története

Arra gondoltam, itt az ideje, hogy bekerüljek a saját történetembe. Ez a történet arról, hogy miként jött létre a PebblesDB kulcsértékű tárolónk létrehozása és közzététele a SOSP 17-ben. A történet a VMware Research posztdoktori tapasztalataimat is tartalmazza.

Ez a történet 2015-ben kezdődik, amikor befejeztem a PhD-t. Interjúkat folytattam az iparban és a tudományos életben egyaránt: Valójában azt hittem, hogy nem fogok tudományos ajánlatokat szerezni (nem dolgoztam olyan szexi témákban, mint a felhőalapú számítástechnika vagy a gépi tanulás), de megpróbáltam kipróbálni, mielőtt az iparba távoztam. . Csatlakozni akartam egy olyan ipari kutató laborba, mint a Microsoft Research.

Érdekes, hogy amikor a munkaerőpiacon voltam, a Microsoft Research Silicon Valley néhány tagja új kutatási laboratóriumot indított a VMware-ben. Gyakornoki mentorom, Mahesh Balakrishnan és Marcos Aguilera ebben az új laboratóriumban voltak, tehát ösztönöztek, hogy jelentkezzek. Interjúkat készítettem a laboratóriumban, és nagyszerű tapasztalataim voltak. Ajánlatot tettek arra, hogy kutatóként csatlakozzak.

Interjúba folytattam a különféle egyetemeket, és nagyon szerencsés volt, hogy ajánlatot tettem a Austini Texasi Egyetemen. Felhívtam Dahlia Malkhi-t (a kutatólaboratórium egyik alapító tagját), hogy elmondjam neki a hírt és tájékoztassam neki, hogy nem tudok csatlakozni a VMware Researchhez (vagy a VRG-hez, ahogy nevezik). Ugyanezen a telefonhíváson Dahlia azt javasolta, hogy tegyek egyéves posztdokumentumot, mielőtt csatlakoznék az UT-hez, és felajánlotta, hogy fogadjon engem a VRG-n. Már hallottam a sikeres egyéves posztdokumentumokról (például Philip Guo), és nem igazán akartam azonnal belemerülni a kari életbe, ezért beleegyeztem. Beszéltem az Austin UT népeivel, akik szerencsére rendben voltak azzal, hogy egy évvel elhalasztották a csatlakozási időpontomat.

Amikor csatlakoztam a VRG-hez, kifejezetten arra törekedtem, hogy új kapcsolatokat alakítson ki, és ne csak ugyanazokkal a dolgokkal dolgozhassam, mint a PhD során. Nagyon sok kutatóval beszélt arról, hogy miről dolgoznak, és hogyan tudnék segíteni. Ekkor beszéltem először Ittai Abrahamnel, egy elméleti / adatszerkezeti szakértővel (szakértelme sokkal több területet ölel fel, de ez a legrövidebb módja annak leírására). Ittai elképzelése volt a kulcsérték-tárolók új adatstruktúrájáról, és azt akarta, hogy valaki, aki rendelkezik rendszerrel tapasztalattal, segítsen annak felépítésében. Csatlakoztam arra a gondolkodásra, hogy ez egy gyors egy-három hónapos projekt lesz.

A kezdeti napok kissé durvaak voltak, és a legtöbb, amit Ittai mondott, a fejem fölött ment. A rendszeriek és az elméletek tényleg különböző nyelveket beszélnek, tehát egy ideje volt a szinkronban. A projekt mögött meghúzódó intuíció jobb megértése érdekében elkezdtem egy gyors python prototípus építését, amely megtestesíti az Ittai új adatszerkezetét. Prototípusunk kimutatta, hogy az új adatszerkezet drasztikusan csökkentheti az írási amplifikációt, bár késleltetési idejük szignifikánsan magasabb volt, mint a C ++ kulcsérték-tárolókkal, amelyeket összehasonlítottunk. A PebblesDB korai formáját mutattam be a VMware RADIO konferencián, a VMware belső K + F konferenciáján. A tudományos konferenciáknak viszont nincs semmi a RADIO-val: A RADIO termelési értéke közelebb van a TED-hez, mint egy akadémiai konferencia. Lehetett volna egy kis koncertet ezen a színpadon, és nem lett volna helytelen.

Miután pozitív és hasznos visszajelzést kaptunk a RADIO-nál, Ittai és én úgy döntöttünk, hogy módosítunk egy meglévő kulcsérték-tárolót az új adatszerkezetünk használatához. A LevelDB-t választottuk, mivel ez lényegesen egyszerűbb és könnyebben érthető volt, mint a RocksDB, és módosítani kezdtük. Pontosabban, megkezdtük a HyperLevelDB, a LevelDB kikötőjének módosítását a HyperDex emberek által a Cornellnél (Emin Gun Sirer csoport).

Több pillanatunk is volt, amikor azt feltételeztük, hogy összecsaptak azzal, amit a LevelDB valójában csináltunk: például úgy gondoltuk, hogy egy bináris keresés lesz az egész stabilan, az O (logn) keresés során; Kiderül, hogy az stabilaknak csak indexei vannak, amelyek O (1) keresést eredményeznek.

Ez volt a projekt szórakoztató része, mivel annyira fontos szerepet játszik az elméleti adatstruktúrától a valódi kulcsérték-tároló felépítéséig, amely kiváló teljesítményt nyújt. Számos ismert mérnöki trükköt kellett felhasználnunk a PebblesDB készítéséhez.

A megvalósítás felénél voltunk, amikor véget ért a posztdokumentum, és csatlakoztam az UT-hez. Szerencsére szinte azonnal Pandian csatlakozott a kutatócsoporthoz, és átvette a rendszerépítő részt. Pandian csodálatos rendszerek építője, így hamarosan készen állt a prototípus is. A LevelDB alapján értékeltük, és nagyszerű eredményeket kaptunk. Így felírtuk és elküldtük az Euroys-nak.

Elutasításra kerültünk az Eurosys-en, elsősorban két ok miatt: a RocksDB-vel szemben nem vettünk fel értékelést, és a tervezést sem magyaráztuk meg nagyon jól. Úgy tűnt, hogy inkább egy hackerekkel találkozik a LevelDB számára, mint egy új adatszerkezetként. Tehát el kellett dolgoznunk, és ki kellett értékelnünk a RocksDB-vel szemben, és ki kellett értékelnünk az olyan alkalmazások teljesítményét, mint a HyperDex és a MongoDb a PebblesDB tetején. Ekkor csatlakozott Rohan Kadekodi a projekthez. Rohan egy újabb csodálatos rendszerek építője, és egy hónap múlva nem tudott semmit a MongoDB-ről, és úgy módosította, hogy az a PebblesDB tetején futjon.

Az alkalmazás teljesítményének összehasonlításakor más meglepetéseket kaptunk. Például, mind a HyperDex, mind a MongoDB esetében sok put () kérést get () + put () kérésekké alakítanak át, hogy először ellenőrizzék, van-e már kulcs. Ez jelentősen befolyásolta a PebblesDB teljesítményét, mivel a PebblesDB sokkal több put () kérést tudott kezelni, mint az alkalmazás. Érdekes volt kitalálni ezeket az alkalmazásokat!

Egy másik dolog, amivel foglalkoztunk, az írás volt. A tervezetet kiosztottam a Austin UT rendszercsoportjának. Kiváló visszajelzést kaptunk, és újraírtam a papírt, hogy világossá tegyük, hogy két dolgot csinálunk: az adatszerkezet-innovációt a fragmentált log-strukturált egyesítési fák (FLSM) adatstruktúrája szempontjából, és a PebblesDB felépítését az FLSM tetejére (mentén). a kapcsolódó mérnöki trükkökkel). Különösen a bevezetésről szóló visszajelzés nagyon hasznos volt, és többször is újraírtuk, hogy megkapjuk a pontot. A dokumentumot benyújtottuk az SOSP-hez.

Augusztusban jött a hír: nagyszerű véleményekkel fogadtunk minket! Jó volt tudni, hogy mindez a munka végre megtérül. Pásztorunkkal, a csodálatos Frans Kaashoek-kel együtt dolgoztunk, hogy megválaszoljuk az értékelő megjegyzéseit. Keményen dolgoztunk a kód nyílt forráskódú kiadásaként is a Githubon (ahol ez elég nagy figyelmet kapott: most már 98 csillag!). Dolgoztunk a MongoDB változtatásainak kiadásán is, hogy az a PebblesDB tetején futhasson.

A PebblesDB-vel végzett munkám ráébredt arra, hogy a tárolási veremben az íráserősítés problémájára gondoljak, ezért elkezdtem dolgozni az Austin UT-n. Az ezen a téren végzett előzetes munka eredményeként az ApSys legjobb posztere és az NSF CAREER támogatás jött létre! Tehát összességében sikeres posztdoktori tapasztalat :)

A PebblesDB tapasztalatai:

  • Az írás rendkívül fontos. Erősen úgy érzem, hogy a papír újraírásával töltött idő sokkal többet fizeti ki, mint a kiegészítő kísérletek elvégzéséhez fordított idő (bár az erős értékelés szintén fontos).
  • Az elméleti emberekkel való együttműködés nagyon szórakoztató! Ha megtalálja a megfelelő munkatársakat, az elmélet és a gyakorlat keverékének kidolgozása rendkívül kielégítő kutatásokhoz és sok hatáshoz vezet. A VMware Researchnél hasonló projektek vannak folyamatban, amelyek rendkívül nagyszerűek.
  • Ha csatlakozni kíván az egyetemi közösséghez, nagyon ajánlom egyéves posztdokumentumot, miután befejezte a doktori fokozatát. A posztdokumentum lehetővé tette számomra, hogy levegőt nyújtson a PhD után, új projekteket fedezzek fel, és új kapcsolatokat alakítsunk ki, amelyekkel soha nem lennék.
  • Nagyon javaslom, hogy végezzen egy posztdokumentumot a VMware Researchnél (és nem, ezt nem fizetem meg.) A kutatócsoport elképesztő kutatókkal rendelkezik, akik számos területen mély tapasztalattal rendelkeznek, és a kultúra nagy projektekre irányul, amelyek hosszabb ideig tart, de tartós hatással lesz.