Zgodba o CSR št. 8: Zakaj grozni pregledi so dobri za vas!

Zgodba o CSR št. 8 prihaja od profesorja Barzana Mozafarija v Michiganu. Barzan vodi raziskovalno skupino, ki oblikuje novo generacijo razširljivih baz podatkov z uporabo naprednih statističnih modelov. Pred kratkim sta MySQL in MariaDB sprejela njun algoritem za načrtovanje zaklepanja DDV, zato sem z Barzanom poklepetal, kako je treba opraviti delo DDV. Klepetal sem tudi z enim od njihovih industrijskih sodelavcev, Sunny Bains iz Oracle, da sem dobil industrijsko plat te zgodbe. Na splošno je to odlična zgodba o CSR! Najprej slišimo od Barzana:

Bilo je poletje 2013. Pravkar sem začel kot profesor na univerzi v Michiganu in sem poskušal ugotoviti, na čem bom delal. Med svojim postdoc na MIT-u sem prispeval k številnim različnim projektom, od analitike (npr. BlinkDB), transakcij in računalništva v oblaku (npr. DBSeer) do množice. Od teh je bil DBSeer daleč najtežji izziv, ki sem ga kdajkoli sprejel. Cilj z DBSeer je bil predvideti zmogljivost sistema baz podatkov (v tem primeru MySQL) glede na delovno obremenitev. Skoraj dve leti sem preizkusil vsak algoritem strojnega učenja v učbeniku. Čeprav smo imeli nekaj uspeha pri napovedovanju porabe virov (npr. IO diska ali CPU), so bili naši rezultati povprečni, ko smo šli za napovedovanje dejanske zamude transakcije.

Za to sta bila dva temeljna razloga. Najprej smo se odločili, da nas zanimajo samo vsiljive rešitve. Na primer, razmišljali bomo le o spremenljivkah globalnega stanja MySQL. To je pomenilo, da nismo imeli dostopa do nekaterih kritičnih statistik zgolj zato, ker jih MySQL ni izpostavil. (Projekt Pelotona Andyja Pavla je odličen način za reševanje te prve težave z dostopom do notranjosti baze podatkov). Toda takrat je bila naša utemeljitev, da če sprejmemo to delo, bi sprejetje DBSeer-a postalo brez možganov. Drugi razlog je bil veliko bolj preprost: MySQL ni bil najprej predvidljiv sistem! Pod enakimi pogoji lahko večkrat pošljete natančno isto poizvedbo, vendar boste vsakič dobili vedno različne zamude! S tako veliko hrupa v signalu ni ravno veliko storiti za strojno učenje. To je tako preprosto. Moram poudariti, da to ni bil samo MySQL: vsi drugi DBMS, ki smo jih gledali, so bili prav tako nepredvidljivi. "Naši predniki, ko so oblikovali te zapuščene sisteme, so bili preveč osredotočeni na to, da bi jih naredili hitreje, in zato niso imeli razkošja, da bi skrbeli za svojo predvidljivost." Ali vsaj tako se je zdelo.

Tako sem bil, ko sem šele začel v Michiganu, in ugotovil, da obstaja velika priložnost, da to spremenim enkrat za vselej: naredimo sisteme baz podatkov bolj predvidljive, ne le hitrejše. Pred kratkim sem zaposlil Jiamina Huanga, impresivnega študenta z neverjetnimi sistemskimi znanji. Odločili smo se razvozlati, kaj lahko povzroči nepredvidljivost. Naš prvi osumljenec so bili pogreški predpomnilnika L2. Združili smo se z enim od mojih kolegov s strojno opremo (Tom Wenisch), da bi raziskali to in številne druge možne vzroke, vendar je bilo zelo hitro nemogoče podvig rešiti to ročno, glede na to, kako zapletena je bila zbirka kode MySQL. Kmalu smo se znašli v ustvarjanju lastnega profilerja, ki je bil za razliko od Dtrace in drugih profilov zasnovan posebej za iskanje temeljnih vzrokov za odstopanje zmogljivosti v veliki in zapleteni zbirki kod. Izkazalo se je, da naš profiler ni bil specifičen za podatkovne baze, zato smo ga na koncu pretvorili v VProfiler in ga pozneje objavili na EuroSysu 2017. Zdelo se je, da je pogledal na milijone vrstic kode in nato obvestil razvijalca o nekaj potrebnih parih funkcij, ki jih želite uporabiti, da bo vaša aplikacija predvidljiva.

