CSR-tarina # 8: Miksi hirvittävät arvostelut ovat sinulle hyviä!

CSR Tale # 8 on peräisin professori Barzan Mozafarilta Michiganista. Barzan johtaa tutkimusryhmää, joka suunnittelee seuraavan sukupolven skaalautuvat tietokannat edistyneiden tilastomallien avulla. MySQL ja MariaDB hyväksyivät äskettäin heidän VATS-lukon aikataulutusalgoritminsa, joten juttelin Barzanin kanssa kuinka VATS-työ tuli tehdä. Juttelin myös yhden heidän teollisen yhteistyökumppaninsa, Sunny Bainsin kanssa Oraclesta saadaksesi tarinan teollisuuden puolelle. Kaiken kaikkiaan se tarjoaa upean CSR-tarinan! Ensinnäkin, kuullaan Barzanilta:

Oli kesä kesä 2013. Olin juuri aloittanut toimikautensa professorina Michiganin yliopistossa ja yritin selvittää, mitä työskennellä. MIT: n postdokumentin aikana olin osallistunut useisiin erilaisiin hankkeisiin analytiikasta (esim. BlinkDB) transaktioihin ja pilvilaskentaan (esim. DBSeer) joukkotietojen hankkimiseen. Näistä DBSeer oli ylivoimaisesti vaikein haaste, jonka olen koskaan vastaanottanut. DBSeerin kanssa tavoitteena oli ennustaa tietokantajärjestelmän (tässä tapauksessa MySQL) suorituskyky annetulla työkuormalla. Yli kahden vuoden aikana olen kokeillut kaikkia oppikirjassa olevia koneoppimisalgoritmeja. Vaikka meillä oli jonkin verran menestystä resurssien käytön (esimerkiksi levy IO tai CPU) ennustamisessa, tuloksemme olivat keskinkertaisia, kun piti ennustaa tapahtuman todellista latenssia.

Tähän oli kaksi perustavaa syytä. Ensinnäkin, olimme päättäneet, että olemme kiinnostuneita vain tuntemattomista ratkaisuista. Esimerkiksi, me aiomme tarkastella vain MySQL: n globaalia tilamuuttujaa. Tämä tarkoitti, että meillä ei ollut pääsyä joihinkin kriittisiin tilastoihin, koska MySQL ei paljastanut niitä. (Andy Pavlon Peloton-projekti on hieno tapa puuttua tähän ensimmäiseen ongelmaan pääsyä tietokannan sisäisiin osiin). Mutta tuolloin periaatteemme oli, että jos voisimme tehdä tämän työn, DBSeerin omaksumisesta tulisi ei-braineri. Toinen syy oli paljon suoraviivaisempi: MySQL ei ollut vain ennakoitavissa oleva järjestelmä, jonka alkua! Voit lähettää täsmälleen saman kyselyn täsmälleen samoissa olosuhteissa useita kertoja, ja sait silti paljon erilaisia ​​latensseja joka kerta! Koska signaalissa on paljon melua, koneoppimiseen ei ole vain paljon tehtävää. Se on niin yksinkertaista. Ja minun on huomautettava, että tämä ei ollut vain MySQL: kaikki muut tarkastelemasi DBMS-järjestelmät olivat yhtä arvaamattomia. "Esivanhempamme, kun he suunnittelivat näitä vanhoja järjestelmiä, olivat liian keskittyneitä tekemään niistä nopeampia, minkä seurauksena heillä ei ollut ylellisyyttä huolehtia heidän ennustettavuudestaan." Tai ainakin niin näytti.

Joten siellä olin, vasta aloittaessani Michiganista, ja tajusin, että oli loistava tilaisuus muuttaa tätä kerran ja lopulta: Tehdään tietokantajärjestelmistä ennustettavissa olevia, ei vain nopeampia. Olin hiljattain rekrytoinut Jiamin Huang, vaikuttavan opiskelijan, jolla on uskomattomat järjestelmätaidot. Pyrimme selvittämään, mikä voi aiheuttaa arvaamattomuutta. Ensimmäinen epäillymme oli L2-välimuistin katoaminen. Yhteistyössä yhden laitteistokampanjani (Tom Wenisch) kanssa tutkimme tätä ja monia muita mahdollisia syitä, mutta erittäin nopeasti oli mahdotonta saavuttaa tämä käsin, koska MySQL-tietokanta oli monimutkainen. Pian löysimme itsemme luomaan oman profiilin, joka, toisin kuin Dtrace ja muut profiilit, oli erityisesti suunniteltu etsimään suorituskykyvaihtelujen perimmäiset syyt suuressa ja monimutkaisessa kooditietokannassa. Kävi ilmi, että profiloijamme eivät olleet erityisiä tietokantoille, ja lopulta muutimme sen VProfileriksi ja julkaissimme sen myöhemmin EuroSys 2017 -palvelussa. Tarkoituksena oli tarkastella miljoonia rivikoodeja ja ilmoittaa sitten kehittäjälle muutamasta välttämättömästä parista. toiminnoista, joita käytetään sovelluksen ennustettavuuden parantamiseksi.

