ĮSA pasaka Nr. 5: „PebblesDB“ istorija

Aš supratau, kad atėjo laikas įsitraukti į savo istoriją. Tai istorija apie tai, kaip buvo sukurta ir paskelbta mūsų „PebblesDB“ pagrindinės vertės parduotuvė SOSP 17. Istorijoje taip pat yra mano „post-doc“ patirtis „VMware Research“.

Ši istorija prasideda 2015 m., Kai baigiau mokslų daktaro laipsnį. Aš kalbėjau tiek pramonėje, tiek akademinėje erdvėje: iš tikrųjų maniau, kad nesulaukiu jokių akademinių pasiūlymų (nedirbau tokiomis seksualiomis temomis kaip debesų kompiuterija ar mašinų mokymasis), tačiau norėjau pabandyti tai išbandyti prieš išvykdamas į pramonę. . Norėjau įstoti į pramoninių tyrimų laboratoriją, tokią kaip „Microsoft Research“.

Įdomu tai, kad tuo metu, kai aš buvau darbo rinkoje, keli žmonės iš „Microsoft Research Silicon Valley“ pradėjo naują tyrimų laboratoriją VMware. Mano stažuotės mentoriai Maheshas Balakrishnanas ir Marcosas Aguilera buvo šioje naujoje laboratorijoje, todėl jie paskatino mane kreiptis. Aš daviau interviu laboratorijoje ir turėjau puikią patirtį. Jie man pasiūlė įstoti kaip tyrėjui.

Aš ėjau į interviu įvairiuose universitetuose ir man labai pasisekė, kad nusiųsčiau pasiūlymą Teksaso universitete, Ostine. Paskambinau Dahlia Malkhi (vienai iš mokslinių tyrimų laboratorijos įkūrėjų), kad papasakotų jai naujienas ir praneščiau, kad negalėčiau prisijungti prie „VMware Research“ (arba VRG, kaip ji vadinama). Tuo pačiu telefono skambučiu Dahlia pasiūlė man padaryti vienerių metų doktorantūrą prieš stojant į UT, ir pasiūlė mane priimti į VRG. Aš jau buvau girdėjęs apie sėkmingus vienerių metų doktorantūros dokumentus (pavyzdžiui, Philipas Guo) ir nenorėjau iš karto pasinerti į fakulteto gyvenimą, todėl sutikau. Kalbėjausi su UT Ostino žmonėmis, kurie, laimei, gerai, atidėjo mano prisijungimo datą vieneriems metams.

Kai įstojau į VRG, turėjau aiškų tikslą užmegzti naujus ryšius, o ne tik dirbti tuos pačius dalykus, kuriuos dariau daktaro laipsnio metu. Kalbėjau su daugybe tyrėjų apie tai, ką jie dirba ir kaip galėčiau padėti. Tai buvo tada, kai pirmą kartą kalbėjausi su Ittai Abraham, teorijos / duomenų struktūrų ekspertu (jo patirtis apima daug daugiau sričių, tačiau tai yra trumpiausias būdas jį apibūdinti). Ittai kilo mintis apie naują pagrindinės vertės parduotuvių duomenų struktūrą ir jis norėjo, kad kažkas, turintis sistemų patirtį, padėtų ją sukurti. Aš prisijungiau galvodamas, kad tai bus greitas trijų mėnesių projektas.

Pirmosios dienos buvo šiek tiek grubios, ir dauguma to, ką Ittai sakydavo, eidavo tiesiai per galvą. Sistemos ir teorijos žmonės iš tikrųjų kalba skirtingomis kalbomis, todėl šiek tiek laiko buvome sinchroniškai. Norėdamas geriau suprasti projekto intuiciją, pradėjau kurti greitojo pitono prototipą, įkūnijantį naują duomenų struktūrą, apie kurią mąstė Ittai. Mūsų prototipas parodė, kad naujoji duomenų struktūra gali drastiškai sumažinti rašymo amplifikaciją, nors mūsų delsos buvo žymiai didesnės nei C ++ pagrindinės vertės parduotuvės, su kuriomis mes palyginome. Aš pristačiau ankstyvą „PebblesDB“ formą „VMware RADIO“ konferencijoje, VMware vidinėje mokslinių tyrimų ir plėtros konferencijoje. Tuo tarpu akademinės konferencijos neturi nieko apie RADIJĄ: RADIJO produkcijos vertė yra artimesnė TED vertei nei akademinė konferencija. Jūs galėjote surengti nedidelį koncertą toje scenoje, ir tai nebūtų atrodė ne vietoje.

Gavę teigiamų ir naudingų atsiliepimų RADIJUI, Ittai ir aš pasiryžome pakeisti esamą raktų vertės saugyklą, kad būtų galima naudoti mūsų naują duomenų struktūrą. Mes pasirinkome „LevelDB“, nes jis buvo žymiai paprastesnis ir suprantamesnis nei „RocksDB“, ir pradėjome jį modifikuoti. Tiksliau, mes pradėjome modifikuoti „HyperLevelDB“, „LevelDB“ prievadą, kurį pateikė „HyperDex“ žmonės Kornelyje (Emin Gun Sirer grupė).

Turėjome keletą akimirkų, kai tai, kas, mūsų manymu, susidūrė su tuo, ką „LevelDB“ iš tikrųjų darė: pavyzdžiui, mes manėme, kad visame stabiliame sąraše bus dvejetainė paieška, atliekanti paiešką O (logn); paaiškėja, kad lentelėse yra tik rodyklės, leidžiančios ieškoti O (1).