Del naših ugotovitev v bazi podatkov ima veliko bolj zanimivo zgodbo. VProfiler je razkril kup krivcev za povzročanje nepredvidljivosti. Na primer, ena od naših ugotovitev je bila, da je bil v vrsti MySQL "čakanje v vrsti" za deljenimi viri glavni vzrok za odstopanje zamud. V zadnjem času je to zelo intuitivno: ko N transakcij čaka v čakalni vrsti za isti deljeni vir, bo ta pred čakalno vrsto doživela zelo drugačen čas čakanja kot tisti na koncu čakalne vrste in obe sta bo zelo drugačen od tistega na sredini čakalne vrste. Zato na koncu prikažejo zelo različne zamude pri opravljanju iste količine dela.

Kratka zgodba je bila usmerjena k temu, kako se upravljajo čakalne vrste in šokantno smo ugotovili, da vsaka posamezna baza podatkov na svetu še vedno uporablja neko različico FIFO (prva, prva). Izdelali smo nov algoritem, imenovan VATS (Variance-Aware Transaction Scheduling), s katerim smo zmanjšali odstopanje, in ga objavili v našem prispevku SIGMOD 2017 ("pristop od zgoraj navzdol za doseganje predvidljivosti učinkovitosti v sistemih baz podatkov"). Eden od odličnih primerov, ki jih je ta ponudil, je bil, da predvidljivosti ni treba doseči po ceni povprečne učinkovitosti. Z drugimi besedami, obstaja način, kako narediti sisteme bolj predvidljive, hkrati pa jih tudi narediti hitrejše: z zmanjšanjem odstopanja na osnovi prepira.

Kasneje smo oblikovali splošni problem načrtovanja zaklepanja. Raziskali smo drugačen, nov algoritem, ki je bil optimalen za zmanjšanje povprečne zamude (in povečanje pretoka) in objavljen v VLDB 2018 ("Zaznavanje zaklepnega načrtovanja zaklepanja za transakcijske baze podatkov"). Novi algoritem smo poimenovali VATS 3.0 (nikoli nismo objavili VATS 2.0), ki smo ga pozneje poimenovali CATS (Contention-Aware Transaction Scheduling).

Razpored načrtovanja transakcij, ki se zaveda omejitev: Dovoljenje zaklepanja na O1 do t1 omogoča več vzporednosti (zmanjšuje več prerekanja) kot dodelitev t2

Z vidika sprejemanja v panogo so šle stvari precej gladko: tako MySQL kot MariaDB sta z lastnim novim algoritmom določila lastna merila uspešnosti in se odločila, da ga bosta uporabila v svojih samostojnih različicah (MySQL je celo naredil svojo privzeto strategijo). Hvaležni smo vsem našim odprtokodnim sodelavcem v skupnosti MySQL, vključno z neprecenljivimi povratnimi informacijami in pomočjo Jana Lindstroma (MariaDB), Sunny Bains in Dimitrija Kravtchua (Oracle), Laurynas Biveinis in Alekseja Stroganova (Percona), Marka Callaghana ( Facebook) in Daniel Black (IBM).

Z akademskega stališča pa stvari niso tekle tako gladko. Tu je časovnica, kaj se je zgodilo:

Izjava o omejitvi odgovornosti: Nekatera imena / leta konference so lahko drugačna

  • SIGMOD'16: Predložili smo rezultate MySQL.
  • Zavrnitev: "Kako vemo, ali deluje za kaj drugega kot za MySQL?"