Havaintojen tietokantaosassa on paljon mielenkiintoisempi tarina. VProfiler paljasti joukon syyllisiä ennakoimattomuuden aiheuttamiseksi. Esimerkiksi yksi havaintoista oli, että MySQL: ssä "jonottaminen" jaettujen resurssien taakse oli pääasiallinen viive latenssivarianssiin. Jälkikäteen tämä on erittäin intuitiivinen: kun N tapahtumaa odottaa jonossa samaa jaettua resurssia, jonon edessä oleva odottaa aivan erilaista odotusaikaa kuin jonon lopussa, ja molemmat ovat tulee olemaan hyvin erilainen kuin jonon keskellä. Siksi he lopulta osoittavat hyvin erilaisia ​​viiveitä tehdä saman määrän työtä.

Lyhyt tarina, siirrimme painopistettä jonotusjohtamiseen ja ymmärsimme, että jokainen maailman tietokanta käytti edelleen jotakin FIFO-varianttia (first-in, first-out). Olemme keksineet uuden algoritmin, nimeltään VATS (Variance-Aware Transaction Scheduling), varianssin vähentämiseksi, ja julkaissimme sen SIGMOD 2017 -lehdessämme (”Ylhäältä alaspäin suuntautuva lähestymistapa suorituskykyennustettavuuden saavuttamiseen tietokantajärjestelmissä”). Yksi tämän tarjoamista hienoista käsityksistä oli, että ennustettavuuden ei tarvitse olla keskimääräisen suorituskyvyn hinta. Toisin sanoen on olemassa tapa tehdä järjestelmistä ennustettavissa ja samalla tehdä niitä nopeammiksi: vähentämällä väitepohjaista varianssia.

Myöhemmin määrittelimme lukkojen ajoituksen yleisen ongelman. Tutkimme erilaista, uutta algoritmia, joka oli optimaalinen keskimääräisen latenssin vähentämiseksi (ja läpäisykyvyn lisäämiseksi) ja julkaistiin VLDB 2018: ssa (”Content-tietoinen lukuaikataulu transaktiotietokannoille”). Kutsimme tätä uutta algoritmia VATS 3.0: ksi (emme koskaan julkaissut VATS 2.0: ta), josta myöhemmin annettiin nimi CATS (Content-Aware Transaction Scheduling).

Kilpailua tietoinen tapahtumiaikataulu: Lukon myöntäminen O1: lle t1: lle mahdollistaa enemmän samansuuntaisuutta (vähentää enemmän väitteitä) kuin sen myöntäminen t2: lle

Teollisuuden omaksumisen kannalta asiat menivät melko sujuvasti: Sekä MySQL että MariaDB käyttivät omia vertailuarvojaan uudella algoritmillamme ja päättivät ottaa sen käyttöön erillisessä versiossa (MySQL teki siitä jopa oletusstrategian). Olemme kiitollisia kaikille avoimen lähdekoodin yhteistyökumppaneillemme MySQL-yhteisössä, mukaan lukien arvokasta palautetta ja apua Jan Lindstromilta (MariaDB), Sunny Bainsilta ja Dimitri Kravtchukilta (Oracle), Laurynas Biveinis ja Aleksei Stroganovilta (Percona), Mark Callaghanilta ( Facebook) ja Daniel Black (IBM).

Akateemisesta näkökulmasta kuitenkin asiat eivät sujunut aivan yhtä sujuvasti. Tässä on aikajana tapahtuneelle:

Vastuuvapauslauseke: Jotkut konferenssien nimistä / vuosista ovat saattaneet olla erilaisia

  • SIGMOD’16: Lähetämme MySQL-tuloksemme.
  • Hylkääminen: “Kuinka tiedämme, toimiiko se muulle kuin MySQL: lle?”

