CSR Priča br. 8: Zašto su grozne recenzije dobre za vas!

CSR Priča br. 8 dolazi od profesora Barzana Mozafarija u Michiganu. Barzan vodi istraživačku skupinu koja je dizajnirala novu generaciju skalabilnih baza podataka koristeći napredne statističke modele. Nedavno su MySQL i MariaDB prihvatili njihov algoritam za zakazivanje zaključavanja PDV-a, pa sam razgovarao s Barzanom o tome kako se obavlja posao VATS-a. Razgovarao sam i s jednim od njihovih industrijskih suradnika, Sunny Bains iz Oraclea, kako bih upoznao industrijsku stranu ove priče. Sve u svemu, to je sjajna CSR priča! Prvo, čujmo od Barzana:

Bilo je ljeto 2013. Upravo sam započeo kao profesor na Sveučilištu u Michiganu i pokušavao sam smisliti na čemu ću raditi. Tijekom svog postdoc-a na MIT-u, dao sam doprinos u nizu različitih projekata, od analitike (npr. BlinkDB), transakcija i računalstva u oblaku (npr. DBSeer) do gužve. Od ovih, DBSeer je bio daleko najteži izazov koji sam ikad bio ispunjen. Cilj DBSeera bio je predvidjeti performanse sustava baza podataka (u ovom slučaju MySQL) s obzirom na radno opterećenje. Tijekom gotovo dvije godine isprobao sam svaki algoritam strojnog učenja u udžbeniku. Iako smo imali određeni uspjeh u predviđanju utroška resursa (npr. Disk IO ili CPU), naši su rezultati bili osrednji kada je u pitanju predviđanje stvarne kašnjenja transakcije.

Dva su temeljna razloga za to. Prvo smo odlučili da nas zanimaju samo nametljiva rješenja. Na primjer, gledali smo samo varijable globalnog statusa MySQL-a. To je značilo da nismo imali pristup nekim kritičnim statistikama samo zato što ih MySQL nije izložio. (Peloton-ov projekt Andyja Pavla sjajan je način rješavanja ovog prvog problema putem pristupa unutrašnjosti baze podataka). Ali, tada, naša je osnova bila da ako to uspijemo, prihvaćanje DBSeera će postati ne-glavno. Drugi je razlog bio mnogo jasniji: MySQL jednostavno nije mogao započeti s početkom! Možete poslati isti upit pod istim uvjetima više puta, a i dalje ćete dobiti različita kašnjenja svaki put! Uz ovoliko buke u signalu, nema mnogo posla s strojnim učenjem. To je tako jednostavno. I moram napomenuti da ovo nije samo MySQL: svaki drugi DBMS koji smo pogledali bio je jednako nepredvidiv. "Naši preci, kada su dizajnirali te naslijeđene sustave, bili su previše usredotočeni na to da bi ih brže postigli, pa kao rezultat nisu imali luksuz brinuti se o svojoj predvidljivosti." Ili se barem tako činilo.

Tako sam, tek započevši u Michiganu, shvatio da postoji sjajna prilika da se to jednom zauvijek promijeni: učinimo sustave baza podataka predvidivim, a ne samo bržim. Nedavno sam zaposlio Jiamina Huanga, impresivnog učenika s nevjerojatnim sustavnim vještinama. Krenuli smo u dešifriranje onoga što može uzrokovati nepredvidivost. Naš prvi osumnjičeni bio je nedostatak predmemorije L2. Udružili smo se s jednim mojim hardverskim kolegom (Tom Wenisch) kako bismo istražili ovaj i niz drugih potencijalnih uzroka, ali vrlo brzo bilo je nemoguće poduhvat da se to riješi ručno, s obzirom na to koliko je složena MySQL baza podataka. Ubrzo smo pronašli svoj vlastiti profil koji je, za razliku od Dtracea i drugih profila, posebno dizajniran kako bi pronašao korijenske uzroke varijance performansi u velikoj i složenoj bazi podataka. Pokazalo se da naš profiler nije specifičan za baze podataka, a na kraju smo ga pretvorili u VProfiler i kasnije ga objavili na EuroSysu 2017. Došlo je do pregleda milijunskih redaka koda, a zatim i informiranja programera o nekoliko potrebnih para funkcija koje trebate koristiti kako bi vašu aplikaciju učinili predvidivom.

