CSR Tale # 8: Dlaczego okropne recenzje są dla Ciebie dobre!

Opowieść CSR nr 8 pochodzi od prof. Barzana Mozafari z Michigan. Barzan prowadzi grupę badawczą projektującą kolejną generację skalowalnych baz danych z wykorzystaniem zaawansowanych modeli statystycznych. Ostatnio ich algorytm planowania blokady VATS został przyjęty przez MySQL i MariaDB, więc rozmawiałem z Barzanem o tym, jak doszło do pracy nad VATS. Rozmawiałem również z jednym z ich współpracowników przemysłowych, Sunny Bains z Oracle, aby poznać branżową stronę tej historii. Ogólnie rzecz biorąc, to świetna opowieść CSR! Najpierw usłyszymy od Barzana:

To było lato 2013 roku. Właśnie zacząłem jako profesor ds. Kadencji na University of Michigan i próbowałem wymyślić, nad czym pracować. Podczas postdocu na MIT uczestniczyłem w wielu różnych projektach, od analityki (np. BlinkDB), po transakcje i przetwarzanie w chmurze (np. DBSeer) po crowdsourcing. Spośród nich DBSeer było zdecydowanie najtrudniejszym wyzwaniem, jakie kiedykolwiek podjąłem. Celem DBSeer było przewidzenie wydajności systemu bazy danych (w tym przypadku MySQL) przy obciążeniu pracą. Przez prawie dwa lata wypróbowałem każdy algorytm uczenia maszynowego w podręczniku. Chociaż mieliśmy pewne sukcesy w przewidywaniu wykorzystania zasobów (np. We / Wy dysku lub procesora), nasze wyniki były mierne, jeśli chodzi o przewidywanie faktycznego opóźnienia transakcji.

Były to dwa podstawowe powody. Po pierwsze, zdecydowaliśmy, że jesteśmy zainteresowani tylko nieinwazyjnymi rozwiązaniami. Na przykład, zamierzaliśmy przyjrzeć się tylko globalnym zmiennym statusu MySQL. Oznaczało to, że nie mieliśmy dostępu do niektórych krytycznych statystyk po prostu dlatego, że MySQL ich nie ujawnił. (Projekt Peloton Andy Pavlo to świetny sposób na rozwiązanie tego pierwszego problemu poprzez dostęp do wewnętrznych elementów bazy danych). Ale w tamtym czasie naszym uzasadnieniem było to, że jeśli moglibyśmy sprawić, by to zadziałało, przyjęcie DBSeer stałoby się oczywiste. Drugi powód był o wiele prostszy: MySQL po prostu nie był przewidywalnym systemem na początek! Możesz przesłać dokładnie to samo zapytanie w tych samych warunkach wiele razy, a za każdym razem nadal otrzymujesz bardzo różne opóźnienia! Przy tak dużym hałasie w sygnale nie ma wiele do zrobienia w uczeniu maszynowym. To takie proste. I powinienem zaznaczyć, że to nie był tylko MySQL: każdy inny DBMS, na który spojrzeliśmy, był równie nieprzewidywalny. „Nasi przodkowie, projektując te starsze systemy, byli zbyt skoncentrowani na przyspieszeniu ich, w wyniku czego nie mieli luksusu martwić się o ich przewidywalność”. A przynajmniej tak to wyglądało.

Tak więc, właśnie rozpocząłem pracę w Michigan i zdałem sobie sprawę, że jest świetna okazja, aby to zmienić raz na zawsze: sprawmy, aby systemy baz danych były bardziej przewidywalne, a nie tylko szybsze. Niedawno zwerbowałem Jiamina Huanga, imponującego studenta o niewiarygodnych umiejętnościach systemowych. Postanowiliśmy rozszyfrować, co może powodować nieprzewidywalność. Naszym pierwszym podejrzanym były błędy w pamięci podręcznej L2. Połączyliśmy siły z jednym z moich kolegów ze sprzętu (Tomem Wenisch), aby zbadać to i wiele innych potencjalnych przyczyn, ale bardzo szybko było to niemożliwe, aby rozwiązać to ręcznie, biorąc pod uwagę, jak skomplikowana była baza kodów MySQL. Wkrótce odkryliśmy, że tworzymy własny profiler, który w przeciwieństwie do Dtrace i innych profilerów, został specjalnie zaprojektowany, aby znaleźć podstawowe przyczyny różnic w wydajności w dużej i złożonej bazie kodu. Okazało się, że nasz profiler nie był specyficzny dla baz danych i ostatecznie przekształciliśmy go w VProfiler, a później opublikowaliśmy go na EuroSys 2017. Sprowadzono się do przeglądania milionów linii kodu, a następnie informowania programisty o kilku niezbędnych parach funkcji do użycia, aby aplikacja była przewidywalna.