Kommentti: Mielenkiintoista se, että saat vastaista kommenttia, kuten tämä, vain kun otat ideasi käyttöön oikeassa järjestelmässä. Jos prototyyppituotat ideaasi tyhjästä ja luot mallitietokannan, tyypillisesti kukaan ei kysy, koskeeko se muita oikeita järjestelmiä! Nämä kommentit eivät ymmärtäneet oppilaani päättänyt todistaa arvioijaa väärin ...

  • VLDB’16: Sovelimme VProfiilia myös Postgresiin ja VoltDB: ään.
  • Hylkääminen: "Jos tämä ongelma olisi tarpeeksi tärkeä, joku muu olisi tehnyt sen jo nyt!"

Kommentti: Tähän päivään asti tämä on edelleen yksi suosikkini arvosteluista! Epäreilun arvostelun vastaanottaminen ei ole koskaan hauskaa, mutta tämä oli niin naurettava, että se ei häirinnut meitä - itse asiassa pidimme sitä melko huvittavana. Vaikka toivomme, että meillä olisi ollut tilaisuus esittää tarkastajalle kaksi kysymystä:

1) Mittaa arvostelija omaa tutkimustaan ​​samalla palkilla? (Tiedämme, että se oli ”hän”; katso oppitunti 5.)

2) Kuinka voimme koskaan saavuttaa edistystä tutkimuksessa soveltamalla tätä periaatetta? Jos jotain on jo tehty, niin se ei ole uusi ja julkaistava, ja jos sitä ei ole tehty, niin se ei vain ole tarpeeksi tärkeä, eikä niiden julkaisemiseen ole mitään syytä!

  • OSDI’16: Siitä huolimatta opiskelijani päätti jälleen kerran todistaa arvostelija väärin ja todistaa ongelman olevan todellinen. Joten lähetimme algoritmejamme ja tuloksemme sekä MariaDB: lle että MySQL: lle. MySQL otti VATS: n vastaan ​​oletusaikatauluna ja mainitsimme sen lehdessä.
  • Hylkääminen: “Olet asentanut VProfileriä MySQL: ään, Postgresiin ja VoltDB: ään. Kuinka tiedämme, toimiiko se muulle kuin DBMS-järjestelmälle? "

Kommentti: Tämä oli kohtuullinen huolenaihe. Loppujen lopuksi OSDI on OS-konferenssi. Olimme todellakin erittäin tyytyväisiä saatujen arvostelujen laatuun. DB-tutkijana katehdin OS-yhteisöä heidän merkittävästi paremmasta tarkistusjärjestelmästä.

  • SIGMOD’17: Lähetämme VATS- ja muut tietokantatiedot.
  • Hyväksyä! Vihdoinkin!
  • EuroSys’17: Yleistimme profiloijamme, josta tuli myöhemmin VProfiler ja jota sovellettiin tietokantajärjestelmien lisäksi Apache Web Server -palvelimeen.
  • Hyväksyä! Jee!
  • VLDB’18: Lopulta, kun onnistuimme virallistamaan lukkojen aikataulutusongelman, pystyimme ratkaisemaan myös suorituskyvyn (ei vain ennustettavuuden). Tästä tuli CATS-algoritmi.
  • Hyväksyä. Saimme todella upeita arvosteluja VLDB'18: lta. Saimme myös poikkeuksellista palautetta Peter Bailisiltä paperin julkaisemisen jälkeen.

Joten tässä on muutamia oppia tästä pitkästä viestistä:

Oppitunti 1. Kauheat arvostelut ovat todella hyviä sinulle. Ne pakottavat sinut (ja opiskelijasi!) Tekemään lisää työtä, mikä ei ole huono tulos!

Oppiaihe 2. Älä luota siihen, mitä ihmiset sanovat paneeleissa. Vaikka kaikki akateemisessa yliopistossa osallistuisivat tosiseikkojen arviointiin reaalimaailman vaikutusten ja reaalimaailman validointien arvioinnissa, jotkut heistä ovat joskus alitajuisesti valehtelevia. Kun he käyttävät tarkistaja hattuaan, he rankaisevat usein papereita, joissa käytetään todellista arviointijärjestelmää, esimerkiksi kysymällä miljardia muuta asiaa, mikä olisi mahdollista vain, jos käyttäisit prototyyppisimulaatiota. En tarkoita, että sinun pitäisi luopua todellisten järjestelmien käytöstä kokeissa, vaan yksinkertaisesti olla varautunut tekemään lisää työtä!

Oppiaihe 3. Akatemialla ja teollisuudessa on erilaiset aallonpituudet. Niille meistä akateemisessa ympäristössä kolme kuukautta tuntuu ikuisuudelta. Tuotetiimit kuitenkin ajavat omalla aikajanallaan - joskus voi kulua jopa vuosi, ennen kuin heillä on mitään sykliä sinulle. Sinun täytyy vain olla kärsivällinen ja arvostaa sitä suurta työtä, jota he tekevät korkealaatuisen avoimen lähdekoodin ekosysteemin ylläpitämisessä.

