CSR lugu nr 8: miks kohutavad ülevaated teile sobivad!

CSR Tale # 8 pärineb prof Barzan Mozafarilt Michiganist. Barzan juhib uurimisrühma, mis kujundab järgmise põlvkonna skaleeritavaid andmebaase, kasutades täiustatud statistilisi mudeleid. Hiljuti võtsid MySQL ja MariaDB vastu nende VATS-i lukustamise ajakava algoritmi, nii et vestlesin Barzaniga, kuidas VATS-i tööd teha tuli. Vestlesin ka ühe nende tööstuskaaslase, Oracle'i Sunny Bainsiga, et saada selle loo tööstuslik külg. Üldiselt teeb see suurepärase CSR-i loo! Esiteks, kuulgem Barzanilt:

See oli 2013. aasta suvi. Olin just alustanud Michigani ülikooli ametialase professorina ja üritasin välja mõelda, mille kallal töötada. MIT-is tehtud postdokumendi ajal olin panustanud mitmesse erinevasse projekti, alates analüüsist (nt BlinkDB), lõpetades tehingute ja pilvandmetöötlusega (nt DBSeer) ja lõpetades ühishangetega. Neist oli DBSeer kaugelt kõige raskem väljakutse, mille ma kunagi vastu olen võtnud. DBSeerriga oli eesmärk ennustada andmebaasisüsteemi (antud juhul MySQL) jõudlust töökoormuse korral. Ligi kahe aasta jooksul proovisin õpikus kõiki masinõppe algoritme. Kui meil oli ressursikasutuse (nt ketta IO või CPU) ennustamisel teatavat edu, siis tehingu tegeliku latentsuse ennustamisel olid meie tulemused keskpärased.

Sellel oli kaks peamist põhjust. Esiteks otsustasime, et meid huvitavad ainult pealetükkivad lahendused. Näiteks vaatasime ainult MySQL globaalse oleku muutujaid. See tähendas, et meil ei olnud juurdepääsu mõnele kriitilisele statistikale lihtsalt sellepärast, et MySQL ei avaldanud neid. (Andy Pavlo Pelotoni projekt on suurepärane viis selle esimese probleemiga tegelemiseks, kui neil on juurdepääs andmebaasi sisemistele osadele). Kuid tol ajal oli meie põhjendus selline, et kui me suudame selle töö ära teha, muutub DBSeeri vastuvõtmine mõttetuks. Teine põhjus oli palju otsesem: MySQL polnud lihtsalt kõigepealt etteaimatav süsteem! Võite esitada täpselt sama päringu täpselt samadel tingimustel mitu korda ja teil oleks ikka iga kord erinev latentsusaeg! Kuna signaalis on nii palju müra, pole masinõppeks palju vaja. See on nii lihtne. Ja ma peaksin rõhutama, et see polnud ainult MySQL: kõik muud DBMS-id, mida me vaatasime, olid sama ettearvamatud. „Meie esivanemad olid neid pärandsüsteeme kavandades liiga keskendunud nende kiiremaks muutmisele ja seetõttu polnud neil luksust muretseda nende ennustatavuse pärast.” Või vähemalt nii tundus.

Nii ma siis olin, kui olin just Michiganis alustanud, ja mõistsin, et on suurepärane võimalus seda kord ja kõik muuta: muutkem andmebaasisüsteemid etteaimatavamaks, mitte ainult kiiremaks. Olin hiljuti värvanud Jiamin Huangi, kes on muljetavaldav üliõpilane, kellel on uskumatud süsteemioskused. Otsustasime dešifreerida selle, mis võib põhjustada ettearvamatust. Meie esimene kahtlus oli L2 vahemälu puudumine. Võtsime ühendust ühe minu riistvarakaaslasega (Tom Wenisch), et seda ja paljusid muid võimalikke põhjuseid uurida, kuid väga kiire oli see käsitsi lahendamine võimatu, arvestades MySQL koodbaasi keerukust. Peagi leidsime, et loome oma profiiliprofiili, mis erinevalt Dtrace'ist ja teistest profiilidest oli spetsiaalselt loodud jõudluse dispersiooni algpõhjuste leidmiseks suures ja keerulises koodbaasis. Selgus, et meie profiiliprofiil ei olnud spetsiifiline andmebaaside suhtes ja muutisime selle VProfileriks ning avaldasime selle hiljem veebisaidil EuroSys 2017. Tuli vaadata miljonite ridade koodiribasid ja teavitada arendajat vajalikust paarist. funktsioone, mida kasutada, et muuta teie rakendus ennustatavaks.

