A CSR 8. története: Miért jó a szörnyű vélemények neked!

A CSR Tale # 8 professzor, Barzan Mozafari, Michigan. Barzan vezet egy kutatócsoportot, amely fejlett statisztikai modellek segítségével tervezi a skálázható adatbázisok következő generációját. Nemrégiben a MySQL és a MariaDB elfogadta a VATS zárolási ütemezési algoritmusát, így Barzan-nal beszélgettem arról, hogy hogyan kell elvégezni az VATS-munkát. Beszélgettem az egyik ipari kollégájukkal, az Oracle Sunny Bains-szel is, hogy megkapják a történet ipari oldalát. Összességében nagyszerű CSR mesét eredményez! Először halljuk Barzant:

2013 nyarán volt. Épp most kezdtem hivatali idejű professzorként a Michigan-i Egyetemen, és próbáltam kitalálni, mihez dolgozom. A MIT-ben folytatott posztdokumentum során számos különféle projektben részt vettem, az analitikától (például BlinkDB), a tranzakciókig és a felhőalapú számítástechnikáig (például a DBSeer-től) a tömegforrásig. Ezek közül a DBSeer messze volt a legnehezebb kihívás, amelyet valaha felvettem. A DBSeer-rel a cél az volt, hogy előre jelezze egy adatbázis-rendszer (ebben az esetben a MySQL) teljesítményét a munkaterhelés függvényében. Közel két év alatt kipróbáltam a gépi tanulási algoritmusokat a tankönyvben. Miközben sikerrel jártunk az erőforrás-felhasználás előrejelzésében (például a lemez IO vagy a CPU), az eredményeink közepes voltak, amikor a tranzakciók tényleges késése volt megjósolni.

Ennek két alapvető oka volt. Először úgy döntöttünk, hogy csak a nem behatoló megoldások érdekli őket. Például csak a MySQL globális státusú változóit vizsgálnánk. Ez azt jelentette, hogy nem tudtunk hozzáférni bizonyos kritikus statisztikákhoz, csak azért, mert a MySQL nem tette ki őket. (Andy Pavlo Peloton projektje nagyszerű módszer az első probléma kezelésére azáltal, hogy hozzáférést biztosít az adatbázis belső részéhez). De abban az időben az volt az indokunk, hogy ha el tudjuk végezni ezt a munkát, akkor a DBSeer elfogadása nem bátor. A második ok sokkal egyértelműbb volt: a MySQL csak nem volt kiszámítható rendszer, amely kezdetben lenne! Pontosan ugyanazt a lekérdezést küldheti el ugyanolyan feltételek mellett, többször is, és mindig eltérő késéseket kaphat! Ha egy jelben ilyen sok zaj van, a gépi tanuláshoz nem sok minden szükséges. Ilyen egyszerű. És ki kell emelnem, hogy ez nem csak a MySQL volt: minden más DBMS, amelyet megnézünk, ugyanolyan kiszámíthatatlan volt. „Őseink, amikor ezeket a régi rendszereket tervezték, túl koncentráltak arra, hogy gyorsabbá tegyék őket, és ennek eredményeként nem volt luxusuk aggódni kiszámíthatóságuk miatt.” Vagy legalábbis így tűnt.

Szóval ott voltam, amikor csak Michiganben kezdtem, és rájöttem, hogy nagyszerű lehetőség megváltoztatni ezt egyszer és mindenkorra: tegyük az adatbázis-rendszereket kiszámíthatóbbá, nem csak gyorsabban. Nemrégiben toboroztam Jiamin Huang-t, egy lenyűgöző hallgatót, aki hihetetlen rendszertudással rendelkezik. Meghatároztuk, hogy mi okozhatja a kiszámíthatatlanságot. Az első gyanúnk az L2 gyorsítótár hiánya volt. Összeálltunk az egyik hardver kollégámmal (Tom Wenisch), hogy kivizsgáljuk ezt és számos más lehetséges okot, ám ezt a manuális megoldást nagyon gyorsan lehetetlen képessé vált, tekintettel a MySQL kódbázis összetettségére. Hamarosan azt találtuk, hogy saját profilkészítőt készítünk, amelyet a Dtrace-tól és más profilozóktól eltérően kifejezetten arra terveztek, hogy egy nagy és összetett kódbázisban megtalálja a teljesítmény-variancia kiváltó okait. Kiderült, hogy profilozónk nem az adatbázisokra vonatkozik, és végül VProfilerré alakítottuk, majd később közzétettük az EuroSys 2017-ben. A millió millió sornyi kódot nézegette, majd néhány szükséges pár fejlesztőjét értesítette a fejlesztőről. az alkalmazások kiszámíthatóságához szükséges funkciók száma.