Dio naših baza podataka ima mnogo zanimljiviju priču. VProfiler je otkrio hrpu krivca za izazivanje nepredvidivosti. Na primjer, jedno od naših otkrića bilo je da je u MySQL "čekanju" iza zajedničkih resursa glavni uzrok odstupanja kašnjenja. Zauzvrat, to je vrlo intuitivno: kada N transakcije čekaju u redu za isti zajednički resurs, onaj ispred čekanja iskusit će vrlo različito vrijeme čekanja od onog na kraju čekanja, a obje su biti će vrlo različit od onog na sredini reda. Zbog toga završavaju s različitim kašnjenjima za obavljanje iste količine posla.

Ukratko, preusmjerili smo fokus na način upravljanja redovima i šokantno smo shvatili da svaka pojedinačna baza podataka u svijetu još uvijek koristi neku varijantu FIFO-a (prvi-u, prvi-izlazak). Osmislili smo novi algoritam, nazvan VATS (Variance-Aware Transaction Scheduling), kako bi smanjio varijancu i objavio ga u našem radu SIGMOD 2017 („Pristup odozdo prema dolje za postizanje predvidljivosti performansi u sustavima baza podataka“). Jedan od sjajnih uvida koji se nudi bio je da predvidivost ne mora doći po cijeni prosječnih performansi. Drugim riječima, postoji način da se sustavi postanu predvidljiviji, a istovremeno i učine bržim: smanjujući varijancu na temelju suprotnosti.

Kasnije smo formulirali opći problem rasporeda zaključavanja. Istražili smo drukčiji, novi algoritam koji je bio optimalan za smanjenje prosječne latencije (i povećanje propusnosti) i objavljen u VLDB 2018 („Raspored zaključavanja koji je svjestan ograničenja za transakcijske baze podataka“). Ovaj novi algoritam nazvali smo VATS 3.0 (nikad nismo objavili VATS 2.0) koji smo kasnije nazvali CATS (Contention-Aware Transaction Scheduling).

Raspored svjesnih ograničenja i ograničenja: Dodjeljivanje zaključavanja na O1 do t1 omogućava više paralelizma (smanjuje više kontroverze) nego dodijelivanje t2

Iz perspektive prihvaćanja industrije, stvari su išle prilično glatko: i MySQL i MariaDB izvršili su vlastita mjerila s našim novim algoritmom i odlučili ga usvojiti u samostalnim verzijama (MySQL ih je čak učinio kao svoju zadanu strategiju). Zahvaljujemo svim suradnicima s otvorenim kodom u MySQL zajednici, uključujući neprocjenjive povratne informacije i pomoć Jana Lindstroma (MariaDB), Sunny Bains i Dimitrija Kravtchua (Oracle), Laurynas Biveinis i Alexey Stroganov (Percona), Marka Callaghana ( Facebook) i Daniel Black (IBM).

S akademskog stajališta, međutim, stvari nisu tekle tako glatko. Evo vremenske trake onoga što se dogodilo:

Izjava o odricanju odgovornosti: Neki od imena / godina konferencije možda su različiti

  • SIGMOD'16: Podnijeli smo svoje MySQL rezultate.
  • Odbacivanje: "Kako možemo znati da li djeluje za nešto drugo osim za MySQL?"