Meie leidude andmebaasiosas on palju huvitavam lugu. VProfiler paljastas hunniku süüdlasi ettearvamatuse põhjustamiseks. Näiteks oli üks meie järeldustest, et MySQL-is oli latentsusaja variatsiooni peamine põhjus jagatud ressursside taga järjekorda seadmine. Tagantjärele on see väga intuitiivne: kui N tehingut ootab sama ühiskasutatava ressursi jaoks järjekorras, peab järjekorda ootav ootaja ootama hoopis teistsugust ooteaega kui see, mis järjekorra lõpus on, ja mõlemad on saab olema väga erinev kui järjekorra keskel. Seetõttu on neil sama palju töö tegemiseks väga erinevad latentsusajad.

Lühidalt öeldes, nihutasime tähelepanu järjekordade haldamise suunas ja šokeerivalt mõistsime, et kõik maailma andmebaasid kasutavad endiselt mõnda FIFO varianti (first-in, first-out). Tulime välja dispersioonide vähendamiseks uue algoritmiga VATS (Variance-Aware Transaction Scheduling) ja avaldasime selle oma SIGMOD 2017 töös (“Ülalt-alla lähenemine jõudluse ennustatavuse saavutamiseks andmebaasisüsteemides”). Üks suurepäraseid teadmisi, mida see pakkus, oli see, et etteaimatavus ei pea tulema keskmise jõudluse hinnaga. Teisisõnu, on olemas viis, kuidas muuta süsteeme paremini ennustatavaks, muutes need kiiremaks: vähendades väitepõhist dispersiooni.

Hiljem sõnastasime luku ajakava üldise probleemi. Uurisime teistsugust uudset algoritmi, mis oli optimaalne keskmise latentsuse vähendamiseks (ja läbilaskevõime suurendamiseks) ning avaldati ajakirjas VLDB 2018 (“Tehingute andmebaaside väidete teadlik lukustamise ajakava”). Kutsusime seda uut algoritmi VATS 3.0 (me ei avaldanud kunagi VATS 2.0), millele hiljem panime nimeks CATS (Contents-Aware Transaction Scheduling).

Konkurentsi teadvustavate tehingute ajastamine: luku O1 kuni t1 lukustuse andmine võimaldab rohkem paralleelsust (vähendab rohkem väidet) kui selle andmine t2-le

Tööstussektoris kasutuselevõtu seisukohast kulgesid asjad üsna sujuvalt: nii MySQL kui ka MariaDB käitusid meie uue algoritmiga oma mõõdupuud ja otsustasid selle omaette versioonides kasutusele võtta (MySQL muutis selle isegi vaikestrateegiaks). Oleme tänulikud kõigile meie MySQL-i kogukonna avatud lähtekoodiga kaastöötajatele, sealhulgas hindamatu tagasiside ja abi saamiseks Jan Lindstromilt (MariaDB), Sunny Bainsilt ja Dimitri Kravtchukilt (Oracle), Laurynas Biveiniselt ja Aleksei Stroganovilt (Percona), Mark Callaghanilt ( Facebook) ja Daniel Black (IBM).

Akadeemilisest seisukohast vaadatuna ei läinud asjad aga sugugi nii libedalt. Siin on toimunu ajajoon:

Kohustustest loobumine: mõne konverentsi nimi / aasta võis olla erinev

  • SIGMOD’16: esitasime oma MySQL-i tulemused.
  • Tagasilükkamine: „Kuidas me teame, kas see töötab muuks kui MySQL?“

