Jak backend developer rozumie, że zapytanie SQL będzie dobrze działać na „produkcji”? W dużych lub szybko rozwijających się firmach dostęp do „produkcji” nie jest dostępny dla wszystkich. A nawet z dostępem nie wszystkie zapytania można bezboleśnie sprawdzić, a stworzenie kopii bazy danych często zajmuje godziny. Aby rozwiązać te problemy, stworzyliśmy sztucznego DBA - Joe. Leży u podstaw jego wdrożenia w kilku firmach i pomaga niejednemu dziesiątkowi programistów.
Wideo:
Cześć wszystkim! Nazywam się Anatolij Stanser. Pracuję w firmie . Zajmujemy się tym, że przyspieszamy proces rozwoju, eliminując opóźnienia związane z pracą Postgresa u programistów, DBA i QA.
Mamy świetnych klientów i dzisiaj część prezentacji będzie poświęcona przypadkom, które napotkaliśmy w pracy z nimi. Opowiem, jak pomogliśmy im rozwiązać dość poważne problemy.
Kiedy prowadzimy rozwój i robimy złożone, obciążone migracje, zadajemy sobie pytanie: „Czy ta migracja się powiedzie?”. Korzystamy z recenzji, korzystamy z wiedzy bardziej doświadczonych kolegów, DBA-ekspertów. I mogą oni powiedzieć – czy się powiedzie, czy nie.
Ale być może lepiej byłoby, gdybyśmy mogli sami przetestować to na pełnowymiarowych kopiach. Dzisiaj porozmawiamy o tym, jakie obecnie istnieją podejścia do testowania i jak można to lepiej robić oraz z jakich narzędzi korzystać. Poruszymy także plusy i minusy takich podejść oraz co możemy tu poprawić.
Kto kiedykolwiek robił indeksy lub wprowadzał jakieś zmiany bezpośrednio na produkcji? Całkiem sporo. A komu to prowadziło do utraty danych lub przestojów? Wtedy znasz ten ból. Na szczęście są kopie zapasowe.
Pierwsze podejście – testowanie na produkcji. Lub kiedy programista siedzi na lokalnej maszynie, ma testowe dane, jest jakaś ograniczona próbka. Wdrażamy to na produkcję i otrzymujemy taką sytuację.
To boli, to jest drogie. Pewnie lepiej tego nie robić.
A jak można to lepiej zrobić?
Weźmy staging i wydzielmy tam jakąś część produkcji. Lub, w najlepszym przypadku, weźmy prawdziwe dane produkcyjne. A po tym, jak w lokalnym środowisku opracowaliśmy, będziemy dodatkowo sprawdzać również na stagingu.
To pozwoli nam wyeliminować część błędów, tzn. nie dopuścić ich do produkcji.
Jakie są problemy?
- Problem w tym, że ten staging dzielimy z kolegami. I bardzo często zdarza się, że robisz jakąś zmianę, bum - i nie ma żadnych danych, praca na marne. Staging był wieloteraabajtny. I trzeba długo czekać, aż znów się podniesie. I decydujemy się poprawić to jutro. Wszystko, mamy zatrzymanie w rozwoju.
- I oczywiście, pracuje tam wielu kolegów, wiele zespołów. I trzeba to ręcznie uzgadniać. A to jest niewygodne.
I trzeba powiedzieć, że mamy tylko jedną próbę, jeden strzał, jeśli chcemy wprowadzić jakieś zmiany w bazie danych, dotknąć danych, zmienić strukturę. I jeśli coś poszło nie tak, jeśli w migracji była pomyłka, to szybko już nie wrócimy.
To lepsze niż poprzednie podejście, ale wciąż istnieje duże prawdopodobieństwo, że jakiś błąd trafi na produkcję.
Co nas powstrzymuje przed daniem każdemu programiście testowego środowiska, pełnowymiarowej kopii? Myślę, że jasne, co to powstrzymuje.
Kto ma bazę danych większą niż terabajt? Więcej niż połowa sali.
I jasne, że utrzymanie maszyn dla każdego programisty, przy tak dużej produkcji, jest bardzo drogie, a do tego jeszcze trwałe.
Mamy klientów, którzy zrozumieli, że bardzo ważne jest testowanie wszystkich zmian na pełnowymiarowych kopiach, ale mają bazę poniżej terabajta, a zasobów, aby dla każdego programisty utrzymać testowe środowisko, nie mają. Dlatego muszą pobierać zrzuty lokalnie na swoje maszyny i testować w ten sposób. To zajmuje mnóstwo czasu.
Nawet jeśli robicie to wewnątrz infrastruktury, pobranie jednego terabajta danych na godzinę - to już bardzo dobrze. Ale oni używają logicznych zrzutów, ściągają lokalnie z chmury. Dla nich prędkość wynosi około 200 gigabajtów na godzinę. A jeszcze potrzeba czasu, aby z logicznego zrzutu się rozwinąć, załadować indeksy itd.
Ale oni używają tego podejścia, ponieważ pozwala to utrzymać produkcję niezawodną.
Co możemy tutaj zrobić? Zróbmy tak, aby testowe środowiska były tanie i dawajmy każdemu programiście własne testowe środowisko.
I to jest możliwe.
W tym podejściu, gdy tworzymy cienkie kopie dla każdego dewelopera, możemy je współdzielić na jednej maszynie. Na przykład, jeśli masz bazę danych o pojemności czterech terabajtów i chcesz udostępnić ją 10 deweloperom, nie musisz mieć 10 maszyn czteroteraowych. Wystarczy jedna maszyna, na której będziesz tworzyć cienkie, izolowane kopie dla każdego dewelopera. Jak to działa, wyjaśnię później.
Prawdziwy przykład:
Baza danych – 4,5 terabajta.
Możemy uzyskać niezależne kopie w 30 sekund.
Nie musisz czekać na środowisko testowe i polegać na jego rozmiarze. Możesz je uzyskać w kilka sekund. Otrzymasz całkowicie izolowane środowiska, które jednak będą dzielić dane między sobą.
To jest niesamowite. Tutaj mówimy o magii i równoległym wszechświecie.
W naszym przypadku działa to za pomocą systemu OpenZFS.
OpenZFS to system plików typu copy-on-write, który od razu wspiera migawek i klonów. Jest niezawodny i skalowalny. W jego zarządzanie jest bardzo proste. Można go uruchomić dosłownie w dwóch komendach.
Są inne opcje:
LVM,
macierze dyskowe (na przykład Pure Storage).
Database Lab, o którym opowiadam, jest modułowy. Można go wdrożyć przy użyciu takich opcji. Ale na razie skupiliśmy się na OpenZFS, ponieważ mieliśmy problemy z LVM.
Jak to działa? Zamiast zapisywać dane za każdym razem, gdy je zmieniamy, zachowujemy je, po prostu oznaczając, że te nowe dane odnoszą się do nowego momentu czasowego, do nowej migawki.
A kiedy później chcemy cofnąć się lub stworzyć nowy klon z jakiejś starszej wersji, po prostu mówimy: „Ok, dajcie nam te bloki danych, które są tak oznaczone”.
Ten użytkownik będzie pracował z takim zestawem danych. Będzie je stopniowo zmieniać, tworzyć własne migawki.
I będziemy mieć rozgałęzienie. Każdy deweloper w naszym przypadku będzie miał możliwość posiadania swojego własnego klonu, który edytuje, a te wspólne dane będą dzielone między wszystkimi.
Aby uruchomić taki system, trzeba rozwiązać dwie problemy:
Pierwszym elementem jest źródło danych, z którego będziesz je pobierać. Możesz skonfigurować replikację z produkcji. Można również wykorzystać już skonfigurowane kopie zapasowe, mam nadzieję. WAL-E, WAL-G czy Barman. A nawet, jeśli korzystasz z rozwiązania w chmurze, na przykład RDS lub Cloud SQL, możesz użyć logicznych zrzutów. Niemniej jednak, zalecamy korzystanie z kopii zapasowych, ponieważ dzięki temu zachowasz fizyczną strukturę plików, co pozwoli ci być jeszcze bliżej metryk, które widziałbyś w produkcji, aby wyłapywać istniejące problemy.
Drugim elementem jest miejsce, w którym chcesz hostować Database Lab. Może to być chmura lub lokalny serwer. Ważne jest, aby wspomnieć, że ZFS wspiera kompresję danych. I robi to całkiem dobrze.
Wyobraź sobie, że dla każdego takiego klona, w zależności od operacji, które wykonujemy na bazie, będzie narastać jakiś dev. Do tego również będzie potrzebne miejsce. Jednak ze względu na to, że mamy bazę o pojemności 4,5 terabajta, ZFS skompresuje ją do 3,5 terabajta. W zależności od ustawień można to modyfikować. I wciąż pozostanie miejsce na dev.
Taki system można wykorzystać do różnych zastosowań.
To są deweloperzy, DBA do testowania zapytań, do optymalizacji.
Można to wykorzystać w testach QA do sprawdzenia konkretnej migracji przed wypuszczeniem na produkcję. Możemy również uruchamiać specjalne środowiska QA z rzeczywistymi danymi, gdzie mogą przetestować nową funkcjonalność. I zajmie to sekundy, zamiast czekać godziny, a być może i dni w innych przypadkach, gdzie nie są używane cienkie kopie.
I jeszcze jeden przypadek. Jeśli w firmie nie jest skonfigurowany system analityczny, możemy wydzielić cienką kopię bazy produktowej i wykorzystać ją do długich zapytań lub pod specjalne indeksy, które mogą być używane w analizie.
Z takim podejściem:
Niska prawdopodobieństwo błędów na «produkcji», ponieważ wszystkie zmiany testowaliśmy na pełnowymiarowych danych.
Pojawia się kultura testowania, ponieważ teraz nie trzeba czekać godzinami na własne środowisko.
Nie ma przeszkód, nie ma oczekiwania między testami. Możesz naprawdę pójść i sprawdzić. A to będzie lepsze, ponieważ przyspieszymy rozwój.
Będzie mniej refaktoryzacji. Mniej błędów trafi do produkcji. Refaktoryzujemy ich mniej później.
Możemy odwracać nieodwracalne zmiany. Tego nie ma w standardowych podejściach.
- To opłacalne, ponieważ dzielimy zasoby środowisk testowych.
Już jest dobrze, a co jeszcze moglibyśmy przyspieszyć?
Dzięki takiemu systemowi możemy znacznie obniżyć próg wejścia do tego rodzaju testowania.
Obecnie mamy błędne koło, gdzie deweloper, aby uzyskać dostęp do prawdziwych, pełnowymiarowych danych, musi stać się ekspertem. Musi mu zostać powierzony taki dostęp.
Ale jak rosnąć, jeśli go nie ma? A co, jeśli masz dostęp tylko do bardzo małego zestawu danych testowych? Wtedy nie zdobędziesz realnego doświadczenia.
Jak wyjść z tego kręgu? Jako pierwsze, wygodne dla deweloperów na każdym poziomie, wybraliśmy bota Slack. Ale może to być dowolny inny interfejs.
Co on pozwala robić? Można wziąć konkretne zapytanie i wysłać je do specjalnego kanału dla bazy danych. Automatycznie w ciągu sekund uruchomimy cienkiego klona. Wykonamy to zapytanie. Zbieramy metryki i rekomendacje. Pokażemy wizualizację. A następnie ten klon pozostanie, aby to zapytanie można było w jakiś sposób zoptymalizować, dodać indeksy itd.
Slack daje nam również możliwości współpracy z pudełka. Ponieważ to po prostu kanał, można tam rozpocząć dyskusję na temat tego zapytania, pingować swoich kolegów, DBA, którzy są w firmie.
Jednak są też problemy. Ponieważ to prawdziwy świat i używamy serwera, na którym hostujemy od razu wiele klonów, musimy ograniczyć ilość pamięci i procesora, które są dostępne dla klonów.
Aby te testy były wiarygodne, musimy jakoś rozwiązać ten problem.
Oczywiście ważnym punktem są jednorodne dane. Ale to już mamy. Chcemy uzyskać jednorodną konfigurację. I praktycznie taką samą konfigurację możemy zaoferować.
Byłoby fajnie mieć taki sam sprzęt jak w produkcji, ale może się on różnić.
Przypomnijmy sobie, jak Postgres działa z pamięcią. Mamy dwa buforowe pamięci. Jeden od systemu plików i jeden własny Postgres, czyli Shared Buffer Cache.
Warto zauważyć, że Shared Buffer Cache jest alokowane podczas uruchamiania Postgresa w zależności od tego, jaki rozmiar ustawisz w konfiguracji.
A druga pamięć podręczna wykorzystywana jest w całej dostępnej przestrzeni.
Kiedy robimy kilka klonów na tej samej maszynie, stopniowo zapełniamy pamięć. Odpowiednio, Shared Buffer Cache powinno stanowić 25% całkowitej pamięci dostępnej na maszynie.
W rezultacie, jeśli nie zmienimy tego parametru, będziemy w stanie uruchomić na jednej maszynie tylko 4 instancje, tzn. tylko 4 takie cienkie klony. To oczywiście nie jest dobre, ponieważ chcielibyśmy mieć ich o wiele więcej.
Z drugiej strony, Buffer Cache jest używane do wykonywania zapytań, do indeksów, tzn. plan zależy od tego, jakiego rozmiaru mamy pamięci podręczne. Jeśli po prostu zmniejszymy ten parametr, to nasze plany mogą się drastycznie zmienić.
Na przykład, jeśli na prod mamy dużą pamięć podręczną, Postgres będzie preferował korzystanie z indeksu. A jeśli nie, to wtedy nastąpi SeqScan. I jaki byłby sens, jeśli nasze plany nie byłyby zgodne?
Dochodzi do tego, że w rzeczywistości plan w Postgresie nie zależy od konkretnego rozmiaru ustawionego w Shared Buffer, lecz od effective_cache_size.
Effective_cache_size to zakładana wielkość pamięci podręcznej, która jest nam dostępna, tzn. suma Buffer Cache i pamięci podręcznej systemu plików. Jest to określone w konfiguracji. I ta pamięć nie jest alokowana.
Dzięki temu parametrowi możemy w pewien sposób oszukać Postgresa, mówiąc, że tak naprawdę mamy dostęp do wielu danych, nawet jeśli tych danych nie posiadamy. W ten sposób plany będą całkowicie zgodne z produkcją.
Jednak to może wpłynąć na czas działania. Optimzujemy zapytania pod kątem czasu, ale ważne jest, że czas działąnia zależy od wielu czynników:
Zależy od obciążenia, które aktualnie występuje na prod.
Zależy od specyfikacji samej maszyny.
Jest to wskaźnik pośredni, ale naprawdę możemy optymalizować na podstawie ilości danych, które to zapytanie odczyta, aby uzyskać wynik.
Jeśli chcesz, aby czas reakcji był zbliżony do tego, co zobaczymy w prod, musimy wziąć jak najbardziej podobny sprzęt, a być może nawet więcej, aby zmieścić wszystkie klony. Ale to jest kompromis, tj. otrzymasz te same plany, zobaczysz, ile danych przeczytało konkretne zapytanie i będziesz mógł ocenić – to zapytanie jest dobre (lub migracja) czy złe, musi być jeszcze zoptymalizowane.
Zobaczmy, jak dokładnie odbywa się optymalizacja z Joe.
Weźmiemy zapytanie z rzeczywistego systemu. W tym przypadku baza danych ma 1 terabajt. I chcemy obliczyć liczbę świeżych postów, które miały więcej niż 10 polubień.
Wysyłamy wiadomość na kanał, uruchomił się dla nas klon. I zobaczymy, że takie zapytanie będzie działać przez 2,5 minuty. To pierwsza rzecz, którą zauważymy.
Joe pokaże automatyczne rekomendacje oparte na planie i metrykach.
Zobaczymy, że zapytanie przetwarza zbyt wiele danych, aby uzyskać względnie niewielką liczbę wierszy. I potrzebny jest jakiś specjalistyczny indeks, ponieważ zauważyliśmy, że w zapytaniu jest zbyt wiele odfiltrowanych wierszy.
Przyjrzyjmy się bliżej, co się wydarzyło. Rzeczywiście, widzimy, że przeczytaliśmy prawie półtora gigabajta danych z pamięci podręcznej dysku lub nawet z dysku. I to nie jest dobree, ponieważ uzyskaliśmy tylko 142 wiersze.
I wydawałoby się, że mamy tutaj skanowanie indeksu i powinno to działać szybko, ale ponieważ odfiltrowaliśmy zbyt wiele wierszy (musieliśmy je policzyć), więc zapytanie działało wolno.
I to się zdarzyło w planie, ponieważ warunki zapytania i warunki w indeksie częściowo nie pasują.
Spróbujmy zrobić indeks dokładniejszym i zobaczmy, jak zmieni się wydajność zapytania po tym.
Tworzenie indeksu zajęło sporo czasu, ale teraz sprawdzamy zapytanie i widzimy, że czas zamiast 2,5 minuty wynosi tylko 156 milisekund, co jest całkiem dobre. I czytamy tylko 6 megabajtów danych.
I teraz używamy skanowania tylko indeksu.
Inną ważną kwestią jest to, że chcemy przedstawić plan w bardziej zrozumiały sposób. Wprowadziliśmy wizualizację za pomocą Flame Graphs.
To inne zapytanie, bardziej złożone. Flame Graphs tworzymy na podstawie dwóch parametrów: ilości danych, które konkretna węzeł w planie przeczytała oraz czasu, tzn. czasu wykonania węzła.
Tutaj możemy porównywać konkretne węzły ze sobą. Będzie jasne, który z nich zajmuje więcej lub mniej miejsca, co zazwyczaj jest trudne do zrobienia w innych metodach wizualizacji.
Oczywiście wszyscy znają explain.depesz.com. Dobrym atutem tej wizualizacji jest to, że zachowujemy tekstowy plan i również wyciągamy jakieś główne parametry do tabeli, aby móc je sortować.
I programiści, którzy jeszcze nie zagłębiali się w ten temat, również korzystają z explain.depesz.com, ponieważ dla nich łatwiej zrozumieć, jakie metryki są ważne, a które nie.
Jest nowe podejście do wizualizacji - to explain.dalibo.com. Tworzą wizualizację drzewiastą, ale tutaj bardzo trudno jest porównywać węzły między sobą. Można dobrze zrozumieć strukturę, ale jeśli zapytanie jest duże, to trzeba będzie przewijać tam i z powrotem, ale to też opcja.
Współpraca
I, jak już powiedziałem, Slack daje nam możliwość współpracy. Na przykład, jeśli napotkaliśmy skomplikowane zapytanie, które trudno zoptymalizować, możemy wyjaśnić ten problem w wątku na Slacku z naszymi kolegami.
Uważamy, że ważne jest testowanie na pełnowymiarowych danych. W tym celu stworzyliśmy narzędzie Update Database Lab, które jest dostępne w open source. Możesz również używać bota Joe. Możesz go wziąć już teraz i zaimplementować u siebie. Wszystkie przewodniki są tam dostępne.
Warto również zauważyć, że samo rozwiązanie nie jest rewolucyjne, ponieważ istnieje Delphix, ale to jest rozwiązanie dla przedsiębiorstw. Jest całkowicie zamknięte i kosztuje bardzo dużo. My specjalizujemy się w Postgres. To wszystko produkty open source. Dołącz do nas!
Na tym kończę. Dziękuję!
Pytania
Cześć! Dziękuję za prezentację! Bardzo interesujące, szczególnie dla mnie, ponieważ rozwiązuję podobne zadanie od pewnego czasu. Mam zatem szereg pytań. Mam nadzieję, że przynajmniej część z nich zadam.
Ciekawe, jak obliczacie miejsce dla tego środowiska? Technologia zakłada, że przy określonych okolicznościach wasze klony mogą urosnąć do maksymalnego rozmiaru. Mówiąc wprost, jeśli macie dziesięcio-terabajtową bazę danych i 10 klonów, to łatwo można sobie wyobrazić sytuację, w której każdy klon będzie zawierał 10 unikalnych danych. Jak obliczacie to miejsce, to znaczy tę deltę, o której mówiliście, w której będą żyły te klony?
Dobre pytanie. Ważne jest, aby śledzić konkretne klony. Jeśli klon wymaga zbyt dużych zmian i zaczyna rosnąć, możemy najpierw poinformować użytkownika o tym, albo natychmiast zatrzymać ten klon, aby uniknąć sytuacji awaryjnej.
Tak, mam dodatkowe pytanie. Jak zapewniacie cykl życia tych modułów? Mamy z tym problem i to cała osobna historia. Jak to działa?
Każdy klon ma określony ttl. Zasadniczo mamy stały ttl.
Jaki, jeśli można zapytać?
1 godzina, czyli idle – 1 godzina. Jeśli nie jest używany, to go usuwamy. Ale tutaj nie ma nic dziwnego, ponieważ możemy uruchamiać klon w ciągu sekund. Jeśli będzie znowu potrzebny, to – proszę bardzo.
Ciekawi mnie również wybór technologii, ponieważ my na przykład równolegle wykorzystujemy kilka różnych metod z różnych powodów. Dlaczego akurat ZFS? Dlaczego nie użyliście LVM? Wspomniałeś, że były problemy z LVM. Jakie to były problemy? Moim zdaniem, najbardziej optymalnym rozwiązaniem jest użycie macierzy dyskowej z punktu widzenia wydajności.
Jaka jest główna wada ZFS? To, że musisz uruchamiać ją na jednym hoście, tzn. wszystkie instancje będą działać w ramach jednego systemu operacyjnego. W przypadku macierzy dyskowej możesz podłączać różne urządzenia. I wąskim gardłem są tylko te blokady, które znajdują się na macierzy. Interesujące jest pytanie dotyczące wyboru technologii. Dlaczego nie LVM?
Możemy omówić LVM na meetupie. Co do macierzy – to po prostu kosztowne. System ZFS możemy wdrożyć wszędzie. Możesz go uruchomić na swoim komputerze. Możesz po prostu pobrać repozytorium i zainstalować. ZFS działa praktycznie wszędzie, jeśli mówimy o Linuksie. Oznacza to, że otrzymujemy bardzo elastyczne rozwiązanie. ZFS z pudełka oferuje wiele. Możesz przechowywać nieograniczoną ilość danych, podłączać dużą liczbę dysków, są zrzuty snapshota. I jak już mówiłem, administracja jest bardzo prosta. To rozwiązanie wydaje się bardzo przyjemne w użytkowaniu. Jest sprawdzone, ma wiele lat. Ma ogromne społeczność, która się rozwija. ZFS to bardzo niezawodne rozwiązanie.
Nikolaj Samochwałow: Czy mogę jeszcze skomentować? Nazywam się Nikolaj, pracuję razem z Anatolijem. Zgadzam się, że macierz to świetne rozwiązanie. I niektórzy z naszych klientów mają Pure Storage itd.
Anatolij słusznie zauważył, że dążymy do modularności. W przyszłości możemy zrealizować jeden interfejs – wykonaj zrzut, zrób klon, zniszcz klon. To wszystko jest łatwe. A macierz dyskowa jest świetna, jeśli jest dostępna.
Ale ZFS jest dostępny dla wszystkich. Już wystarczy DelPhix, mają 300 klientów. Z nich w Fortune 100 - 50 klientów, tj. koncentrują się na NASA itd. Czas, aby ta technologia była dostępna dla wszystkich. Dlatego mamy open source Core. Mamy część interfejsową, która nie jest open source. To jest platforma, którą pokażemy. Ale chcemy, aby była dostępna dla każdego. Chcemy zrewolucjonizować, aby wszyscy testerzy przestali zgadywać na laptopach. Musimy pisać SELECT i od razu widzieć, że jest wolny. Dość czekania, aż DBA o tym powie. To jest nasz główny cel. I myślę, że wszyscy do tego dojdziemy. I ten element robimy, aby był dostępny dla wszystkich. Dlatego ZFS, ponieważ będzie dostępny wszędzie. Dziękuję społeczności za rozwiązywanie problemów i za to, że mają licencję open source itd.
Witaj! Dziękuję za prezentację! Nazywam się Maksym. Mieliśmy podobne problemy. U siebie je rozwiązaliśmy. Jak dzielicie zasoby między tymi klonami? Każdy klon w każdej chwili może robić swoje: jeden testuje coś innego, inny coś innego, ktoś buduje indeks, ktoś inny ma ciężką pracę. I jeśli można podzielić po CPU, to jak dzielicie po IO? To jest pierwsze pytanie.
A drugie pytanie dotyczy różnorodności środowisk. Załóżmy, że tu mam ZFS i wszystko jest świetnie, a klient na produkcji nie ma ZFS, tylko ext4, na przykład. Jak w takim przypadku?
Bardzo dobre pytania. Trochę wspomniałem o tym problemie z dzieleniem zasobów. Rozwiązanie jest następujące. Wyobraź sobie, że testujesz na staging. Może się zdarzyć, że ktoś obciąża jeden zasób, a ktoś inny inny. I w rezultacie widzisz nieczytelne metryki. Taki sam problem może wystąpić na produkcji. Kiedy chcesz sprawdzić zapytanie i widzisz, że jest z nim jakiś problem – działa wolno, to w rzeczywistości problem nie był w zapytaniu, a w tym, że jest jakieś równoległe obciążenie.
Dlatego ważne jest, aby skupić się na tym, jaki będzie plan, jakie kroki podejmiemy w ramach planu i ile danych będziemy musieli przetworzyć. To, że nasze dyski będą obciążone, wpłynie na harmonogram. Możemy jednak ocenić stopień obciążenia zapytania po ilości danych. Nie ma znaczenia, co jeszcze będzie wykonywane jednocześnie.
Mam dwa pytania. To naprawdę świetna rzecz. Czy były przypadki, gdy dane produkcyjne były krytycznie ważne, na przykład numery kart kredytowych? Czy jest już coś gotowego, czy to osobne zadanie? I drugie pytanie – czy jest coś takiego dla MySQL?
Jeśli chodzi o dane. Będziemy stosować obfuskację, dopóki tego nie zrobimy. Ale jeśli wdrażasz Joe i nie udostępniasz dostępu programistom, nie ma dostępu do danych. Dlaczego? Ponieważ Joe nie pokazuje danych. Pokazuje tylko metryki, plany i tyle. Zostało to specjalnie zaprojektowane, ponieważ jest to jedno z wymagań naszego klienta. Chcieli mieć możliwość optymalizacji, ale nie udostępniać dostępu wszystkim.
Jeśli chodzi o MySQL. Ten system można wykorzystać do dowolnych celów, które przechowują stan na dysku. Ponieważ zajmujemy się Postgres, w pierwszej kolejności automatyzujemy wszystko dla Postgres. Chcemy zautomatyzować pozyskiwanie danych z kopii zapasowej. Prawidłowo konfiguruje Postgres. Wiemy, jak dopasować plany itd.
Jednak ponieważ system jest rozszerzalny, będzie można go również wykorzystać dla MySQL. Są takie przykłady. Podobne rozwiązanie ma Yandex, ale nie publikuje go nigdzie. Używają go wewnętrznie w Yandex.Metryce. I to jest właśnie historia związana z MySQL. Ale technologie są takie same, ZFS.
Dziękuję za wykład! Mam również kilka pytań. Wspomniałeś, że klonowanie można wykorzystać do analityki, na przykład do budowania dodatkowych indeksów. Czy możesz nieco bardziej szczegółowo opowiedzieć, jak to działa?
I od razu zadam drugie pytanie dotyczące jednorodności stanowisk i planów. Plan zależy częściowo od statystyk zbieranych przez Postgres. Jak rozwiązujecie ten problem?
Nie ma analizy konkretnych przypadków, ponieważ jeszcze tak nie korzystaliśmy, ale taka możliwość istnieje. Jeśli mówimy o indeksach, wyobraźcie sobie, że zapytanie jest wykonywane na tabeli z setkami milionów rekordów i w kolumnie, która zwykle nie jest indeksowana w prod. A my chcemy obliczyć jakieś dane. Jeśli to zapytanie zostanie wykonane w prod, istnieje możliwość, że w prod wystąpi przestój, ponieważ zapytanie będzie się tam wykonywać przez minutę.
Ok, zróbmy cienką kopię, której nie będzie strasznie zatrzymać na kilka minut. A aby łatwiej było liczyć analitykę, dodamy indeksy do tych kolumn, które nas interesują.
Czy indeks będzie tworzony za każdym razem?
Można to zrobić tak, że dotkniemy danych, zrobimy zrzuty, a potem z tego zrzutu będziemy się odbudowywać i wykonywać nowe zapytania. Tzn. można zrobić tak, że uda się podnieść nowe klony z już ustawionymi indeksami.
Jeśli chodzi o kwestię statystyki, to jeśli odbudowujemy się z kopii zapasowej, jeśli robimy replikację, to nasza statystyka będzie dokładnie taka sama. Ponieważ mamy całkowitą fizyczną strukturę danych, tzn. przyniesiemy dane, jakie są, ze wszystkimi metrykami statystyk również.
Tutaj jest inny problem. Jeśli używane jest rozwiązanie w chmurze, to dostępne są tylko zrzuty logiczne, ponieważ Google, Amazon nie pozwala na wzięcie fizycznej kopii. Tam pojawi się taki problem.
Dziękuję za prezentację. Pojawiły się dwa dobre pytania dotyczące MySQL i podziału zasobów. Ale w zasadzie wszystko sprowadza się do tego, że to jest temat nie konkretnych DBMS, ale w ogóle systemu plików. I odpowiednio pytania dotyczące podziału zasobów również powinny być rozwiązywane stamtąd, nie na końcu, że to Postgres, ale w systemie plików, w serwerze, w instancji.
Moje pytanie dotyczy nieco innej kwestii. Jest bardziej związane z wielowarstwowością bazy danych, w której jest kilka warstw. Na przykład skonfigurowaliśmy aktualizację dziesięcio terabajtowego obrazu, mamy replikację. I konkretne rozwiązanie wykorzystujemy dla baz danych. Trwa replikacja, odbywa się aktualizacja danych. Równocześnie pracuje 100 pracowników, którzy ciągle uruchamiają te różne zrzuty. Co robić? Jak zrobić, aby nie było konfliktu, że uruchomili to jedno, a potem system plików się zmienił, i te zrzuty się zepsuły?
Nie będą jeździć, ponieważ tak działa ZFS. Możemy osobno przechowywać w jednym strumieniu zmiany systemu plików, które przychodzą dzięki replikacji. I na starszych wersjach danych trzymać klony, które używają programiści. I to u nas działa, wszystko w porządku.
Wygląda na to, że aktualizacja będzie zachodzić jako dodatkowa warstwa, a wszystkie nowe migawki będą pochodzić już z tej warstwy, prawda?
Z wcześniejszych warstw, które pochodziły z poprzednich replikacji.
Poprzednie warstwy odpadną, ale będą odwoływać się do starej warstwy, a nowe obrazy będą pobierane z ostatniej warstwy, która została uzyskana w aktualizacji?
Generalnie tak.
W takim razie, jako skutek, będziemy mieli mnóstwo warstw. I z czasem trzeba je będzie kompresować?
Tak, dokładnie. Istnieje pewne okno. Zachowujemy tygodniowe migawki. To zależy od tego, jakie masz zasoby. Jeśli masz możliwość przechowywania dużych ilości danych, można długo przechowywać migawki. One same się nie usuną. Nie będzie żadnej utraty danych. Jeśli migawki się zestarzeją, jak nam się wydaje, tzn. to zależy od polityki w firmie, to po prostu możemy je usunąć i zwolnić miejsce.
Dzień dobry, dziękuję za prezentację! Co do pytania Joe. Powiedziałeś, że klient nie chciał dawać wszystkim dostępu do danych. Ścisłe mówiąc, jeśli ktoś ma wynik Explain Analyze, to może podglądać dane.
Tak, dokładnie. Na przykład, możemy napisać: „SELECT FROM WHERE email = coś tam”. Tzn. nie zobaczymy samych danych, ale możemy zobaczyć jakieś pośrednie wskaźniki. To trzeba rozumieć. Z drugiej strony wszystko to jest widoczne. Mamy audyt logów, mamy kontrolę innych kolegów, którzy również widzą, co robią programiści. I jeśli ktoś spróbuje tak zrobić, to do nich przyjdzie służba bezpieczeństwa i zajmie się tym problemem.
Dzień dobry! Dziękuję za prezentację! Mam krótkie pytanie. Jeśli w firmie nie używa się Slacka, to czy teraz jest do niego jakieś powiązanie, czy można dla programistów uruchomić instancje, aby podłączyć do baz testową aplikację?
Obecnie istnieje integracja z Slackiem, tzn. nie ma żadnego innego komunikatora, ale bardzo chciałbym wprowadzić wsparcie dla innych komunikatorów. Co możesz zrobić? Możesz uruchomić u siebie DB Lab bez Joe, korzystając z REST API lub naszej platformy, tworzyć klony i podłączać się do PSQL. Tak można to zrobić, jeśli jesteś gotów dać swoim programistom dostęp do danych, ponieważ już nie będzie tutaj ekranu.
Nie potrzebuję tej warstwy, ale potrzebna mi taka możliwość.
W takim razie – tak, to można zrobić.
Źródło: habr.com