Megállapítások adatbázis-része sokkal érdekesebb történetet tartalmaz. A VProfiler egy csomó tettet fedezett fel kiszámíthatatlanság miatt. Például egyik megállapításunk az volt, hogy a MySQL-ben a várakozási sorrend a megosztott erőforrások mögött volt a latencia-szórás fő oka. Utólagosan ez nagyon intuitív: amikor N tranzakció vár egy sorban ugyanahhoz a megosztott erőforráshoz, a sor előtt állónak nagyon más várakozási időre lesz szüksége, mint a sor végén, és mindkettő nagyon különbözik attól, mint a sor közepén. Ez az oka annak, hogy nagyon különböző késleltetési időkkel bírnak, hogy ugyanazt a munkát végezzék.

Röviden: a várakozási sorok kezelésére összpontosítottuk a figyelmet, és megdöbbentően rájöttünk, hogy a világ minden egyes adatbázisa továbbra is a FIFO valamilyen változatát használja (first-in, first-out). Egy új algoritmust, a VATS (Variance-Aware Transaction Scheduling) néven állítottunk elő, hogy csökkentsük a varianciát, és közzétettük azt a SIGMOD 2017 tanulmányunkban („Felülről lefelé mutató megközelítés a teljesítmény-kiszámíthatóság eléréséhez az adatbázis-rendszerekben”). Az általam felkínált nagyszerű betekintés az volt, hogy a kiszámíthatóságnak nem az átlagos teljesítmény árán kell lennie. Más szavakkal, van mód arra, hogy a rendszerek kiszámíthatóbbá tegyék azokat, miközben gyorsabbá teszik őket: az érvelésen alapuló szórás csökkentésével.

Később megfogalmaztuk a zárolás ütemezésének általános problémáját. Megvizsgáltunk egy másik, újszerű algoritmust, amely optimális volt az átlagos késés csökkentéséhez (és az átviteli sebesség növeléséhez), és amelyet a VLDB 2018-ban publikáltak („Konkurzustudatos zárolási ütemezés tranzakciós adatbázisokhoz”). Ezt az új algoritmust VATS 3.0-nak hívtuk (soha nem tettük közzé VATS 2.0-t), amelyet később CATS-nek (Contents-Aware Transaction Scheduling) neveztek.

A vitatott ügyletek tranzakcióinak ütemezése: Az O1 – t1 rögzítésének megadása több párhuzamosságot eredményez (több érvelést csökkent), mint a t2-hez való megadása.

Iparági elfogadás szempontjából a dolgok meglehetősen simán mentek: mind a MySQL, mind a MariaDB futtatta saját referenciapontjait az új algoritmusunkkal, és úgy döntött, hogy önálló verziókba fogadja el (a MySQL még alapértelmezett stratégiává tette). Hálásak vagyunk minden MySQL közösségben működő nyílt forrású együttműködőnknek, beleértve felbecsülhetetlen visszajelzéseket és segítséget Jan Lindstrom (MariaDB), Sunny Bains és Dimitri Kravtchuk (Oracle), Laurynas Biveinis és Alexey Stroganov (Percona), Mark Callaghan ( Facebook) és Daniel Black (IBM).

Tudományos szempontból azonban a dolgok nem mentek annyira simán. Itt van egy idővonal, ami történt:

Jogi nyilatkozat: Lehet, hogy a konferencia neveinek / éveinek néhánya más volt

  • SIGMOD’16: Elküldtük a MySQL eredményeinket.
  • Elutasítás: „Honnan tudhatjuk, hogy a MySQL-en kívül másra is működik?”