Komentar: Zanimljivo je da komentare poput ovog dobivate samo kada primijenite svoju ideju na pravi sustav. Ako ideju jednostavno nacrtate ispočetka i kreirate bazu podataka, obično nitko neće pitati primjenjuje li se na druge stvarne sustave! Neprihvaćen tim komentarima, moj student je odlučio dokazati recenzentu krivo ...

  • VLDB'16: VProfile smo primijenili i na Postgres i VoltDB.
  • Odbacivanje: "Da je ovaj problem bio dovoljno važan, to bi do sada učinio netko drugi!"

Komentar: Do danas mi je to još uvijek jedna od najdražih recenzija! Primanje nepravedne recenzije nikada nije zabavno, ali ovo je bilo tako smiješno da nas nije mučilo - u stvari smo ga smatrali prilično zabavnim. Iako želimo da smo imali priliku postaviti tom pitanju dva pitanja:

1) Mjeri li recenzent svoje vlastito istraživanje prema istoj traci? (Znamo da je to bio on; pogledajte Lekciju 5.)

2) Kako bismo uopće mogli postići napredak u istraživanju primjenom ovog načela? Ako je nešto već učinjeno, onda nije novo i objavljivo, a ako to nije učinjeno, onda jednostavno nije dovoljno važno i ne smije imati smisla objavljivati ​​ih!

  • OSDI'16: Ipak, moj je student još jednom odlučio dokazati recenzent u krivu i dokazati da je problem stvaran. Stoga smo svoje algoritme i rezultate poslali i MariaDB i MySQL. MySQL je preuzeo MySQL kao zadani raspored i spomenuli smo ga u radu.
  • Odbacivanje: "Primijenili ste VProfiler na MySQL, Postgres i VoltDB. Kako možemo znati funkcionira li za bilo što osim DBMS-a? "

Komentar: To je prilično zabrinjavalo. Uostalom, OSDI je konferencija o OS-u. U stvari smo bili jako zadovoljni kvalitetom recenzija koje smo dobili. Kao DB istraživač, uvijek zavidim OS zajednici na njihovom znatno boljem sustavu pregleda.

  • SIGMOD’17: Podnijeli smo PDVS i ostale nalaze baze podataka.
  • Prihvatiti! Konačno!
  • EuroSys'17: Generalizirali smo naš profil, koji je kasnije postao VProfiler i primijenjen na Apache Web Server pored sustava baza podataka.
  • Prihvatiti! Yay!
  • VLDB18: Konačno, nakon što smo uspjeli formalizirati problem zakazivanja zaključavanja, uspjeli smo riješiti i performanse (ne samo predvidljivost). Ovo je postao CATS algoritam.
  • Prihvatiti. Zapravo smo dobili sjajne kritike od VLDB18. Također smo dobili izvanredne povratne informacije od Petera Bailisa nakon objavljivanja rada.

Evo nekoliko lekcija iz ovog dugog posta:

Lekcija 1. Grozne kritike zapravo su dobre za vas. Oni vas (i vašeg učenika!) Guraju da radite više, što i nije loš ishod!

Lekcija 2. Ne vjerujte onome što ljudi kažu na ploči. Iako bi svi u akademskim krugovima vodili evidenciju o vrednovanju utjecaja u stvarnom svijetu i validacija u stvarnom svijetu, neki od njih ponekad podsvjesno lažu. Kad nose šešir za recenziju, oni često kažnjavaju papire koji koriste pravi sustav za ocjenjivanje, na primjer, tražeći milijardu drugih stvari koje bi bile moguće samo ako koristite simulaciju prototipa. Ne mislim da biste trebali odustati od korištenja stvarnih sustava u svojim eksperimentima, već jednostavno budite spremni za više posla!

Lekcija 3. Akademija i industrija imaju različite valne duljine. Za one od nas u akademiji, tri mjeseca se osjećaju kao vječnost. Međutim, timovi proizvoda pokreću se na vlastitoj vremenskoj traci - ponekad može potrajati i godinu dana prije nego što za vas dobiju neki ciklus. Trebate samo biti strpljivi i cijeniti veliki posao koji rade u održavanju visokokvalitetnog otvorenog koda eko sustava.