Część naszych odkryć dotycząca bazy danych ma znacznie ciekawszą historię. VProfiler ujawnił grupę winowajców za spowodowanie nieprzewidywalności. Na przykład jednym z naszych ustaleń było to, że w MySQL „kolejkowanie” za współdzielonymi zasobami było główną przyczyną wariancji opóźnień. Z perspektywy czasu jest to bardzo intuicyjne: gdy N transakcji czeka w kolejce na ten sam współużytkowany zasób, kolejka przed kolejką doświadczy innego czasu oczekiwania niż ten na końcu kolejki i oba są będzie bardzo różny od tego w środku kolejki. Właśnie dlatego wykazują bardzo różne opóźnienia, aby wykonać tę samą ilość pracy.

Krótko mówiąc, skupiliśmy się na sposobie zarządzania kolejkami i, szokująco, zdaliśmy sobie sprawę, że każda baza danych na świecie wciąż używa jakiegoś wariantu FIFO (pierwsze weszło, pierwsze wyszło). Opracowaliśmy nowy algorytm o nazwie VATS (planowanie transakcji z uwzględnieniem wariancji), aby zmniejszyć wariancję, i opublikowaliśmy go w naszym dokumencie SIGMOD 2017 („Podejście odgórne do uzyskania przewidywalnej wydajności w systemach baz danych”). Jednym z największych wglądów, jakie to zapewniło, było to, że przewidywalność nie musi się wiązać z ceną średniej wydajności. Innymi słowy, istnieje sposób, aby uczynić systemy bardziej przewidywalnymi, jednocześnie przyspieszając je: poprzez zmniejszenie wariancji opartej na rywalizacji.

Później sformułowaliśmy ogólny problem szeregowania zamków. Zbadaliśmy inny, nowatorski algorytm, który był optymalny pod kątem zmniejszenia średniego opóźnienia (i zwiększenia przepustowości) i opublikowany w VLDB 2018 („Planowanie blokad uwzględniające rywalizację w transakcyjnych bazach danych”). Ten nowy algorytm nazwaliśmy VATS 3.0 (nigdy nie publikowaliśmy VATS 2.0), który później nazwaliśmy CATS (planowanie transakcji uwzględniające rywalizację).

Harmonogram transakcji uwzględniający rywalizację: przyznanie blokady na O1 do t1 umożliwia większą równoległość (zmniejsza więcej rywalizacji) niż przyznanie jej do t2

Z punktu widzenia przyjęcia w branży sprawy potoczyły się dość sprawnie: zarówno MySQL, jak i MariaDB przeprowadziły własne testy porównawcze z naszym nowym algorytmem i zdecydowały się na zastosowanie go w swoich niezależnych wersjach (MySQL uczynił to nawet ich domyślną strategią). Jesteśmy wdzięczni wszystkim naszym współpracownikom open source ze społeczności MySQL, w tym bezcennym opiniom i pomocy Jana Lindstroma (MariaDB), Sunny Bains i Dimitri Kravtchuk (Oracle), Laurynas Biveinis i Alexey Stroganov (Percona), Mark Callaghan ( Facebook) i Daniel Black (IBM).

Jednak z akademickiego punktu widzenia sprawy nie potoczyły się tak gładko. Oto harmonogram tego, co się wydarzyło:

Oświadczenie: Niektóre nazwy / lata konferencji mogły być inne

  • SIGMOD’16: Przesłaliśmy nasze wyniki MySQL.
  • Odrzucenie: „Skąd wiemy, czy to działa na coś innego niż MySQL?”