Kommentaar: Huvitaval kombel saate selliseid kommentaare nagu see ainult siis, kui rakendate oma ideed reaalsesse süsteemi. Kui prototüübid lihtsalt oma idee nullist ja loote makettide andmebaasi, siis tavaliselt ei küsi keegi, kas see kehtib muude reaalsete süsteemide kohta! Nende kommentaaride puudumisel otsustas minu õpilane tõestada, et arvustaja eksib ...

  • VLDB’16: rakendasime VProfiili ka Postgres ja VoltDB.
  • Tagasilükkamine: "Kui see probleem oleks piisavalt oluline, oleks keegi teine ​​seda juba teinud!"

Kommentaar: tänapäevani on see endiselt üks minu lemmik ülevaateid! Ebaõiglase arvustuse saamine pole kunagi lõbus, kuid see oli nii naeruväärne, et see ei häirinud meid - tegelikult pidasime seda üsna lõbusaks. Ehkki soovime, et meil oleks olnud võimalus esitada sellele arvustajale kaks küsimust:

1) Kas retsensend mõõdab enda uurimistööd sama riba järgi? (Me teame, et see oli "ta"; vt õppetund 5.)

2) Kuidas saaksime selle põhimõtte rakendamisel teadusuuringutes edasiminekut saavutada? Kui midagi on juba tehtud, siis pole see uus ja avaldatav ning kui seda pole tehtud, siis pole see lihtsalt piisavalt oluline ja neid avaldada pole mõtet!

  • OSDI’16: Sellegipoolest otsustas mu tudeng veel kord tõestada retsensendi vale ja tõestada, et probleem on tõeline. Nii saatsime oma algoritmid ja tulemused nii MariaDB-le kui ka MySQL-i. MySQL võttis VATS-i vastu vaikimisi ajastamisena ja mainisime seda oma artiklis.
  • Tagasilükkamine: „Olete rakenduse MySQL, Postgres ja VoltDB jaoks rakendanud VProfileri. Kuidas me teame, kas see töötab muu jaoks kui DBMS? ”

Kommentaar: see oli õiglane mure. Lõppude lõpuks on OSDI OS-i konverents. Jäime saadud arvustuste kvaliteediga tegelikult väga rahule. DB-teadurina kadestan OS-i kogukonda nende oluliselt parema ülevaatesüsteemi pärast.

  • SIGMOD’17: esitasime VATS-i ja muud andmebaasi leiud.
  • Nõus! Lõpuks!
  • EuroSys’17: üldistasime oma profiiliprofiili, millest hiljem sai VProfiler ja mida rakendati lisaks andmebaasisüsteemidele ka Apache veebiserverisse.
  • Nõus! Jah!
  • VLDB’18: kui lõpuks suutsime lukustamise ajastamise probleemi vormistada, suutsime lahendada ka toimivuse (mitte ainult etteaimatavuse). Sellest sai CATS-i algoritm.
  • Nõus. Saime VLDB’18-st tegelikult suurepäraseid arvustusi. Pärast töö avaldamist saime Peter Bailiselt ka erakordset tagasisidet.

Siin on mõned õppetunnid sellest pikast postitusest:

Õppetund 1. Kohutavad arvustused on teile tegelikult head. Nad sunnivad teid (ja teie õpilast!) Rohkem tööd tegema, mis pole halb tulemus!

2. õppetund. Ärge usaldage seda, mida inimesed paneelidel ütlevad. Ehkki kõik akadeemilistes ringkondades õpiksid reaalse maailma mõju ja valideerimise väärtustamist, on mõni neist vahel alateadlikult valetatud. Kui nad kannavad oma retsensendimütsi, siis karistavad nad sageli paberit, mis kasutab hindamiseks reaalset süsteemi, nt küsides miljardit muud asja, mis oleks võimalik ainult prototüübi simulatsiooni kasutamisel. Ma ei pea silmas, et peaksite katsetes loobuma reaalsete süsteemide kasutamisest, vaid olema lihtsalt valmis rohkem tööd tegema!