Komentar: Zanimivo je, da komentarje, kakršen je ta, prejmete le, ko svojo idejo uporabite v resničnem sistemu. Če preprosto oblikujete svojo idejo iz nič in ustvarite bazo podatkov, običajno nihče ne bo vprašal, ali velja za druge prave sisteme! Moj študent ni bil navdušen nad temi komentarji in se je odločil, da bo dokazal narobe.

  • VLDB'16: VProfile smo uporabili tudi za Postgres in VoltDB.
  • Zavrnitev: "Če bi bil ta problem dovolj pomemben, bi to storil že nekdo drug!"

Komentar: Do danes mi je to še vedno eno najljubših ocen! Prejemanje nepoštenega pregleda ni nikoli zabavno, toda ta je bil tako smešen, da nas ni motil - pravzaprav smo se mu zdeli precej zabavni. Čeprav bi radi imeli možnost, da vprašalcu postavimo dve vprašanji:

1) Ali ocenjevalec oceni svoje lastno raziskovanje z isto lokacijo? (Vemo, da je šlo za »on«; glej lekcijo 5.)

2) Kako bi lahko sploh dosegli napredek na področju raziskav z uporabo tega načela? Če je nekaj že narejeno, potem ni novo in objavljeno, in če ni bilo storjeno, potem preprosto ni dovolj pomembno in ne sme biti smisla, da bi jih objavljali!

  • OSDI’16: Kljub temu se je moj študent še enkrat odločil, da bo pregledalca zmotil in dokazal, da je težava resnična. Tako smo svoje algoritme in rezultate poslali v MariaDB in MySQL. MySQL je izbral MySQL kot privzeto načrtovanje in to smo omenili v prispevku.
  • Zavrnitev: »VProfiler ste uporabili v MySQL, Postgres in VoltDB. Kako vemo, ali deluje za kaj drugega kot za DBMS? "

Komentar: To je bila poštena skrb. Konec koncev je OSDI konferenca OS. S kakovostjo pregledov smo bili pravzaprav zelo zadovoljni. Kot raziskovalec DB-ja vedno zavidam skupnosti OS zaradi njihovega bistveno boljšega sistema pregledovanja.

  • SIGMOD’17: Predložili smo DDV in druge ugotovitve zbirke podatkov.
  • Sprejmi! Končno!
  • EuroSys'17: Posplošili smo naš profil, ki je kasneje postal VProfiler in se poleg sistemov baz podatkov uveljavil tudi na spletnem strežniku Apache.
  • Sprejmi! Juhu!
  • VLDB´18: Nazadnje, ko smo uspeli formalizirati težavo z načrtovanjem zaklepanja, smo lahko rešili tudi za uspešnost (ne samo predvidljivost). To je postal algoritem CATS.
  • Sprejmi. Pravzaprav smo dobili odlične ocene od VLDB18. Od objave prispevka smo dobili tudi izjemne povratne informacije od Petra Bailisa.

Tukaj je nekaj lekcij iz te dolge objave:

Lekcija 1. Grozljivi pregledi so pravzaprav dobri za vas. Te (in tvojega študenta!) Silijo k večjemu delu, kar ni slab rezultat!

Lekcija 2. Ne zaupaj, kaj pravijo ljudje na ploščah. Čeprav bi se vsi v akademskem krogu zapisovali glede vrednotenja vpliva v resničnem svetu in potrditev resničnega sveta, nekateri med njimi včasih podzavestno lažejo. Ko nosijo klobuk za pregledovalce, pogosto kaznujejo papirje, ki uporabljajo resničen sistem za ocenjevanje, na primer tako, da zaprosijo za milijardo drugih stvari, ki bi bile možne le, če bi uporabil prototipno simulacijo. Ne mislim, da bi se morali v svojih poskusih odpovedati uporabi resničnih sistemov, ampak preprosto biti pripravljeni na več dela!

Lekcija 3. Akademije in industrija imajo različne valovne dolžine. Za tiste, ki smo v akademiji, se trije meseci počutijo kot večnost. Skupine izdelkov pa se izvajajo po svoji časovni premici - včasih lahko traja tudi leto dni, preden za vas naredijo kakšen cikel. Samo morate biti potrpežljivi in ​​ceniti njihovo veliko delo pri ohranjanju kakovostnega odprtokodnega eko sistema.