Komentarz: Co ciekawe, takie komentarze otrzymujesz tylko wtedy, gdy zastosujesz swój pomysł w prawdziwym systemie. Jeśli po prostu prototypujesz swój pomysł od podstaw i tworzysz makietową bazę danych, zwykle nikt nie zapyta, czy dotyczy on innych prawdziwych systemów! Niezrażony tymi komentarzami mój uczeń postanowił udowodnić, że recenzent się myli…

  • VLDB’16: Zastosowaliśmy VProfile do Postgres i VoltDB.
  • Odrzucenie: „Gdyby ten problem był wystarczająco ważny, ktoś już by to zrobił!”

Komentarz: Do dziś jest to jedna z moich ulubionych recenzji! Otrzymanie niesprawiedliwej recenzji nigdy nie jest zabawne, ale ta była tak absurdalna, że ​​nie przeszkadzało nam to - w rzeczywistości uważaliśmy, że jest dość zabawna. Chociaż szkoda, że ​​nie mieliśmy okazji zadać temu recenzentowi dwóch pytań:

1) Czy recenzent porównuje swoje badania do tego samego paska? (Wiemy, że to był „on”; patrz lekcja 5.)

2) Jak moglibyśmy kiedykolwiek osiągnąć postęp w badaniach, stosując tę ​​zasadę? Jeśli coś już zostało zrobione, to nie jest nowe i publikowane, a jeśli nie zostało to zrobione, to po prostu nie jest wystarczająco ważne i publikowanie ich nie musi mieć sensu!

  • OSDI’16: Niemniej jednak mój uczeń ponownie postanowił udowodnić, że recenzent się mylił i udowodnić, że problem jest prawdziwy. Wysłaliśmy więc nasze algorytmy i wyniki zarówno do MariaDB, jak i MySQL. VATS został wybrany przez MySQL jako domyślny harmonogram i wspominaliśmy o tym w artykule.
  • Odrzucenie: „Zastosowałeś VProfiler do MySQL, Postgres i VoltDB. Skąd wiemy, czy to działa na coś innego niż DBMS? ”

Komentarz: To był uczciwy problem. W końcu OSDI to konferencja OS. Byliśmy bardzo zadowoleni z jakości otrzymanych recenzji. Jako badacz DB zawsze zazdroszczę społeczności systemów operacyjnych za znacznie lepszy system recenzji.

  • SIGMOD’17: Przekazaliśmy VATS i inne ustalenia bazy danych.
  • Zaakceptować! Wreszcie!
  • EuroSys’17: Uogólniliśmy nasz profiler, który później stał się VProfiler i zastosował się do serwera WWW Apache oprócz systemów baz danych.
  • Zaakceptować! Tak!
  • VLDB’18: W końcu, kiedy udało nam się sformalizować problem z planowaniem blokady, byliśmy w stanie rozwiązać również wydajność (nie tylko przewidywalność). Stało się to algorytmem CATS.
  • Zaakceptować. Mamy naprawdę świetne recenzje z VLDB'18. Otrzymaliśmy także wyjątkową informację zwrotną od Petera Bailisa po opublikowaniu artykułu.

Oto kilka lekcji z tego długiego postu:

Lekcja 1. Straszne recenzje są dla ciebie dobre. Popychają ciebie (i twojego ucznia!) Do wykonania większej pracy, co nie jest złym rezultatem!

Lekcja 2. Nie ufaj temu, co ludzie mówią na panelach. Mimo że wszyscy w środowisku akademickim zapisywali się na temat doceniania rzeczywistego wpływu i prawdziwych walidacji, niektórzy z nich czasami podświadomie kłamią. Kiedy noszą czapkę recenzenta, często karzą artykuły, które używają prawdziwego systemu oceny, np. Prosząc o miliard innych rzeczy, które byłyby możliwe tylko przy użyciu prototypowej symulacji. Nie mam na myśli, że powinieneś zrezygnować z używania prawdziwych systemów w swoich eksperymentach, ale po prostu bądź przygotowany na więcej pracy!

Lekcja 3. Środowisko akademickie i przemysł mają różne długości fal. Dla nas w środowisku akademickim trzy miesiące wydają się wiecznością. Zespoły ds. Produktów działają jednak na własnej osi czasu - czasem może minąć nawet rok, zanim będą mieli dla Ciebie jakieś cykle. Musisz tylko uzbroić się w cierpliwość i docenić wspaniałą pracę, jaką wykonują, utrzymując wysokiej jakości ekosystem open source.