3. tund. Akadeemial ja tööstusel on erinevad lainepikkused. Neile, kes oleme akadeemilises ringkonnas, tundub kolm kuud igavikuna. Tootetiimid juhivad siiski oma ajakava - mõnikord võib kuluda kuni aasta, enne kui neil on teie jaoks tsüklid. Peate lihtsalt olema kannatlik ja hindama suurt tööd, mida nad teevad kvaliteetse avatud lähtekoodiga ökosüsteemi hooldamisel.

4. õppetund. Mitte iga arvustaja pole matemaatik. Ühes oma varasemates avaldustes teatasime me kõrvaldatud protsendi kogu dispersioonist, mis oli umbes 65%. Ilmselt ei saa te midagi enam kui 100% kõrvaldada. Kahjuks on see vaid matemaatika seaduste piirang. Kuid üks meie arvustustest (ma arvan, et SIGMOD’16 või VLDB’16) oli arvamusel, et 65% -line vähendamine pole piisavalt oluline. Nii otsustasime oma järgmises esitamises edastada parendussuhte, mis määratleti kui algse MySQLi dispersioon jagatuna meie muudetud versiooni dispersiooniga. Samast 65% -lisest vähenemisest teatati nüüd dispersiooni kolmekordse vähenemisena ja arvustajad (ehkki ilmselt erinevad inimesed) olid seekord õnnelikumad.

Õppetund 5. Ole kena või ole anonüümne. See kehtib meie lemmikretsensendi kohta: kui kavatsete kirjutada vastikut arvustust, pole ilmselt hea mõte paluda autoritel nimetada kolm teie enda artiklit. Teie anonüümsuse säilitamine ei lähe hästi ☺

Õppetund 6. Päris süsteemidega töötamine on valu, kuid see on seda väärt. Kui olete nõus halbade arvustustega ja oluliselt pikema ajaga paberile jõudmiseks, on päris süsteemidega töötamine äärmiselt rahuldust pakkuv kogemus!

Võimaldab selle töö puhul lülituda tööstuslikule vaatenurgale. Vestlesin Oracle'i Sunny Bainsiga, kes aitas VATS-i MySQL / InnoDB-sse sisse viia. Esitan oma vestlust temaga küsimuste ja märkustena.

CSRTales: Kuidas te kõigepealt CATS-i töö kohta teada saite?

Päikeseline: IIRC Barzan ja Jiamin avaldasid võrdlusalustega paberi ja selle edastas mulle keegi meie organisatsiooni esindajatest. Seejärel panid nad paika, mis mind huvitab. Lukustamine vajab alati mõnda või teist optimeerimist ja sel ajal otsisime InnoDB lukustushalduri optimeerimist. Seetõttu oli see väga õigeaegne. CATS, nagu seda tol ajal kutsuti, tundus paljutõotav kandidaat, kellele seda vaadata. Selles etapis keskendusime liiga kitsalt ühtlasele jaotusele ega näinud mingit kasu. Samuti keskenduti muude asjade fikseerimisele InnoDB sees. Kui meil oli InnoDB siseselt tehingute haldamisega seotud probleemidele head lahendused, tõusid lukustusprobleemid taas esiplaanile. InnoDB meeskond hakkas uuesti CATSi vaatama ja juhuslikult saatis Mark Callaghan Facebookist mulle järgmisel päeval mulle meilisõnumi, tutvustades mulle Barzani ja Jiaminit. Tihedam koostöö algas pärast seda ning otsese suhtluse ja nende abiga oli kõik sealt allamäge.

CSRTales: Mis teile CATSi ideest kõige rohkem meeldis, kui sellest kuulsite?

Sunny: see käsitles tõelist probleemi ja sisu ise on väga üldine ning ma arvan, et sellel on rakendusi väljaspool lukuhaldurit. Praktiliselt on sama oluline see, et sellega kaasnes kontseptsiooni tõend. Plaaster, mida saime kohe katsetada. Ümberringi hõljub palju häid ideid. Midagi konkreetset testida on tohutu pluss. See säästab palju aega ja ressursse. Samuti arvan, et see on avatud lähtekoodiga tarkvara üks eeliseid. See on selle kohta väga hea näide.

CSRTales: Kui kaua kulus töö esimesest kuulmisest kuni selle ühendamiseni?