Tai buvo smagi projekto dalis, nes nuo teorinės duomenų struktūros sukūrimo iki realios pagrindinės vertės saugyklos, užtikrinančios puikius rezultatus, tiek daug reikia. Norėdami sukurti „PebblesDB“, turėjome naudoti daugybę žinomų inžinerinių triukų.

Įpusėjus įgyvendinimui, kai baigėsi mano post-doc, aš įstojau į UT. Laimei, beveik iš karto Pandianas prisijungė prie mano tyrimų grupės ir perėmė sistemos kūrimo dalį. „Pandian“ yra nuostabi sistemų kūrėja, todėl netrukus mes turėjome paruoštą prototipą. Įvertinome tai pagal „LevelDB“ ir gavome puikių rezultatų. Taigi mes jį surašėme ir išsiuntėme „Euroys“.

„Eurosys“ sulaukėme atmetimo, daugiausia dėl dviejų priežasčių: mes nebuvome įvertinę „RocksDB“ ir nelabai paaiškinome projekto. Atrodė, kad daugiau nei „LevelDB“ įsilaužimų krūva nei nauja duomenų struktūra. Taigi mes turėjome dirbti, vertindami „RocksDB“, ir vertindami tokių programų, kaip „HyperDex“ ir „MongoDb“, veikimą „PebblesDB“ viršuje. Tuo metu Rohanas Kadekodi prisijungė prie projekto. Rohanas yra dar vienas nuostabus sistemų kūrėjas, o per mėnesį jis nieko nežinojo apie „MongoDB“ ir modifikavo jį taip, kad jis veiktų „PebblesDB“ viršuje.

Kai mes palyginome programos našumą, sulaukėme ir kitų netikėtumų. Pvz., Tiek „HyperDex“, tiek „MongoDB“ daugelis įvedimo () užklausų būtų paverstos gavimo () + įdėjimo () užklausomis, kad pirmiausia patikrintų, ar raktas jau yra. Tai smarkiai paveikė „PebblesDB“ našumą, nes „PebblesDB“ galėjo patenkinti daug daugiau užklausų, susijusių su įvedimu (), nei programa buvo įmetusi. Vis dėlto buvo įdomu išsiaiškinti, kokie šie taikikliai!

Kitas dalykas, į kurį mes atkreipėme dėmesį, buvo rašymas. Išplatinau mūsų projektą sistemų grupei UT Austine. Gavome puikų atsiliepimą, ir aš perrašiau darbą, kad būtų aišku, jog mes darome du dalykus: duomenų struktūros naujoves pagal fragmentuojamų loginių struktūrų sujungimo medžių (FLSM) duomenų struktūrą ir „PebblesDB“ kūrimą ant FLSM viršaus (kartu su susijusiomis inžinerinėmis gudrybėmis). Visų pirma, atsiliepimai apie įvadą buvo labai naudingi, ir mes kelis kartus jį perrašėme, kad suprastume mintį. Pateikėme dokumentą SOSP.

Rugpjūtį pasirodė naujienos: mes sulaukėme puikių atsiliepimų! Buvo gera žinoti, kad visas darbas pagaliau atsipirko. Mes dirbome su savo piemeniu, nuostabiu Fransu Kaashoeku, kad atsakytume į recenzentų komentarus. Mes taip pat sunkiai dirbome, norėdami išleisti kodą kaip atvirąjį kodą „Github“ (kur jis sulaukė nemažo dėmesio: 98 žvaigždės kaip dabar!). Mes taip pat stengėmės išleisti pakeitimus, kuriuos atlikome „MongoDB“, kad jį būtų galima paleisti virš „PebblesDB“.

Dirbdamas „PebblesDB“ privertiau susimąstyti apie rašymo stiprinimo per saugojimo krūvą problemą, todėl pradėjau ją nagrinėti UT Ostine. Dėl parengiamojo darbo šioje erdvėje buvo gautas geriausias ApSys plakatas ir suteikta NSF KARJERO stipendija! Taigi, sėkminga post-doc patirtis :)

Mano pamokos iš „PebblesDB“ patirties:

  • Rašymas yra nepaprastai svarbus. Aš labai jaučiu, kad laikas, praleistas perrašant darbą, atsiperka kur kas geriau nei laikas, praleistas atliekant papildomus eksperimentus (nors svarbu ir tvirtas įvertinimas).
  • Darbas su teorijos žmonėmis yra labai įdomus! Jei rasite tinkamus bendradarbius, dirbant prie teorijos ir praktikos mišinio, bus atliekama nepaprastai patenkinamų tyrimų ir daug įtakos. „VMware Research“ vykdomi panašūs projektai, kurie yra nepaprastai puikūs.
  • Jei įstosite į akademinę bendruomenę, aš labai rekomenduoju vienerių metų doktorantūrą baigus daktaro laipsnį. Postdokumentas leido man atsikvėpti po daktaro laipsnio, tyrinėti naujus projektus ir užmegzti naujus ryšius, kurių niekada nebūčiau turėjęs.
  • Aš labai rekomenduoju atlikti „VMware Research“ podoktorantūrą (ir ne, man nemoka to sakyti.) Tyrimų grupėje yra nuostabūs tyrėjai, turintys didelę patirtį daugelyje sričių, o kultūra orientuota į didelių projektų, kurie gali užtruks ilgiau, bet turės ilgalaikį poveikį.