Lekcija 4. Vsak recenzent ni matematik. V eni od prejšnjih stališč smo poročali o odstotku skupne odstopanja, ki smo ga odpravili, kar je bilo približno 65%. Očitno ničesar ne morete odpraviti za več kot 100%. Žal je to le omejitev zakonov matematike. Toda eden od naših pregledov (mislim, da je SIGMOD'16 ali VLDB'16) je bil mnenja, da 65-odstotno znižanje ni dovolj pomembno. Tako smo v naslednji predstavitvi prešli na poročanje o razmerju izboljšav, ki je opredeljeno kot varianca izvirnega MySQL, deljeno z variacijo naše spremenjene različice. O istem 65-odstotnem zmanjšanju so zdaj poročali kot o 3-kratnem znižanju odstopanja, recenzenti (čeprav verjetno različni ljudje) pa so bili tokrat srečnejši.

Lekcija 5. Bodite prijazni ali bodite anonimni. To velja za našega najljubšega recenzenta: Če boste napisali grdo mnenje, verjetno ni dobro, da bi od avtorjev zahtevali, da navajajo tri svoje prispevke. Z vzdrževanjem anonimnosti se ne gre dobro ☺

Lekcija 6. Delo na resničnih sistemih je bolečina, vendar je povsem vredno. Če ste pripravljeni navajati slabe ocene in bistveno daljši čas za pisanje papirja, je delo na resničnih sistemih izredno koristna izkušnja!

Preklopite na industrijsko perspektivo tega dela. Klepetal sem s Sunny Bains iz Oracle, ki je pripomogla k sprejemanju DDV v MySQL / InnoDB. Svoj pogovor z njim predstavljam kot vprašanja in vprašanja.

CSRTales: Kako ste se najprej naučili o delu CATS?

Sunny: IIRC Barzan in Jiamin sta objavila prispevek z referencami, ki mi ga je posredoval nekdo v naši organizaciji. Nato so prispevali obliž, kar me je zanimalo. Zaklepanje vedno potrebuje določeno optimizacijo ali drugo in takrat smo razmišljali o optimizaciji upravitelja ključavnic InnoDB. Zato je bilo zelo pravočasno. CATS, kot so ga takrat imenovali, se je zdel obetaven kandidat. Na tej stopnji smo bili preozko osredotočeni na enotno distribucijo in nismo videli nobenih koristi. Tudi fokus se je preusmeril na popravljanje drugih stvari v InnoDB. Ko smo imeli nekaj dobrih rešitev v zvezi z upravljanjem transakcij znotraj InnoDB, so težave z zaklepanjem ponovno izstopale. Ekipa InnoDB je začela ponovno gledati CATS in po naključju mi ​​je že naslednji dan Mark Callaghan s Facebooka poslal e-sporočilo, v katerem sta me predstavila Barzan in Jiamin. Zatem se je začelo tesnejše sodelovanje in z neposredno komunikacijo in njihovo pomočjo je bilo vse od tam navzdol.

CSRTales: Kaj vam je bilo najbolj všeč pri ideji CATS, ko ste slišali za to?

Sunny: Odpravila je resnično težavo, sama vsebina pa je zelo splošna in mislim, da ima aplikacije zunaj upravitelja zaklepanja. Prav tako pomembno s praktičnega vidika je, da je prišel z dokazilom koncepta. Obliž, ki smo ga lahko preizkusili takoj. Naokoli plava veliko dobrih idej. Ogromen plus je imeti nekaj konkretnega za preizkus. Prihrani nam veliko časa in sredstev. Mislim tudi, da je to ena od prednosti odprtokodne programske opreme. To je zelo dober primer tega.

CSRTales: Koliko časa je trajalo od prvega zaslišanja o delu do združitve?