Oppitunti 4. Kaikki arvioijat eivät ole matemaatikoita. Yhdessä aikaisemmissa lausunnoissamme ilmoitimme eliminoimamme prosentuaalisen osuuden kokonaisvarianssista, joka oli noin 65%. Ilmeisesti et voi poistaa mitään yli 100%. Valitettavasti se on vain matematiikan lakien rajoitus. Mutta yksi arvosteluistamme (mielestäni SIGMOD’16 tai VLDB’16) oli sitä mieltä, että 65%: n vähennys ei ole tarpeeksi merkittävä. Joten seuraavassa lähetyksessämme siirryimme parannussuhteen raportointiin, joka määritettiin alkuperäisen MySQL: n varianssiksi jaettuna modifioidun version varianssilla. Sama 65%: n vähennys ilmoitettiin nyt varianssin kolminkertaiseksi vähentämiseksi, ja arvioijat (tosin todennäköisesti erilaiset ihmiset) olivat tällä kertaa onnellisempia.

Oppitunti 5. Ole mukava tai tuntematon. Tämä koskee suosikkiarvioijaamme: Jos aiot kirjoittaa ilkeän arvion, ei todennäköisesti ole hyvä idea pyytää kirjoittajia mainitsemaan kolme omaa artikkeliasi. Anonymiteetin säilyttäminen ei sovi hyvin ☺

Oppiaihe 6. Oikeiden järjestelmien parissa työskenteleminen on tuskaa, mutta se on täysin sen arvoista. Jos olet halukas sietämään huonoja arvosteluja ja huomattavasti pidempää paperille ajamista, työskentely oikeilla järjestelmillä on erittäin palkitseva kokemus!

Sallii siirtyä teolliseen näkökulmaan tässä teoksessa. Juttelin Oraclen Sunny Bainsin kanssa, joka auttoi VATS: n käyttöönottoa MySQL / InnoDB: hen. Esitän hänen kanssaan käymäni keskustelun Q & A: na.

CSRTales: Kuinka opit ensin CATS-työstä?

Aurinkoinen: IIRC Barzan ja Jiamin julkaisivat vertailuarvoja sisältävän paperin, jonka joku organisaatiossamme välitti minulle. Sitten he tekivät korjaustiedoston, joka kiinnosti minua. Lukitseminen vaatii aina jonkin verran optimointia tai toista, ja silloin tutkimme InnoDB-lukitushallinnan optimointia. Siksi se oli hyvin ajankohtainen. CATS, kuten sitä sitten kutsuttiin, näytti lupaavalta ehdokkaalta tarkastella. Tuolloin olimme keskittyneet liian suppeasti yhdenmukaiseen jakeluun eivätkä nähneet mitään voittoja. Painopiste siirtyi myös muiden asioiden kiinnittämiseen InnoDB: n sisälle. Kun meillä oli hyviä ratkaisuja muihin TranDB: n transaktioiden hallintaa koskeviin kysymyksiin, lukitusasiat nousivat eturintamaan. InnoDB-tiimi alkoi tarkastella uudelleen CATS: ää ja sattumalta Facebookista lähetetty Mark Callaghan lähetti minulle sähköpostin seuraavana päivänä esittelemällä minua Barzanille ja Jiaminille. Tiiviimpi yhteistyö alkoi sen jälkeen ja suoran viestinnän ja heidän avunsa avulla se oli kaikki alamäkeä sieltä.

CSRTales: Mitä pidit eniten CATS-ideasta, kun kuulit siitä?

Sunny: Se käsitteli todellista ongelmaa, ja sisältö itsessään on hyvin yleistä, ja mielestäni sillä on sovelluksia lukonhallinnan ulkopuolella. Yhtä tärkeää käytännöllisestä näkökulmasta on, että se sisälsi todistuksen käsitteestä. Laastari, jonka voimme testata heti. Ympärillä on paljon hyviä ideoita. Jotta jotain konkreettista testata, on valtava plus. Se säästää paljon aikaa ja resursseja. Mielestäni tämä on myös yksi avoimen lähdekoodin ohjelmistojen eduista. Tämä on erittäin hyvä esimerkki siitä.

CSRTales: Kuinka kauan kesti työn ensimmäisestä kuulemisesta työn yhdistämiseen?