Lekcija 4. Nije svaki recenzent matematičar. U jednoj od naših ranijih prijava izvijestili smo o postotku ukupne varijance koju smo eliminirali, a to je bilo oko 65%. Očito ništa ne možete eliminirati više od 100%. Nažalost, to je samo ograničenje matematičkih zakona. Ali jedna od naših recenzija (mislim da SIGMOD'16 ili VLDB'16) je mišljenja da smanjenje od 65% nije dovoljno značajno. Dakle, u našem sljedećem podnesku prešli smo na izvješće o omjeru poboljšanja, definirano kao varijanca izvornog MySQL-a podijeljeno s varijancijom naše modificirane verzije. O istom 65-postotnom sniženju sada je riječ o 3-puta smanjenju varijance, a recenzenti (iako vjerojatno različiti ljudi) bili su sretniji ovaj put.

Lekcija 5. Budite ljubazni ili budite anonimni. Ovo se odnosi na našeg omiljenog recenzenta: Ako ćete pisati gadnu recenziju, vjerovatno nije dobra zamolba autora da navedu tri vlastita rada. To se ne slaže sa održavanjem anonimnosti ☺

Lekcija 6. Rad na stvarnim sustavima je bol, ali potpuno se isplati. Ako se volite nositi s lošim recenzijama i znatno dužim pregledom vremena, rad na stvarnim sustavima izuzetno je korisno iskustvo!

Omogućuje prelazak na industrijsku perspektivu ovog djela. Razgovarao sam s Sunny Bains iz Oraclea koji je bio presudan za uvođenje PDV-a u MySQL / InnoDB. Svoj razgovor s njim predstavljam kao pitanja i odgovori.

CSRTales: Kako ste najprije naučili o radu CATS-a?

Sunny: IIRC Barzan i Jiamin objavili su rad s referentnim vrijednostima i to mi je proslijedio netko iz naše organizacije. Zatim su doprinijeli zakrpu što me je zanimalo. Za zaključavanje je uvijek potrebna neka ili drugačija optimizacija, a u to smo vrijeme razmišljali u optimizaciji InnoDB upravitelja zaključavanja. Stoga je bilo vrlo pravovremeno. CATS kako su ga tada zvali izgledao je kao kandidat koji obećava. U toj fazi smo bili preusko usredotočeni na jednoliku distribuciju i nismo vidjeli nikakve dobitke. Također, fokus se pomaknuo na popravljanje drugih stvari u InnoDB-u. Nakon što smo dobili dobra rješenja za ostala pitanja oko upravljanja transakcijama unutar InnoDB-a, problemi zaključavanja ponovno su došli u prvi plan. Tim InnoDB-a počeo je ponovno gledati CATS i slučajno mi je Mark Callaghan s Facebooka već sljedećeg dana poslao e-poštu upoznavši me s Barzanom i Jiaminom. Nakon toga započela je bliža suradnja, a izravnom komunikacijom i njihovom pomoći sve je bilo nizbrdo.

CSRTales: Što vam se najviše svidjelo u vezi s CATS-om kada ste čuli za nju?

Sunny: Riješio je stvarni problem, a sam je sadržaj vrlo općenit i mislim da ima aplikacije i izvan upravitelja zaključavanja. Jednako je važno iz praktične perspektive i to da je došao uz dokaz koncepta. Flaster koji bismo mogli odmah testirati. Mnogo je dobrih ideja koje lebde okolo. Ogroman plus za testiranje je nešto konkretno. To nam štedi puno vremena i resursa. Također mislim da je to jedna od prednosti softvera otvorenog koda. Ovo je vrlo dobar primjer za to.

CSRTales: Koliko je vremena trebalo od prvog slušanja o radu do njegovog spajanja?