Sunny: Ma arvan, et see võttis umbes aasta. Alates ajast, kui otsustasime sellele pühenduda ja kuni selle tegeliku surumiseni kulus kuus kuud. Meie kvaliteedikontrolli protsess on väga range ja ma ei saa meie kvaliteedikontrolli piisavalt tänada. Algses plaastris oli vigu. Otsustasime selle ka ümber kirjutada. Samuti soovime konfiguratsioonimuutujate arvu poliitikatena vähendada. Lünkade lukustamisel oli mõned probleemid, mis tuli plaastrisse kinnitada.

CSRTales: Tavaliselt peab avatud lähtekoodiga kommuunides, näiteks Linuxi kernel, olema usaldusväärsus juba enne plaastrite vastuvõtmist üles ehitatud. Kas ma arvan, et siin juhtus midagi sarnast?

Sunny: Muidugi. Saame päris palju plaastreid / kaastöid. Kuid tahaksin rõhutada, et see ei ole eeltingimus. Oleme nõus aktsepteerima plaastreid, mis töötavad väljastpoolt ja kellel on dokumentatsioon, mis näitab probleemi ja seda, kuidas plaastrid neid probleeme lahendavad. Meie tõeline soov on julgustada teadlasi / kasutajaid / arendajaid kõiki, kellel on selle valdkonna vastu huvi, kasutama avatud lähtekoodiga eeliseid ja saatma meile oma plaastrid. Tahaksin rõhutada, jutt on odav. Näita mulle koodi :-)

CSRTales: kas on üldine tava kirjutatud plaastrid ümber kirjutada?

Sunny: Jah, kui me otsustame mõnele tööle pühenduda, eelistame seda teha täielikult meeskonnas. Sellel on praktilisi põhjuseid. Kvaliteedi tagamise protsess on üsna intensiivne ning koodide ülevaatamise ja probleemide jälgimise ümber on terve taristu, millele kõrvalistel kasutajatel pole juurdepääsu. Samuti peab koodi sisestanud isik hilisemate veaparanduste eest vastutama jne. Enamasti on praktilisuse tõttu see, et me ei saa originaalautoreid selle töö edenedes tegema. Me (tegelikult ma tegin) kirjutasime plaastri ümber. Jiamin, Dimitri, Barzan ja mina arutasime pidevalt e-posti teel, kus arutasime neid teemasid. Dimitri on meie etendusarhitekt. Nende panus oli väga kasulik tagamaks, et meil kõigil oleks nende ideede ümber sama vaimne mudel.

Tahaksin juhtida tähelepanu mitmele huvitavale asjale selles CSRTale. Esiteks on see suurepärane näide, kuidas saada tööstusharu omaks. Barzan ja tema grupp panid paika, mida sai otse testida. See on ülioluline. Teiseks veetsid Barzan ja tema grupp palju aega Sunnyga oma ideed arutades, et olla samal lehel. Tehnika ülekandmine võtab palju aega, lisaks ajalehe avaldamiseks kulutatud ajale. Kui otsite mõju, on see hea tee, kuid pidage meeles ajakulusid. Kolmandaks, kvaliteedi ülevaatamine ei ole laias süsteemiringkonnas väga järjepidev. Olen näinud arvustusi, mis on sarnased Barzani saadud kommentaaridega: minu arvates on teatud arvustajad (mitte kõik õnneks) kõigepealt meelt ja siis proovivad leida mis tahes vabanduse paberi tagasilükkamiseks. Nii et mõnikord on arvustused väga mürarikkad signaalid: võiksite mõelda, kui fikseeriksite selle, mida arvustaja nõudis, siis aktsepteeritaks teid, kuid see pole sageli nii. Teie paberil võib olla ka muid puudusi, mida võiksite paremini kulutada oma aja parandamisele. Näiteks kui teie paberil olevad ideed ei olnud selgelt kokku puutunud, ei pruugi arvustajale teie paber meeldida ja ta kaebab hinnangu üle. Hinnangu fikseerimine (ilma kirjutamist fikseerimata) ei parandaks teie tõenäosust nõustumiseks. Räägi sellest oma nõustajatega :)