Sunny: Luulen, että kesti noin vuoden. Siitä lähtien kun päätimme sitoutua siihen ja siihen mennessä, kun se tosiasiallisesti työnnettiin, kesti kuusi kuukautta. Laadunvarmistusprosessimme on erittäin tiukka, enkä voi kiittää laadunvarmistustamme. Alkuperäisessä korjaustiedostossa oli joitain virheitä. Päätimme myös kirjoittaa sen uudelleen. Haluamme myös vähentää kokoonpanomuuttujien määrää politiikkana. Aukkojen lukkoissa oli joitain ongelmia, jotka piti kiinnittää laastariin.

CSRTales: Tyypillisesti avoimen lähdekoodin yhteisöissä, kuten Linux-ytimessä, sinulla on oltava luotettavuus jo rakennettu, ennen kuin korjaustiedostot hyväksytään. Arvaan, että jotain vastaavaa tapahtui täällä?

Aurinkoinen: Tietenkin. Meillä on melko vähän korjaustiedostoja / kommentteja. Haluan kuitenkin korostaa, että se ei ole ennakkoedellytys. Olemme valmiita hyväksymään korjauksia, jotka toimivat tyhjästä, ja meillä on dokumentaatio, joka osoittaa ongelman ja kuinka korjaustiedostot korjaavat nämä ongelmat. Aito haluamme rohkaista tutkijoita / käyttäjiä / kehittäjiä ketä tahansa, jolla on kiinnostusta alaan, hyödyntämään avoimen lähdekoodin etuja ja lähettämään meille korjauksensa. Haluaisin korostaa, puhuminen on halpaa. Näytä minulle koodi :-)

CSRTales: Onko yleinen käytäntö kirjoittaa kirjoitettuja korjaustiedostoja uudelleen?

Sunny: Kyllä, kun päätämme sitoutua johonkin työhön, pidämme mieluummin, että se tehdään kokonaan ryhmässä. Tähän on käytännön syitä. Laadunvarmistusprosessi on melko intensiivinen, ja koodin tarkistusten ja aiheiden seurannan ympärillä on koko infrastruktuuri, johon ulkopuolisilla ei ole pääsyä. Koodin lähettäjän on myös otettava omista myöhemmistä virhekorjauksista jne. Useimmiten käytännöllisyyden takia emme saa alkuperäisiä kirjoittajia tekemään työtä sen edetessä. Me (itse asiassa tein) kirjoitin korjaustiedoston uudelleen. Jiamin, Dimitri, Barzan ja minä keskustelimme jatkuvasti sähköpostista, josta keskustelimme asiasta. Dimitri on esitysarkkitehtimme. Heidän panoksensa olivat erittäin hyödyllisiä sen varmistamisessa, että meillä kaikilla oli sama ajatusmalli heidän ideoidensa suhteen.

Haluaisin tuoda esiin useita mielenkiintoisia asioita tässä CSRTalessa. Ensinnäkin, tämä on loistava esimerkki siitä, miten saada teollisuus omaksumaan. Barzan ja hänen ryhmänsä lähettivät korjaustiedoston, joka voitiin testata suoraan. Tämä on ratkaisevan tärkeää. Toiseksi Barzan ja hänen ryhmänsä käyttivät paljon aikaa keskustellakseen ideastaan ​​Sunnyn kanssa varmistaakseen, että he olivat samalla sivulla. Tekninen siirto vie paljon aikaa, paperin julkaisemiseen kuluvan ajan lisäksi. Jos etsit vaikutusta, tämä on hieno polku, mutta ole tietoinen aikakustannuksista. Kolmanneksi, laadun tarkistaminen ei ole kovin johdonmukaista laajassa järjestelmäyhteisössä. Olen nähnyt arvosteluja, jotka ovat samanlaisia ​​kuin Barzanin vastaanottamat: Oman mielestäni tietyt arvioijat (eivät kaikki onneksi) ensin päättävät mielensä ja yrittävät sitten löytää minkäänlaisen syyn paperin hylkäämiseen. Joten arvostelut ovat joskus erittäin meluisia signaaleja: Saatat ajatella, että jos korjaat tarkastajan pyynnön, sinut hyväksytään, mutta niin ei ole usein. Papereissasi voi olla muita heikkouksia, jotka kannattaa käyttää paremmin aikaasi korjaamiseen. Esimerkiksi, jos paperisi ideat eivät törmänneet selvästi, arvioija ei ehkä pidä paperistasi ja valittaa arvioinnista. Arvioinnin vahvistaminen (ilman kirjoituksen korjaamista) ei parantaisi hyväksymismahdollisuuksiasi. Keskustele neuvonantajien kanssa tästä :)