Kommentár: Érdekes módon az ilyen jellegű megjegyzéseket csak akkor kapja meg, ha ötleteit egy valódi rendszerre alkalmazza. Ha egyszerűen prototípust készít az ötletedről, és létrehoz egy makett adatbázist, általában senki sem kérdezi, hogy vonatkozik-e ez más valós rendszerekre! Ezeknek a megjegyzéseknek a hiányában a hallgató úgy döntött, hogy hibásnak bizonyítja a recenzent…

  • VLDB’16: A VProfile-t a Postgres-re és a VoltDB-re is alkalmaztuk.
  • Elutasítás: „Ha ez a probléma elég fontos lenne, valaki más már megtette volna!”

Kommentár: A mai napig ez még mindig az egyik kedvenc véleményem! A tisztességtelen vélemény fogadása soha nem szórakoztató, de ez annyira nevetséges volt, hogy nem zavart minket - valójában nagyon szórakoztatónak találta. Bár szeretnénk, ha lehetősége lett volna rá, két kérdést feltenni az értékelőnek:

1) A recenzens ugyanazon oszlop alapján méri a saját kutatását? (Tudjuk, hogy „ő” volt; lásd az 5. leckét.)

2) Hogyan érhetnénk el haladást a kutatásban ezen elv alkalmazásával? Ha valami már megtörtént, akkor nem új és közzétehető, és ha nem történt meg, akkor ez csak nem elég fontos, és nem szabad értelmezni őket!

  • OSDI’16: Ennek ellenére a hallgatóm ismét úgy döntött, hogy bebizonyítja, hogy a recenzens helytelen, és bebizonyítja, hogy a probléma valós. Tehát elküldtük algoritmusainkat és eredményeinket a MariaDB-hez és a MySQL-hez is. A VATS-t a MySQL választotta alapértelmezett ütemezésként, és megemlítettük a cikkben.
  • Elutasítás: „A VProfilert alkalmazta a MySQL, a Postgres és a VoltDB számára. Honnan tudhatjuk, hogy a DBMS-en kívül másra is működik? ”

Kommentár: Ez komoly aggodalomra ad okot. Végül is az OSDI egy OS konferencia. Valójában nagyon elégedettek voltunk a kapott vélemények minőségével. DB kutatóként mindig irigylem az operációs rendszer közösségét a jelentősen jobb áttekintési rendszerük iránt.

  • SIGMOD’17: benyújtottuk az VATS és más adatbázis-megállapításokat.
  • Elfogad! Végül!
  • EuroSys’17: Általánosítottuk profilolónkat, amely később VProfiler lett, és az adatbázis-rendszerek mellett az Apache webszerverre is alkalmazta.
  • Elfogad! Hurrá!
  • VLDB'18: Végül, amint sikerült formalizálnunk a zárolási ütemezési problémát, a teljesítmény szempontjából is meg tudtuk oldani a problémát (nem csak a kiszámíthatóság). Ez lett a CATS algoritmus.
  • Elfogad. Nagyon jó véleményeket kaptunk a VLDB'18-tól. Kivételes visszajelzéseket kaptunk Peter Bailis-től a cikk közzététele után.

Tehát itt van néhány lecke ebből a hosszú üzenetből:

1. lecke. A szörnyű vélemények valóban jók az Ön számára. Arra ösztönzik téged (és a hallgatódat!), Hogy több munkát végezzenek, ami nem rossz eredmény!

2. lecke. Ne bízzon abban, amit az emberek a paneleken mondanak. Annak ellenére, hogy az akadémiai körzetben mindenki nyilvánvalóan értékelné a valós hatás és a valós érvényesítések értékelését, néhányuk néha tudatalattilag hazudik. Ha átalakító kalapot visel, gyakran megbünteti azokat az iratokat, amelyek valódi értékelési rendszert használnak, például egy milliárd más dolog kérésével, amely csak akkor lehetséges, ha prototípus-szimulációt használsz. Nem azt értem, hogy feladnia kellene a valós rendszerek használatát a kísérleteiben, hanem egyszerűen fel kell készülnie a további munkák elvégzésére!

3. lecke. Az akadémia és az ipar eltérő hullámhosszú. Akiknek az akadémiai életben a három hónap örökkévalóságnak érzi magát. A termékcsoportok azonban a saját ütemtervükön futnak - néha akár egy évig is eltarthat, mialatt bármilyen ciklus megtörténik az Ön számára. Csak türelmesnek kell lennie, és értékelnie kell azt a nagyszerű munkát, amelyet a jó minőségű, nyílt forrású ökoszisztéma fenntartásában végeznek.