Lekcja 4. Nie każdy recenzent jest matematykiem. W jednym z naszych wcześniejszych zgłoszeń podaliśmy odsetek całkowitej wariancji, którą wyeliminowaliśmy, co stanowi około 65%. Oczywiście nie można niczego wyeliminować o więcej niż 100%. Niestety, to tylko ograniczenie praw matematyki. Ale jedna z naszych recenzji (myślę, że SIGMOD’16 lub VLDB’16) była zdania, że ​​redukcja o 65% nie jest wystarczająco znacząca. Dlatego w naszym kolejnym zgłoszeniu przeszliśmy na raportowanie współczynnika poprawy, zdefiniowanego jako wariancja oryginalnego MySQL podzielona przez wariancję naszej zmodyfikowanej wersji. Tę samą 65% redukcję zgłoszono teraz jako 3-krotną redukcję wariancji, a recenzenci (choć prawdopodobnie inni ludzie) byli tym razem bardziej zadowoleni.

Lekcja 5. Bądź miły lub anonimowy. Dotyczy to naszego ulubionego recenzenta: jeśli masz zamiar napisać nieprzyjemną recenzję, prawdopodobnie nie jest dobrym pomysłem, aby poprosić autorów o zacytowanie trzech własnych artykułów. Zachowanie Twojej anonimowości nie wypada dobrze ☺

Lekcja 6. Praca na prawdziwych systemach jest uciążliwa, ale całkowicie się opłaca. Jeśli chcesz pogodzić się z kiepskimi recenzjami i znacznie wydłużyć czas oczekiwania na pracę, praca na prawdziwych systemach jest niezwykle satysfakcjonującym doświadczeniem!

Przejdźmy do przemysłowej perspektywy tej pracy. Rozmawiałem z Sunny Bains z Oracle, który odegrał kluczową rolę w przyjęciu VATS do MySQL / InnoDB. Przedstawiam swoją rozmowę z nim w formie pytań i odpowiedzi.

CSRTales: Jak dowiedziałeś się o pracy CATS?

Sunny: IIRC Barzan i Jiamin opublikowali artykuł z testami porównawczymi, który został przekazany mi przez kogoś z naszej organizacji. Następnie wnieśli łatkę, która mnie zainteresowała. Blokowanie zawsze wymaga pewnej optymalizacji lub innej, a my wtedy staraliśmy się zoptymalizować menedżera blokad InnoDB. Dlatego było bardzo aktualne. CATS, jak go nazywano, wydawał się obiecującym kandydatem do obejrzenia. Na tym etapie byliśmy zbyt wąsko skoncentrowani na jednolitym rozmieszczeniu i nie zauważyliśmy żadnych korzyści. Ponadto skupiono się na naprawianiu innych rzeczy w InnoDB. Gdy mieliśmy już dobre rozwiązania innych problemów związanych z zarządzaniem transakcjami w InnoDB, problemy z blokowaniem znów stały się priorytetem. Zespół InnoDB zaczął ponownie patrzeć na CATS i przypadkiem Mark Callaghan z Facebooka wysłał mi e-maila następnego dnia, przedstawiając mnie Barzanowi i Jiaminowi. Potem zaczęła się ściślejsza współpraca, a dzięki bezpośredniej komunikacji i ich pomocy wszystko zaczęło się z górki.

CSRTales: Co najbardziej podobało Ci się w pomyśle CATS, kiedy o nim usłyszałeś?

Sunny: Rozwiązał prawdziwy problem, a sama treść jest bardzo ogólna i myślę, że ma aplikacje wykraczające poza menedżera zamków. Równie ważne z praktycznego punktu widzenia jest to, że przyszedł z dowodem koncepcji. Łatka, którą moglibyśmy przetestować od razu. Krąży wiele dobrych pomysłów. Posiadanie czegoś konkretnego do przetestowania jest OGROMNYM plusem. Oszczędza nam dużo czasu i zasobów. Myślę też, że jest to jedna z zalet oprogramowania typu open source. To bardzo dobry przykład tego.

CSRTales: Ile czasu zajęło pierwsze usłyszenie o pracy i połączenie jej?

