Wkład Yandex w następujące bazy danych zostanie poddany przeglądowi.
- Kliknij Dom
- Odyssey
- Odzyskiwanie do punktu w czasie (WAL-G)
- PostgreSQL (w tym błędy logów, Amcheck, heapcheck)
- Zielona śliwka
Video:
Witaj świecie! Nazywam się Andriej Borodin. W Yandex.Cloud zajmuję się tworzeniem otwartych relacyjnych baz danych w interesie klientów Yandex.Cloud i Yandex.Cloud.
Podczas tej prelekcji będziemy rozmawiać o wyzwaniach stojących przed otwartymi bazami danych na dużą skalę. Dlaczego to jest ważne? Bo małe, małe problemy, które niczym komary zamieniają się w słonie. Stają się duże, gdy masz wiele klastrów.
Ale nie to jest najważniejsze. Dzieją się niesamowite rzeczy. Rzeczy, które zdarzają się raz na milion. W środowisku chmurowym trzeba być na to przygotowanym, ponieważ niesamowite rzeczy stają się wysoce prawdopodobne, gdy coś istnieje na dużą skalę.
Ale! Jaka jest zaleta otwartych baz danych? Faktem jest, że masz teoretyczną możliwość poradzenia sobie z każdym problemem. Masz kod źródłowy, masz wiedzę programistyczną. Łączymy to i działa.
Jakie podejścia są stosowane w pracy nad oprogramowaniem typu open source?
- Najprostszym podejściem jest użycie oprogramowania. Jeśli używasz protokołów, jeśli używasz standardów, jeśli używasz formatów, jeśli piszesz zapytania w oprogramowaniu open source, to już to wspierasz.
- Powiększasz jego ekosystem. Zwiększasz prawdopodobieństwo wczesnego wykrycia błędu. Zwiększasz niezawodność tego systemu. Zwiększasz dostępność deweloperów na rynku. Udoskonalasz to oprogramowanie. Jesteś już współtwórcą, jeśli właśnie nabrałeś stylu i majstrowałeś przy czymś.
- Innym zrozumiałym podejściem jest sponsorowanie oprogramowania typu open source. Na przykład dobrze znany program Google Summer of Code, w ramach którego Google płaci dużej liczbie studentów z całego świata zrozumiałe pieniądze, aby opracowywali projekty otwartego oprogramowania spełniające określone wymagania licencyjne.
- Jest to bardzo interesujące podejście, ponieważ pozwala na ewolucję oprogramowania bez odwracania uwagi od społeczności. Google, jako gigant technologiczny, nie mówi, że chcemy tej funkcji, chcemy naprawić ten błąd i tu musimy kopać. Google mówi: „Rób, co robisz. Po prostu pracuj tak, jak dotychczas, a wszystko będzie dobrze”.
- Kolejnym podejściem do uczestnictwa w open source jest partycypacja. Kiedy masz problem z oprogramowaniem open source i są programiści, twoi programiści zaczynają rozwiązywać problemy. Zaczynają zwiększać wydajność infrastruktury, a programy działać szybciej i bardziej niezawodnie.
Jednym z najbardziej znanych projektów Yandex w dziedzinie oprogramowania open source jest ClickHouse. Jest to baza danych, która narodziła się jako odpowiedź na wyzwania stojące przed Yandex.Metrica.
A jako baza danych została stworzona w open source, aby stworzyć ekosystem i rozwijać go wspólnie z innymi programistami (nie tylko w ramach Yandex). A teraz jest to duży projekt, w który zaangażowanych jest wiele różnych firm.
W Yandex.Cloud stworzyliśmy ClickHouse na bazie Yandex Object Storage, czyli na bazie chmury.
Dlaczego jest to ważne w chmurze? Bo w tym trójkącie, w tej piramidzie, w tej hierarchii typów pamięci działa każda baza danych. Masz szybkie, ale małe rejestry i tanie, duże, ale wolne dyski SSD, dyski twarde i inne urządzenia blokowe. A jeśli jesteś skuteczny na szczycie piramidy, to masz szybką bazę danych. jeśli jesteś skuteczny na dole tej piramidy, to masz skalowaną bazę danych. I pod tym względem dodanie kolejnej warstwy od dołu jest logicznym podejściem do zwiększenia skalowalności bazy danych.
Jak można to zrobić? To ważny punkt tego raportu.
- Moglibyśmy wdrożyć ClickHouse poprzez MDS. MDS to wewnętrzny interfejs przechowywania w chmurze Yandex. Jest bardziej złożony niż powszechny protokół S3, ale jest bardziej odpowiedni dla urządzenia blokowego. Lepiej jest rejestrować dane. Wymaga więcej programowania. Programiści będą programować, to nawet dobre, to ciekawe.
- S3 to bardziej powszechne podejście, które upraszcza interfejs kosztem mniejszego dostosowania do niektórych typów obciążeń.
Naturalnie, chcąc zapewnić funkcjonalność całemu ekosystemowi ClickHouse i wykonać zadanie, jakie jest potrzebne wewnątrz Yandex.Cloud, postanowiliśmy zadbać o to, aby cała społeczność ClickHouse na tym skorzystała. Wdrożyliśmy ClickHouse na S3, a nie ClickHouse na MDS. A to dużo pracy.
Linki:
„Warstwa abstrakcji systemu plików”
„Integracja AWS SDK S3”
„Bazowa implementacja interfejsu IDisk dla S3”
„Integracja silników przechowywania logów z interfejsem IDisk”
„Obsługa silnika dziennika dla S3 i SeekableReadBuffer”
„Obsługa Storage Stripe Log S3”
„Wstępna obsługa narzędzia Storage MergeTree dla S3”
„Pełne wsparcie MergeTree dla S3”
„Wsparcie ReplicatedMergeTree na S3”
„Dodaj domyślne poświadczenia i niestandardowe nagłówki dla pamięci masowej s3”
„S3 z dynamiczną konfiguracją proxy”
„S3 z funkcją rozpoznawania proxy”
To jest lista żądań ściągnięcia do wdrożenia wirtualnego systemu plików w ClickHouse. To duża liczba żądań ściągnięcia.
Linki:
„Optymalna implementacja łączy twardych DiskS3”
„Klient HTTP S3 — unikaj kopiowania strumienia odpowiedzi do pamięci”
„Unikaj kopiowania całego strumienia odpowiedzi do pamięci w S3 HTTP
klient"
„Możliwość buforowania plików znaczników i indeksów na dysku S3”
„Przenieś części z DiskLocal na DiskS3 równolegle”
Ale na tym praca się nie skończyła. Po stworzeniu tej funkcji konieczne było wykonanie dalszych prac w celu optymalizacji tej funkcjonalności.
Linki:
„Dodaj zdarzenia SelectedRows i SelectedBytes”
„Dodaj zdarzenia profilowania z żądania S3 do system.events”
„Dodaj QueryTimeMicrosekundy, SelectQueryTimeMicrosekundy i InsertQueryTimeMicrosekundy”
A potem trzeba było sprawić, żeby było to możliwe do zdiagnozowania, skonfigurowane monitorowanie i umożliwienie zarządzania.
A wszystko to po to, aby cała społeczność, cały ekosystem ClickHouse otrzymał efekt tej pracy.
Przejdźmy do baz transakcyjnych, do baz OLTP, które są mi osobiście bliższe.
To jest dział rozwoju open source DBMS. Ci goście robią magię uliczną, aby ulepszyć otwarte transakcyjne bazy danych.
Jednym z projektów, na przykładzie którego możemy porozmawiać o tym, jak i co robimy, jest Connection Pooler w Postgresie.
Postgres to baza danych procesów. Oznacza to, że baza danych powinna posiadać jak najmniej połączeń sieciowych obsługujących transakcje.
Z kolei w środowisku chmurowym typową sytuacją jest sytuacja, gdy do jednego klastra przychodzi jednocześnie tysiąc połączeń. Zadaniem puli połączeń jest spakowanie tysiąca połączeń w niewielką liczbę połączeń serwerowych.
Można powiedzieć, że pula połączeń to operator telefoniczny, który przestawia bajty tak, aby sprawnie dotarły do bazy danych.
Niestety nie ma dobrego rosyjskiego słowa na określenie puli połączeń. Czasami nazywa się to połączeniami multiplekserowymi. Jeśli wiesz, jak nazwać pulę połączeń, pamiętaj, aby mi powiedzieć, bardzo chętnie będę mówić poprawnym rosyjskim językiem technicznym.
Przeanalizowaliśmy pulę połączeń, która była odpowiednia dla zarządzanego klastra Postgres. A PgBouncer był dla nas najlepszym wyborem. Jednak napotkaliśmy wiele problemów z PgBouncerem. Wiele lat temu Wołodia Borodin dawała raporty, że używamy PgBouncera, wszystko nam się podoba, ale są niuanse, jest nad czym pracować.
I pracowaliśmy. Naprawiliśmy napotkane problemy, załataliśmy Bouncera i próbowaliśmy przesyłać żądania ściągnięcia w górę. Jednak praca z podstawową jednowątkowością była trudna.
Musieliśmy zbierać kaskady z załatanych bramkarzy. Kiedy mamy wiele jednowątkowych Bouncerów, połączenia z górnej warstwy są przenoszone do wewnętrznej warstwy Bouncerów. Jest to źle zarządzany system, który trudno jest zbudować i skalować w tę i z powrotem.
Doszliśmy do wniosku, że stworzyliśmy własny Pooler połączeń, który nazywa się Odyssey. Napisaliśmy to od zera.
W 2019 roku na konferencji PgCon przedstawiłem społeczności programistów tego Poolera. Teraz na GitHubie mamy nieco niecałe 2 gwiazdek, czyli projekt żyje, projekt cieszy się popularnością.
A jeśli utworzysz klaster Postgres w Yandex.Cloud, będzie to klaster z wbudowaną Odyssey, która jest rekonfigurowana podczas skalowania klastra w przód i w tył.
Czego nauczyliśmy się dzięki temu projektowi? Uruchomienie konkurencyjnego projektu jest zawsze krokiem agresywnym, jest to krok ekstremalny, gdy mówimy, że istnieją problemy, które nie są rozwiązywane wystarczająco szybko, nie są rozwiązywane w pasujących nam odstępach czasu. Ale to jest skuteczny środek.
PgBouncer zaczął się szybciej rozwijać.
A teraz pojawiły się kolejne projekty. Na przykład pgagroal, który jest rozwijany przez programistów Red Hat. Realizują podobne cele i realizują podobne pomysły, ale oczywiście z własną specyfiką, która jest bliższa deweloperom pgagroal.
Kolejnym przypadkiem współpracy ze społecznością Postgres jest przywracanie do punktu w czasie. To odzyskiwanie po awarii, to odzyskiwanie z kopii zapasowej.
Istnieje wiele kopii zapasowych i wszystkie są różne. Prawie każdy dostawca Postgres ma własne rozwiązanie do tworzenia kopii zapasowych.
Jeśli weźmiemy wszystkie systemy zapasowe, stworzymy macierz cech i żartobliwie obliczymy wyznacznik w tej macierzy, będzie to zero. Co to znaczy? Co się stanie, jeśli weźmiesz konkretny plik kopii zapasowej, nie będzie można go złożyć z kawałków wszystkich pozostałych. Jest wyjątkowy w swojej realizacji, jest wyjątkowy w swoim celu, jest wyjątkowy w ideach, które są w nim osadzone. I wszystkie są konkretne.
Podczas gdy my pracowaliśmy nad tym problemem, CitusData uruchomiła projekt WAL-G. Jest to system kopii zapasowych, który został wykonany z myślą o środowisku chmurowym. Teraz CitusData jest już częścią Microsoft. I w tym momencie naprawdę podobały nam się pomysły zawarte w pierwszych wydaniach WAL-G. Zaczęliśmy brać udział w tym projekcie.
Obecnie w tym projekcie uczestniczy kilkudziesięciu programistów, ale wśród 10 największych autorów WAL-G znajduje się 6 Yandexoidów. Przywieźliśmy tam wiele naszych pomysłów. I oczywiście sami je wdrożyliśmy, sami przetestowaliśmy, sami wdrożyliśmy do produkcji, sami z nich korzystamy, sami zastanawiamy się, gdzie dalej pójść, wchodząc w interakcję z dużą społecznością WAL-G.
I z naszego punktu widzenia, teraz ten system tworzenia kopii zapasowych, biorąc pod uwagę nasze wysiłki, stał się optymalny dla środowiska chmurowego. To najlepszy koszt tworzenia kopii zapasowych Postgres w chmurze.
Co to znaczy? Promowaliśmy dość dużą ideę: kopia zapasowa powinna być bezpieczna, tania w obsłudze i możliwie najszybsza do przywrócenia.
Dlaczego ma być tani w eksploatacji? Jeśli nic nie jest zepsute, nie powinieneś wiedzieć, że masz kopie zapasowe. Wszystko działa dobrze, marnujesz jak najmniej procesora, zużywasz jak najmniej zasobów dysku i wysyłasz do sieci jak najmniej bajtów, aby nie zakłócać ładunku cennych usług.
A kiedy wszystko się zepsuje, np. administrator upuścił dane, coś poszło nie tak i pilnie potrzebujesz wrócić do przeszłości, odzyskasz wszystkie pieniądze, bo chcesz, aby Twoje dane zostały szybko i nienaruszone.
I my promowaliśmy ten prosty pomysł. I wydaje nam się, że udało nam się to zrealizować.
Ale to nie wszystko. Chcieliśmy jeszcze jedną małą rzecz. Chcieliśmy mieć wiele różnych baz danych. Nie wszyscy nasi klienci korzystają z Postgres. Niektórzy używają MySQL, MongoDB. W społeczności inni programiści wspierali FoundationDB. A lista ta stale się powiększa.
Społeczności podoba się pomysł uruchomienia bazy danych w zarządzanym środowisku w chmurze. Programiści utrzymują swoje bazy danych, których kopie zapasowe można jednolicie tworzyć wraz z Postgres za pomocą naszego systemu kopii zapasowych.
Czego nauczyliśmy się z tej historii? Nasz produkt, jako dział rozwoju, to nie linie kodu, to nie są instrukcje, to nie są pliki. Nasz produkt nie obsługuje żądań ściągania. To są idee, które przekazujemy społeczeństwu. Jest to wiedza technologiczna i ruch technologii w kierunku środowiska chmurowego.
Istnieje taka baza danych jak Postgres. Najbardziej podoba mi się rdzeń Postgres. Spędzam dużo czasu na rozwijaniu rdzenia Postgres wraz ze społecznością.
Ale tutaj trzeba powiedzieć, że Yandex.Cloud ma wewnętrzną instalację zarządzanych baz danych. A zaczęło się to dawno temu w Yandex.Mail. Wiedza specjalistyczna, która obecnie doprowadziła do zarządzania Postgres, została zgromadzona, gdy poczta chciała przenieść się do Postgres.
Mail ma bardzo podobne wymagania co chmura. Wymaga to możliwości skalowania do nieoczekiwanego wykładniczego wzrostu w dowolnym momencie danych. A poczta była już obciążona setkami milionów skrzynek pocztowych ogromnej liczby użytkowników, którzy stale wysyłają wiele żądań.
A to było dość poważne wyzwanie dla zespołu tworzącego Postgres. Już wtedy wszelkie napotkane problemy były zgłaszane społeczności. I te problemy zostały naprawione, i to w niektórych miejscach przez społeczność, nawet na poziomie płatnego wsparcia dla niektórych innych baz danych, a nawet lepiej. Oznacza to, że możesz wysłać list do hakera PgSQL i otrzymać odpowiedź w ciągu 40 minut. Płatne wsparcie w niektórych bazach danych może uznać, że są rzeczy ważniejsze niż Twój błąd.
Teraz wewnętrzna instalacja Postgres to kilka petabajtów danych. To kilka milionów żądań na sekundę. Są to tysiące klastrów. Ma bardzo dużą skalę.
Ale jest niuans. Nie żyje na wymyślnych dyskach sieciowych, ale na dość prostym sprzęcie. Istnieje również środowisko testowe specjalnie dla nowych, interesujących rzeczy.
I w pewnym momencie w środowisku testowym otrzymaliśmy komunikat wskazujący, że zostały naruszone wewnętrzne niezmienniki indeksów bazy danych.
Niezmiennik to pewien rodzaj relacji, która, jak się spodziewamy, będzie zawsze utrzymywana.
Dla nas bardzo krytyczna sytuacja. Oznacza to, że niektóre dane mogły zostać utracone. A utrata danych jest czymś wręcz katastrofalnym.
Ogólna koncepcja, którą kierujemy się w przypadku zarządzanych baz danych, jest taka, że nawet przy dużym wysiłku trudno będzie utracić dane. Nawet jeśli celowo je usuniesz, nadal będziesz musiał ignorować ich brak przez długi czas. Bezpieczeństwo danych to religia, której przestrzegamy dość pilnie.
I tu pojawia się sytuacja, która sugeruje, że może zaistnieć sytuacja, na którą możemy nie być przygotowani. I zaczęliśmy przygotowywać się na tę sytuację.
Pierwszą rzeczą, którą zrobiliśmy, było zakopanie kłód z tych tysięcy kęp. Ustaliliśmy, które z klastrów znajdowały się na dyskach z problematycznym oprogramowaniem sprzętowym, które traciły aktualizacje stron danych. Oznaczono cały kod danych Postgres. Te wiadomości, które wskazują na naruszenia wewnętrznych niezmienników, oznaczyliśmy kodem mającym na celu wykrywanie uszkodzeń danych.
Łatka ta została praktycznie zaakceptowana przez społeczność bez większych dyskusji, bo w każdym konkretnym przypadku było oczywiste, że stało się coś złego i trzeba było to zgłosić do logu.
Potem doszliśmy do punktu, w którym mamy monitoring skanujący logi. A w przypadku podejrzanych wiadomości budzi oficera dyżurnego, który naprawia go.
Ale! Skanowanie dzienników jest tanią operacją w jednym klastrze i katastrofalnie kosztowną w przypadku tysiąca klastrów.
Napisaliśmy rozszerzenie o nazwie . Tworzy widok bazy danych, w której można tanio i szybko wybrać statystyki dotyczące błędów z przeszłości. A jeśli będziemy musieli obudzić oficera dyżurnego, to dowiemy się o tym bez skanowania plików gigabajtowych, ale wyodrębniając kilka bajtów z tablicy mieszającej.
Rozszerzenie to zostało przyjęte np. w repozytorium dla . Jeśli chcesz z niego skorzystać, możesz go zainstalować samodzielnie. Oczywiście, że jest to oprogramowanie typu open source.
Ale to nie wszystko. Zaczęliśmy używać Amcheck, rozszerzenia stworzonego przez społeczność, aby znaleźć niezmienne naruszenia w indeksach.
Odkryliśmy, że jeśli działa się na dużą skalę, pojawiają się błędy. Zaczęliśmy je naprawiać. Nasze poprawki zostały przyjęte.
Odkryliśmy, że to rozszerzenie nie może analizować indeksów GiST i GIT. Zmusiliśmy ich do wsparcia. Ale to wsparcie jest wciąż dyskutowane przez społeczność, ponieważ jest to stosunkowo nowa funkcjonalność i jest tam wiele szczegółów.
Odkryliśmy również, że podczas sprawdzania indeksów pod kątem naruszeń na liderze replikacji, na masterze, wszystko działa dobrze, ale na replikach, na naśladowcy, wyszukiwanie korupcji nie jest tak skuteczne. Nie wszystkie niezmienniki są sprawdzane. I jeden niezmiennik bardzo nam przeszkadzał. Spędziliśmy półtora roku komunikując się ze społecznością, aby umożliwić kontrolę replik.
Napisaliśmy kod, który powinien być zgodny ze wszystkimi protokołami can. Długo omawialiśmy tę poprawkę z Peterem Gaghanem z Crunchy Data. Aby zaakceptować tę łatkę, musiał nieznacznie zmodyfikować istniejące drzewo B w Postgres. Został przyjęty. A teraz sprawdzanie indeksów na replikach również stało się na tyle skuteczne, że pozwala wykryć naruszenia, które napotkaliśmy. Oznacza to, że są to naruszenia, które mogą być spowodowane błędami oprogramowania sprzętowego dysku, błędami w Postgres, błędami w jądrze Linuksa i problemami sprzętowymi. Dość obszerna lista źródeł problemów, na które się przygotowywaliśmy.
Ale oprócz indeksów istnieje jeszcze taka część, jak sterta, czyli miejsce, w którym przechowywane są dane. I nie ma wielu niezmienników, które można sprawdzić.
Mamy rozszerzenie o nazwie Heapcheck. Zaczęliśmy go rozwijać. Równolegle razem z nami firma EnterpriseDB również zaczęła pisać moduł, który w ten sam sposób nazwali Heapcheck. Tylko my nazwaliśmy to PgHeapcheck, a oni po prostu nazwali to Heapcheck. Mają go z podobnymi funkcjami, nieco inną sygnaturą, ale z tymi samymi pomysłami. W niektórych miejscach zaimplementowali je nieco lepiej. I opublikowali to już wcześniej w wersji open source.
A teraz rozwijamy ich ekspansję, bo to już nie jest ich ekspansja, ale ekspansja społeczności. W przyszłości jest to część jądra, która będzie dostarczana wszystkim, aby mogli z wyprzedzeniem wiedzieć o przyszłych problemach.
W niektórych miejscach doszliśmy nawet do wniosku, że w naszych systemach monitorowania występują fałszywe alarmy. Na przykład system 1C. Podczas korzystania z bazy danych Postgres czasami zapisuje w niej dane, które może odczytać, ale pg_dump nie może odczytać.
Ta sytuacja wyglądała na uszkodzenie naszego systemu wykrywania problemów. Oficer dyżurny obudził się. Oficer dyżurny przyglądał się temu, co się dzieje. Po pewnym czasie przyszedł klient i powiedział, że mam problemy. Osoba obsługująca wyjaśniła na czym polega problem. Ale problem tkwi w rdzeniu Postgres.
Znalazłem dyskusję na temat tej funkcji. I napisał, że napotkaliśmy tę funkcję i było to nieprzyjemne, osoba budziła się w nocy, aby dowiedzieć się, co to jest.
Społeczność odpowiedziała: „Och, naprawdę musimy to naprawić”.
Mam prostą analogię. Jeśli chodzisz w bucie, w którym jest ziarnko piasku, to w zasadzie możesz iść dalej – nie ma problemu. Jeśli sprzedajesz buty tysiącom ludzi, zróbmy buty w ogóle bez piasku. A jeśli jeden z użytkowników Twoich butów ma zamiar przebiec maraton, to chcesz zrobić bardzo dobre buty, a następnie skalować je dla wszystkich swoich użytkowników. A tacy nieoczekiwani użytkownicy zawsze znajdują się w środowisku chmurowym. Zawsze znajdą się użytkownicy, którzy wykorzystują klaster w jakiś oryginalny sposób. Zawsze musisz się na to przygotować.
Czego się tutaj nauczyliśmy? Nauczyliśmy się prostej rzeczy: najważniejsze jest wyjaśnienie społeczności, że jest problem. Jeśli społeczność dostrzegła problem, pojawia się naturalna konkurencja w celu rozwiązania problemu. Bo każdy chce rozwiązać ważny problem. Wszyscy dostawcy, wszyscy hakerzy rozumieją, że sami mogą nadepnąć na te grabieże, więc chcą ich wyeliminować.
Jeśli pracujesz nad problemem, ale nie przeszkadza to nikomu poza Tobą, ale pracujesz nad nim systematycznie i ostatecznie zostanie to uznane za problem, to Twoja pull request na pewno zostanie zaakceptowana. Twoja łatka zostanie zaakceptowana, a Twoje ulepszenia, a nawet prośby o ulepszenia, zostaną sprawdzone przez społeczność. Ostatecznie ulepszamy bazę danych dla siebie nawzajem.
Ciekawą bazą danych jest Greenplum. Jest to wysoce równoległa baza danych oparta na kodzie Postgres, który bardzo dobrze znam.
A Greenplum ma ciekawą funkcjonalność - dodawaj zoptymalizowane tabele. Są to tabele, do których możesz szybko dodać. Mogą być kolumnowe lub rzędowe.
Nie było jednak klastrowania, czyli nie było funkcjonalności pozwalającej na uporządkowanie danych znajdujących się w tabeli zgodnie z kolejnością, jaka jest w jednym z indeksów.
Chłopaki z taksówki podeszli do mnie i powiedzieli: „Andrey, znasz Postgres. A tutaj jest prawie tak samo. Przełącz na 20 minut. Bierzesz to i robisz.” Pomyślałem, że tak, znam Postgres, przełączam na 20 minut - muszę to zrobić.
Ale nie, to nie było 20 minut, pisałem to miesiącami. Na konferencji PgConf.Russia zwróciłem się do Heikkiego Linakangasa z Pivotal i zapytałem: „Czy są z tym jakieś problemy? Dlaczego nie ma grupowania tabel zoptymalizowanego pod kątem dołączania?” Mówi: „Ty bierzesz dane. Sortujesz, przestawiasz. To tylko praca.” Ja: „Och, tak, po prostu musisz to wziąć i zrobić”. Mówi: „Tak, potrzebujemy do tego wolnych rąk”. Pomyślałem, że zdecydowanie muszę to zrobić.
Kilka miesięcy później przesłałem żądanie ściągnięcia, które zaimplementowało tę funkcjonalność. To żądanie ściągnięcia zostało sprawdzone przez firmę Pivotal wraz ze społecznością. Oczywiście, były błędy.
Ale najciekawsze jest to, że kiedy to żądanie ściągnięcia zostało połączone, w samym Greenplum znaleziono błędy. Odkryliśmy, że tabele sterty czasami psują transakcyjność, gdy są klastrowane. I to jest rzecz, którą trzeba naprawić. A ona jest w miejscu, które przed chwilą dotknąłem. Moją naturalną reakcją było – OK, pozwól, że ja też to zrobię.
Naprawiłem ten błąd. Wysłałem prośbę o ściągnięcie do fixerów. Został zabity.
Po czym okazało się, że tę funkcjonalność trzeba pozyskać w wersji Greenplum dla PostgreSQL 12. Czyli 20-minutowa przygoda ma ciąg dalszy z nowymi ciekawymi przygodami. Ciekawie było dotknąć obecnego rozwoju, w którym społeczność tworzy nowe i najważniejsze funkcje. Jest zamrożone.
Ale to nie był koniec. Po wszystkim okazało się, że trzeba na to wszystko napisać dokumentację.
Zacząłem pisać dokumentację. Na szczęście pojawili się dokumentaliści z Pivotal. Angielski jest ich językiem ojczystym. Pomogli mi z dokumentacją. W rzeczywistości sami przepisali to, co zaproponowałem, na prawdziwy angielski.
I tutaj, wydawałoby się, przygoda się skończyła. I wiesz, co się wtedy stało? Chłopaki z taksówki podeszli do mnie i powiedzieli: „Są jeszcze dwie przygody, każda po 10 minut”. I co mam im powiedzieć? Powiedziałem, że teraz zdam relację w skali, a potem zobaczymy Twoje przygody, bo to ciekawa praca.
Czego nauczyliśmy się z tej sprawy? Ponieważ praca z oprogramowaniem open source zawsze polega na pracy z konkretną osobą, zawsze jest to praca ze społecznością. Ponieważ na każdym etapie współpracowałem z jakimś programistą, jakimś testerem, jakimś hackerem, jakimś dokumentalistą, jakimś architektem. Nie pracowałem z Greenplum, pracowałem z ludźmi z Greenplum.
Ale! Jest jeszcze jeden ważny punkt - to po prostu praca. Czyli przychodzisz, pijesz kawę, piszesz kod. Działają wszelkiego rodzaju proste niezmienniki. Zrób to normalnie - będzie dobrze! A to całkiem ciekawa praca. Istnieje prośba o tę pracę od klientów Yandex.Cloud, użytkowników naszych klastrów zarówno w Yandex, jak i poza nim. I myślę, że zwiększy się liczba projektów, w których będziemy uczestniczyć, i głębokość naszego zaangażowania.
To wszystko. Przejdźmy do pytań.
Sesja pytań
Cześć! Przed nami kolejna sesja pytań i odpowiedzi. A w studiu Andriej Borodin. To osoba, która właśnie opowiedziała Ci o wkładzie Yandex.Cloud i Yandex w open source. Nasz raport nie dotyczy teraz wyłącznie Chmury, ale jednocześnie bazujemy na takich technologiach. Bez tego, co zrobiliście w Yandex, nie byłoby usługi w Yandex.Cloud, więc dziękuję wam osobiście. I pierwsze pytanie z audycji: „Co jest napisane w każdym z projektów, o których wspomniałeś?”
System tworzenia kopii zapasowych w WAL-G jest napisany w Go. To jeden z nowszych projektów nad którymi pracowaliśmy. Ma dosłownie zaledwie 3 lata. A baza danych często wiąże się z niezawodnością. A to oznacza, że bazy danych są dość stare i zazwyczaj są pisane w języku C. Projekt Postgres rozpoczął się około 30 lat temu. Zatem C89 był właściwym wyborem. I jest na nim napisany Postgres. Bardziej nowoczesne bazy danych, takie jak ClickHouse, są zwykle pisane w języku C++. Cały rozwój systemu opiera się na językach C i C++.
Pytanie od naszego menadżera finansowego, który odpowiada za wydatki w Cloud: „Dlaczego Cloud wydaje pieniądze na wspieranie open source?”
Tutaj jest prosta odpowiedź dla menedżera finansowego. Robimy to, aby ulepszyć nasze usługi. Pod jakim względem możemy działać lepiej? Możemy robić rzeczy wydajniej, szybciej i sprawić, że będą one bardziej skalowalne. Ale dla nas ta historia dotyczy przede wszystkim niezawodności. Na przykład w systemie zapasowym sprawdzamy 100% poprawek, które go dotyczą. Wiemy, jaki jest kod. I czujemy się bardziej komfortowo wdrażając nowe wersje do produkcji. Czyli przede wszystkim chodzi o pewność siebie, o gotowość do rozwoju i o niezawodność
Kolejne pytanie: „Czy wymagania użytkowników zewnętrznych, którzy mieszkają w Yandex.Cloud, różnią się od wymagań użytkowników wewnętrznych, którzy mieszkają w wewnętrznej chmurze?”
Profil obciążenia jest oczywiście inny. Jednak z punktu widzenia mojego działu wszystkie przypadki szczególne i ciekawe powstają na niestandardowym obciążeniu. Programistów z wyobraźnią, programistów, którzy robią nieoczekiwane rzeczy, można znaleźć zarówno wewnętrznie, jak i zewnętrznie. Pod tym względem wszyscy jesteśmy w przybliżeniu tacy sami. I prawdopodobnie jedyną ważną cechą działania baz danych Yandex będzie to, że wewnątrz Yandex mamy naukę. W pewnym momencie część strefy dostępności całkowicie przechodzi w cień, a wszystkie usługi Yandex muszą mimo to jakoś nadal funkcjonować. To niewielka różnica. Ale stwarza to wiele rozwoju badań na styku bazy danych i stosu sieciowego. W przeciwnym razie instalacje zewnętrzne i wewnętrzne generują te same żądania dotyczące funkcji i podobne żądania poprawy niezawodności i wydajności.
Następne pytanie: „Jak osobiście czujesz się z faktem, że duża część tego, co robisz, jest wykorzystywana przez inne Chmury?” Nie będziemy wymieniać konkretnych, ale wiele projektów, które powstały w Yandex.Cloud, jest używanych w chmurach innych osób.
To jest fajne. Po pierwsze, jest to znak, że zrobiliśmy coś dobrze. I to drapie ego. I mamy większą pewność, że podjęliśmy właściwą decyzję. Z drugiej strony jest to nadzieja, że w przyszłości przyniesie nam to nowe pomysły, nowe prośby od zewnętrznych użytkowników. Większość problemów na GitHubie tworzą indywidualni administratorzy systemów, indywidualni administratorzy baz danych, indywidualni architekci, indywidualni inżynierowie, ale czasami przychodzą osoby z systematycznym doświadczeniem i mówią, że w 30% niektórych przypadków mamy ten problem i zastanówmy się, jak go rozwiązać. Na to właśnie czekamy najbardziej. Z niecierpliwością czekamy na wymianę doświadczeń z innymi platformami chmurowymi.
Dużo mówiłeś o maratonie. Wiem, że przebiegłeś maraton w Moskwie. W rezultacie? Wyprzedziłeś chłopaków z PostgreSQL?
Nie, Oleg Bartunov biega bardzo szybko. Skończył godzinę przede mną. Ogólnie rzecz biorąc, jestem zadowolony z tego, jak daleko zaszedłem. Dla mnie samo ukończenie było osiągnięciem. Ogólnie rzecz biorąc, zaskakujące jest, że w społeczności Postgres jest tak wielu biegaczy. Wydaje mi się, że istnieje jakiś związek pomiędzy sportami aerobowymi a chęcią programowania systemów.
Chcesz powiedzieć, że w ClickHouse nie ma biegaczy?
Wiem na pewno, że tam są. ClickHouse to także baza danych. Swoją drogą, Oleg teraz do mnie pisze: „Może po raporcie pójdziemy pobiegać?” To świetny pomysł.
Kolejne pytanie z transmisji od Nikity: „Dlaczego sam naprawiłeś błąd w Greenplum i nie dałeś go juniorom?” To prawda, nie jest zbyt jasne, na czym polega błąd i w jakiej usłudze, ale prawdopodobnie chodzi o tę, o której mówiłeś.
Tak, w zasadzie można było go komuś podarować. To był tylko kod, który właśnie zmieniłem. Naturalne było, że od razu będziemy to kontynuować. W zasadzie pomysł podzielenia się wiedzą z zespołem jest dobrym pomysłem. Na pewno podzielimy się zadaniami Greenplum pomiędzy wszystkich członków naszego oddziału.
Skoro mówimy o juniorach, tu jest pytanie. Osoba zdecydowała się utworzyć pierwsze zatwierdzenie w Postgresie. Co musi zrobić, aby dokonać pierwszego zatwierdzenia?
To interesujące pytanie: „Od czego zacząć?” Zwykle dość trudno jest zacząć od czegoś w jądrze. Na przykład w Postgres istnieje lista rzeczy do zrobienia. Ale tak naprawdę jest to arkusz tego, co próbowali zrobić, ale nie udało im się. To są złożone rzeczy. Zwykle w ekosystemie można znaleźć pewne narzędzia, pewne rozszerzenia, które można ulepszyć i które przyciągają mniej uwagi programistów jądra. W związku z tym jest tam więcej punktów wzrostu. Co roku podczas programu Google Summer of Code społeczność Postgres przedstawia wiele różnych tematów, którymi można się zająć. W tym roku mieliśmy chyba trzech uczniów. Jeden nawet napisał w WAL-G na tematy ważne dla Yandex. W Greenplum wszystko jest prostsze niż w społeczności Postgres, ponieważ hakerzy Greenplum bardzo dobrze traktują pull requesty i od razu rozpoczynają przeglądanie. Wysłanie łatki do Postgres to kwestia miesięcy, ale Greenplum przyjdzie w ciągu jednego dnia i zobaczy, co zrobiłeś. Inną rzeczą jest to, że Greenplum musi rozwiązać bieżące problemy. Greenplum nie jest szeroko stosowany, więc znalezienie problemu jest dość trudne. A przede wszystkim oczywiście musimy rozwiązać problemy.
Źródło: www.habr.com