4. lecke. Nem minden recenzens van matematikus. Az egyik korábbi beadványunkban a teljes variancia százalékos arányát jelentettük, amelyet megszüntettünk, ami körülbelül 65% volt. Nyilvánvaló, hogy nem távolíthat el semmit több, mint 100% -kal. Sajnos ez csak a matematikai törvények korlátozása. De az egyik véleményünk (azt hiszem, a SIGMOD'16 vagy a VLDB’16) azon a véleményen volt, hogy a 65% -os csökkentés nem elég jelentős. Tehát a következő beküldésünkben átváltottuk a fejlesztési arány jelentésére, amelyet az eredeti MySQL szórásának és a módosított verziónk varianciájának meghatározásával határozunk meg. Ugyanezt a 65% -os csökkenést jelentették, mint a variancia háromszoros csökkenését, és az értékelők (bár valószínűleg különböző emberek) ezúttal boldogabbak voltak.

5. lecke. Légy kedves vagy légy névtelen. Ez vonatkozik a kedvenc recenzensünkre: Ha csúnya recenziót írsz, valószínűleg nem jó ötlet felkérni a szerzőket, hogy idézjenek három saját írást. Ez nem megfelelő a névtelenség megőrzésével ☺

6. lecke. A valódi rendszerekkel való munka fájdalom, de megéri. Ha hajlandó megbirkózni a rossz véleményekkel és lényegesen hosszabb papíridővel, a valódi rendszerekkel való munka rendkívül hálás!

Lehetővé teszi a munka ipari perspektívájának átváltását. Csevegtem az Oracle Sunny Bains-szel, aki hozzájárult ahhoz, hogy az VATS bekerüljön a MySQL / InnoDB-be. Bemutatom vele folytatott beszélgetését mint kérdést és kérdést.

CSRTales: Hogyan tudta meg először a CATS működését?

Napos: Az IIRC Barzan és Jiamin közzétett egy referenciaértékű dokumentumot, amelyet a szervezetünk valaki továbbított nekem. Ezután egy javítást készítettek, ami engem érdekelt. A zároláshoz mindig vagy valamilyen optimalizálásra van szükség, és abban az időben az InnoDB zárkezelő optimalizálására törekedtünk. Ezért nagyon időszerű volt. A CATS, ahogyan akkor hívták, ígéretesnek tűnt, hogy megvizsgálja. Ebben a szakaszban túlságosan szűken összpontosítottunk az egységes elosztásra, és nem láttuk előnyeit. Emellett a hangsúly a más dolgok rögzítésére irányult az InnoDB-en belül. Miután az InnoDB-en belül volt néhány jó megoldás a tranzakciókezelés körüli egyéb kérdésekre, a zárolási kérdések ismét előtérbe kerültek. Az InnoDB csapata újból megnézte a CATS-t, és véletlenül véletlenszerűen Mark Callaghan a Facebook-ból küldte nekem egy e-mailt, a következő napon bemutatva Barzant és Jiaminot. A szorosabb együttműködés ezután kezdődött, közvetlen kommunikációval és segítségükkel mind odafelé volt.

CSRTales: Mi tetszett a legjobban a CATS ötletről, amikor hallottál róla?

Sunny: Valódi problémával foglalkozott, és maga a tartalom nagyon általános, és azt hiszem, hogy a zárkezelőn kívül is van alkalmazás. Gyakorlati szempontból ugyanolyan fontos, hogy a koncepció igazolását kapta. Egy javítás, amelyet azonnal kipróbálhatunk. Sok jó ötlet lebeg körül. Hatalmas plusz az, ha valami konkrét tesztelésre van szükség. Nagyon sok időt és erőforrást takarít meg nekünk. Azt is gondolom, hogy ez a nyílt forráskódú szoftverek egyik előnye. Ez egy nagyon jó példa erre.

CSRTales: Mennyi ideig tartott a munka első meghallgatásától az összeolvadásig?

Sunny: Azt hiszem, körülbelül egy évbe telt. Attól a pillanattól kezdve, amikor elhatároztuk, hogy elkötelezzük magát és a tényleges tolódásig, hat hónap telt el. Minőségi minőségbiztosítási folyamatunk nagyon szigorú, és nem tudom elég köszönetet mondani a minőségbiztosítási minőségünknek. Volt néhány hiba az eredeti javításban. Úgy döntöttünk, hogy újraírjuk. Azt is szeretnénk csökkenteni a konfigurációs változók számát, mint házirendet. Volt néhány probléma a részárakkal, amelyeket rögzíteni kellett a javításban.

CSRTales: Általában olyan nyílt forrású közösségekben, mint például a Linux kernel, a javítások elfogadása előtt már meg kell építeni a hitelességet. Gondolom, hogy valami hasonló történt itt?

Napos: Természetesen. Nagyon sok javítást / hozzájárulást kaptunk. De szeretném hangsúlyozni, hogy ez nem előfeltétel. Nyitottak vagyunk azoknak a javításoknak a elfogadására, amelyek nem működnek a dobozban, és rendelkeznek valamilyen dokumentációval, amely bemutatja a problémát és a javítások megoldását. Valódi vágyunk arra ösztönzi a kutatókat / felhasználókat / fejlesztőket, hogy bárki érdeklődjön ezen a területen, hogy kiaknázza a nyílt forráskód előnyeit, és küldje el nekünk javításainkat. Szeretnék hangsúlyozni, a beszélgetés olcsó. Mutasd meg a kódot :-)