Sunny: Myślę, że zajęło to około roku. Od kiedy postanowiliśmy się do tego zobowiązać, do momentu, w którym faktycznie został popchnięty, zajęło to sześć miesięcy. Nasz proces kontroli jakości jest bardzo rygorystyczny i nie mogę wystarczająco podziękować naszej kontroli jakości. W oryginalnej łatce było kilka błędów. Postanowiliśmy go też przepisać. Chcemy również zmniejszyć liczbę zmiennych konfiguracyjnych jako zasady. Były pewne problemy z blokadami luk, które musiały zostać naprawione w łatce.

CSRTales: Zazwyczaj w społecznościach typu open source, takich jak jądro Linuksa, musisz mieć już zbudowaną wiarygodność, zanim łatki zostaną zaakceptowane. Zgaduję, że stało się tutaj coś podobnego?

Sunny: Oczywiście. Otrzymujemy sporo poprawek / wkładów. Chciałbym jednak podkreślić, że nie jest to warunek konieczny. Jesteśmy otwarci na akceptowanie poprawek, które działają od razu po wyjęciu z pudełka, i dysponujemy dokumentacją, która demonstruje problem i sposób, w jaki poprawki rozwiązują te problemy. Naszym prawdziwym pragnieniem jest zachęcenie badaczy / użytkowników / deweloperów każdego, kto jest zainteresowany tą dziedziną, do korzystania z zalet otwartego oprogramowania i przesyłania nam swoich poprawek. Chciałbym podkreślić, rozmowa jest tania. Pokaż mi kod :-)

CSRTales: Czy powszechną praktyką jest przepisywanie poprawek?

Sunny: Tak, kiedy zdecydujemy się na jakąś pracę, wolimy, aby była ona wykonywana całkowicie w zespole. Istnieją praktyczne powody tego. Proces kontroli jakości jest dość intensywny, a wokół recenzji kodu i śledzenia problemów istnieje cała infrastruktura, do której osoby z zewnątrz nie będą miały dostępu. Ponadto osoba, która popełnia kod, musi przejąć na własność w celu późniejszych poprawek błędów itp. Wynika to głównie z praktyczności, ponieważ nie otrzymujemy oryginalnych autorów do wykonywania pracy w miarę jej postępu. My (właściwie to zrobiłem) przepisałem łatkę. Stała wymiana wiadomości e-mail między Jiaminem, Dymitrem, Barzanem i mną w celu omówienia problemów. Dimitri jest naszym architektem wydajności. Ich wkład był bardzo pomocny w zapewnieniu, że wszyscy mieliśmy ten sam model mentalny wokół ich pomysłów.

Chciałbym wskazać kilka interesujących rzeczy w tym CSRTale. Po pierwsze, jest to świetny przykład tego, jak uzyskać adopcję w branży. Barzan i jego grupa wnieśli łatkę, którą można było przetestować bezpośrednio. To jest kluczowe. Po drugie, Barzan i jego grupa spędzili dużo czasu omawiając swój pomysł ze Sunny, aby upewnić się, że są na tej samej stronie. Transfer technologii zajmuje dużo czasu, ponad czas poświęcony na publikację artykułu. Jeśli szukasz efektu, jest to świetna ścieżka, ale pamiętaj o kosztach czasu. Po trzecie, przegląd jakości nie jest zbyt spójny w szerokiej społeczności systemów. Widziałem recenzje podobne do tych, które otrzymał Barzan: uważam, że niektórzy recenzenci (nie wszyscy na szczęście) najpierw podejmują decyzję, a następnie próbują znaleźć jakąkolwiek wymówkę, by odrzucić artykuł. Czasami więc recenzje są bardzo głośnymi sygnałami: możesz pomyśleć, że jeśli naprawisz to, o co prosił recenzent, zostaniesz zaakceptowany, ale nie jest to często prawdą. W twoim dokumencie mogą występować inne słabości, które lepiej poświęcić na naprawianie. Na przykład, jeśli pomysły w twoim artykule nie były jednoznacznie określone, recenzentowi może się nie spodobać i narzekać na ocenę. Naprawienie oceny (bez poprawienia zapisu) nie zwiększy twoich szans na akceptację. Porozmawiaj o tym ze swoimi doradcami :)