Sunny: Mislim, da je trajalo približno eno leto. Od tega, ko smo se odločili, da se bomo zavezali, in do trenutka, ko se je dejansko potisnil, je trajalo šest mesecev. Naš postopek zagotavljanja kakovosti je zelo strog in ne morem se dovolj zahvaliti naši kakovosti. V originalni obliži je bilo nekaj hroščev. Odločili smo se, da ga bomo tudi prepisali. Prav tako želimo zmanjšati število spremenljivk konfiguracije kot pravilnika. Bilo je nekaj težav z zapornicami, ki jih je bilo treba popraviti v obližu.

CSRTales: Običajno je treba v odprtokodnih skupnostih, kot je Linux jedro, imeti verodostojnost, že pred sprejetjem popravkov. Ugibam, da se je tukaj zgodilo kaj podobnega?

Sunny: Seveda. Dobimo kar nekaj popravkov / prispevkov. Vendar bi rad poudaril, da to ni predpogoj. Odprti smo za sprejemanje popravkov, ki delujejo zunaj polja, in imamo nekaj dokumentacije, ki prikazuje težavo in kako popravki odpravijo te težave. Naša resnična želja je, da bi raziskovalce / uporabnike / razvijalce spodbudili vsi, ki jih zanima to področje, da izkoristijo prednost odprtokodnih virov in nam pošljejo svoje popravke. Rad bi poudaril, pogovor je poceni. Pokaži mi kodo :-)

CSRTales: Ali je običajna praksa za prepisovanje prispelih popravkov?

Sunny: Ja, ko se enkrat odločimo, da se bomo zavezali nekemu delu, potem raje to storimo v celoti v skupini. Za to obstajajo praktični razlogi. Postopek zagotavljanja kakovosti je precej intenziven in obstaja cela infrastruktura, ki temelji na pregledih kod in sledenju izdaje, do katerih zunanji uporabniki ne bodo imeli dostopa. Tudi oseba, ki pošlje kodo, mora prevzeti lastništvo za poznejše popravke napak itd. Večinoma je to zaradi praktičnosti, da pri napredovanju dela ne pridobimo izvirnih avtorjev. Mi (pravzaprav sem ga) obliž smo prepisali. Med Jiaminom, Dimitrijem, Barzanom in menoj sem nenehno izmenjeval e-pošto, razpravljal o težavah. Dimitri je naš arhitekt. Njihov prispevek je bil zelo koristen pri zagotavljanju, da imamo vsi enak miselni model okoli svojih idej.

Rad bi opozoril na nekaj zanimivih stvari v tem CSRTale. Prvič, to je odličen primer, kako doseči usvajanje industrije. Barzan in njegova skupina sta prispevala obliž, ki ga je bilo mogoče neposredno preizkusiti. To je ključno. Drugič, Barzan in njegova skupina sta porabila veliko časa, ko sta s Sunnyjem razpravljala o svoji ideji, da bi zagotovila, da sta na isti strani. Tehnološki prenos traja veliko časa, ki presega čas, porabljen za objavo prispevka. Če iščete vpliv, je to odlična pot, vendar bodite pozorni na časovne stroške. Tretjič, pregled kakovosti ni zelo dosleden v široki sistemski skupnosti. Videla sem ocene, podobne tistim, ki jih je prejel Barzan: meni, da se nekateri recenzenti (ne vsi hvaležni) najprej odločijo, nato pa poskusijo najti kakršen koli izgovor, da bi papir zavrnili. Torej so včasih pregledi zelo hrupni signali: morda bi pomislili, če bi določili, kaj je pregledovalec zahteval, bi bili sprejeti, vendar to ni pogosto. V vašem prispevku so lahko tudi druge pomanjkljivosti, ki jih morda bolje porabite za popravljanje. Na primer, če ideje v vašem prispevku niso naletele nazorno, recenzentu morda ne bo všeč vaš prispevek in se pritožijo nad oceno. Popravljanje ocene (ne da bi popravil pisanje) ne bi izboljšalo vaše možnosti za sprejem. O tem se posvetujte s svetovalci :)