CSRTales: Általános gyakorlat a beküldött javítások átírása?

Sunny: Igen, ha úgy döntünk, hogy elkötelezzük magunkat valamilyen munkával, akkor inkább azt szeretjük, ha azt teljes egészében a csapaton belül végzik el. Ennek gyakorlati okai vannak. A minőségbiztosítási folyamat meglehetősen intenzív, és a kódok áttekintése és a problémakövetés körül egy teljes infrastruktúra működik, amelyhez a kívülállók nem férnek hozzá. A kódot kiadó személynek a későbbi hibajavításokról stb. Is felelősséget kell vállalnia. Ez elsősorban a gyakorlati okokból adódik, hogy nem kapunk eredeti szerzőket arra, hogy a munka előrehaladtával elvégezzék a munkát. Mi (valójában megtettem) újraírtuk a javítást. Folyamatos e-mail csere folyt Jiamin, Dimitri, Barzan és én köztem a kérdések megvitatása között. Dimitri a mi teljesítmény-építészünk. Hozzájárulásuk nagyon hasznos volt annak biztosításában, hogy mindannyian ugyanazt a mentális modellt alkalmazzuk ötleteik körül.

Számos érdekes dolgot szeretnék rámutatni a CSRTale-ben. Először is, ez egy nagyszerű példa arra, hogyan lehet az iparágba bevezetni. Barzan és csoportja javításokat készített, amelyek közvetlenül tesztelhetők voltak. Ez elengedhetetlen. Másodszor, Barzan és csoportja sok időt töltött azzal, hogy megbeszéljék ötletüket Sunnyval, hogy megbizonyosodjanak arról, hogy ugyanazon az oldalon vannak-e. A technikai átadás sok időt vesz igénybe, túl a papír kiadására fordított időn túl. Ha hatást keres, ez egy nagyszerű út, de vegye figyelembe az időköltséget. Harmadszor, a minőség felülvizsgálata nem nagyon következetes a széles rendszerközösségben. Láttam olyan értékeléseket is, mint amilyeneket Barzan kapott: az a véleményem, hogy egyes áttekintők (nem mindenkinek szerencsére) először gondolkodnak, majd mindenféle ürügyet keresnek a papír elutasításához. Tehát néha az értékelések nagyon zajos jelek: gondolhatja, ha rögzíti azt, amit a recenzens kér, elfogadni fog, de ez nem gyakran fordul elő. Lehet, hogy más gyengeségek is vannak a papírjában, amelyek miatt jobban költi az idejét. Például, ha a cikkben szereplő ötletek nem találkoztak egyértelműen, akkor a recenzensnek nem tetszik az ön cikke, és panaszkodnak az értékelésről. Az értékelés rögzítése (az írás rögzítése nélkül) nem javítja az elfogadási esélyeit. Beszéljen erről tanácsadóival :)