Sunny: Mislim da je trebalo oko godinu dana. Od kada smo se odlučili na to obvezati i do vremena kada ga je zapravo gurnuo prošlo je šest mjeseci. Naš QA proces je vrlo rigorozan i ne mogu se dovoljno zahvaliti našem QA-u. U originalnom flasteru bilo je nekih pogrešaka. Odlučili smo ga i prepisati. Također želimo smanjiti broj varijabli konfiguracije kao politike. Bilo je problema s zaključavanjem praznina koje je bilo potrebno popraviti u zakrpi.

CSRTales: Obično u zajednicama otvorenog koda, kao što je Linux kernel, morate imati kredibilitet već izgrađen prije nego što se zakrpe prihvate. Pretpostavljam da se ovdje dogodilo nešto slično?

Sunny: Naravno. Dobivamo poprilično zakrpa / priloga. Ali želio bih naglasiti da to nije preduvjet. Otvoreni smo za prihvaćanje zakrpa koje djeluju izvan okvira i imamo dokumentaciju koja pokazuje problem i kako zakrpe ispravljaju te probleme. Naša je istinska želja potaknuti istraživače / korisnike / programere svih koji imaju interes na ovom polju da iskoriste prednost otvorenog koda i pošalju nam svoje zakrpe. Želio bih naglasiti, razgovor je jeftin. Pokaži mi kôd :-)

CSRTales: Je li uobičajena praksa prepisivanja zakrpa koje su pridonijele?

Sunny: Da, nakon što se odlučimo posvetiti nekom poslu, radije ćemo to raditi u potpunosti u timu. Za to postoje praktični razlozi. Proces QA prilično je intenzivan i postoji čitava infrastruktura oko pregledavanja koda i praćenja problema kojima stranci neće imati pristup. Također, osoba koja izvrši kôd mora preuzeti vlasništvo za kasnije ispravke programskih pogrešaka itd. To je uglavnom zbog praktičnosti da ne dobijemo originalne autore da rade kako napreduje. Mi smo (zapravo jesam) prepravili zakrpu. Stalno je razmjenjivala e-poštu između Jiamina, Dimitrija, Barzana i mene kako smo razgovarali o problemima. Dimitri je naš arhitekt za izvedbu. Njihov doprinos bio je vrlo koristan u osiguravanju da svi imamo isti mentalni model oko svojih ideja.

Želio bih istaknuti nekoliko zanimljivih stvari u ovom CSRTale-u. Prvo, ovo je sjajan primjer kako doći do usvajanja u industriji. Barzan i njegova skupina pridonijeli su flasteru koji se mogao izravno testirati. Ovo je presudno. Drugo, Barzan i njegova skupina proveli su mnogo vremena razgovarajući o svojoj ideji sa Sunnyom kako bi se uvjerili da se nalaze na istoj stranici. Prijenos tehnologije zahtijeva puno vremena iznad i izvan vremena provedenog na objavljivanju rada. Ako tražite utjecaj, ovo je sjajan put, ali budite svjesni vremenskih troškova. Treće, recenzija kvalitete nije baš konzistentna u širokoj zajednici sustava. Vidio sam kritike slične onima koje je Barzan dobio: pretpostavljam da se pojedini recenzenti (ne svi sa srećom) prvo odluče, a zatim pokušaju naći bilo kakav izgovor za odbacivanje rada. Stoga su ponekad recenzije vrlo bučni signali: mogli biste pomisliti da biste popravili ono što je recenzent tražio, i vi ćete biti prihvaćeni, ali to nije često slučaj. Možda postoje druge slabosti u vašem dokumentu koje biste mogli bolje potrošiti na popravljanje vremena. Na primjer, ako ideje iz vašeg rada nisu naišle na jasan način, recenzentu se možda neće svidjeti vaš rad, i žalite se na procjenu. Popravak evaluacije (bez popravljanja pisanja) ne bi poboljšao vaše šanse za prihvaćanje. Razgovarajte sa svojim savjetnicima o ovome :)