Bot DBA Joe. Anatolij Stansler (Postgres.ai)

W jaki sposób programista backendu rozumie, że zapytanie SQL będzie dobrze działać na „prodzie”? W dużych lub prężnie rozwijających się firmach nie każdy ma dostęp do „produktu”. A mając dostęp, nie wszystkie zgłoszenia można bezboleśnie sprawdzić, a utworzenie kopii bazy danych często zajmuje godziny. Aby rozwiązać te problemy, stworzyliśmy sztucznego DBA - Joe. Zostało już z powodzeniem wdrożone w kilku firmach i pomaga kilkunastu programistom.

Video:

Cześć wszystkim! Nazywam się Anatolij Stansler. Pracuję dla firmy postgres.ai. Zależy nam na przyspieszeniu procesu rozwoju poprzez usunięcie opóźnień związanych z pracą Postgres od programistów, administratorów baz danych i kontrolerów jakości.

Mamy wspaniałych klientów i dziś część raportu zostanie poświęcona przypadkom, z którymi spotkaliśmy się podczas pracy z nimi. Opowiem o tym, jak pomogliśmy im rozwiązać dość poważne problemy.

Kiedy opracowujemy i przeprowadzamy złożone migracje o dużym obciążeniu, zadajemy sobie pytanie: „Czy ta migracja wystartuje?”. Korzystamy z recenzji, korzystamy z wiedzy bardziej doświadczonych kolegów, ekspertów DBA. I mogą powiedzieć, czy będzie latać, czy nie.

Ale może byłoby lepiej, gdybyśmy sami mogli przetestować to na pełnowymiarowych egzemplarzach. A dzisiaj porozmawiamy tylko o tym, jakie podejście do testowania jest teraz i jak można to zrobić lepiej i za pomocą jakich narzędzi. Porozmawiamy również o zaletach i wadach takiego podejścia oraz o tym, co możemy tutaj naprawić.

Kto kiedykolwiek robił indeksy bezpośrednio na prod lub wprowadzał jakieś zmiany? Sporo. I dla kogo doprowadziło to do utraty danych lub przestojów? Więc znasz ten ból. Dzięki Bogu są kopie zapasowe.

Pierwszym podejściem jest testowanie w prod. Lub, gdy programista siedzi na lokalnej maszynie, ma dane testowe, jest jakiś ograniczony wybór. Wychodzimy na prod i mamy taką sytuację.

To boli, jest drogie. Chyba lepiej tego nie robić.

A jak najlepiej to zrobić?

Weźmy inscenizację i wybierzmy tam część produkcji. Albo w najlepszym razie weźmy prawdziwy prod, wszystkie dane. A po opracowaniu go lokalnie dodatkowo sprawdzimy, czy nie ma inscenizacji.

Pozwoli nam to usunąć część błędów, czyli zapobiec ich występowaniu na prod.

Jakie są problemy?

• Problem polega na tym, że dzielimy się tą inscenizacją z kolegami. I bardzo często zdarza się, że dokonujesz jakiejś zmiany, bam - a nie ma danych, praca idzie na marne. Inscenizacja była wieloterabajtowa. I trzeba długo czekać, aż znów się podniesie. I postanawiamy sfinalizować to jutro. To wszystko, mamy rozwój.
• I oczywiście pracuje tam wielu kolegów, wiele zespołów. I trzeba to zrobić ręcznie. A to jest niewygodne.

A warto powiedzieć, że mamy tylko jedną próbę, jeden strzał, jeśli chcemy wprowadzić jakieś zmiany w bazie danych, dotknąć danych, zmienić strukturę. A jeśli coś poszło nie tak, jeśli wystąpił błąd w migracji, to szybko się nie cofniemy.

Jest to lepsze niż poprzednie podejście, ale nadal istnieje duże prawdopodobieństwo, że jakiś błąd trafi do produkcji.

Co stoi na przeszkodzie, aby dać każdemu deweloperowi stanowisko testowe, pełnowymiarową kopię? Myślę, że to jasne, co stoi na przeszkodzie.

Kto ma bazę danych większą niż terabajt? Więcej niż połowa pokoju.

A wiadomo, że utrzymanie maszyn dla każdego dewelopera przy tak dużej produkcji jest bardzo kosztowne, a poza tym zajmuje dużo czasu.

Mamy klientów, którzy zdali sobie sprawę, że bardzo ważne jest testowanie wszystkich zmian na pełnowymiarowych kopiach, ale ich baza danych jest mniejsza niż terabajt i nie ma zasobów, aby utrzymać stanowisko testowe dla każdego programisty. Dlatego muszą pobrać zrzuty lokalnie na swój komputer i przetestować w ten sposób. To zajmuje dużo czasu.

Nawet jeśli robisz to wewnątrz infrastruktury, to pobieranie jednego terabajta danych na godzinę jest już bardzo dobre. Ale używają zrzutów logicznych, pobierają lokalnie z chmury. Dla nich prędkość wynosi około 200 gigabajtów na godzinę. I nadal potrzeba czasu, aby odwrócić się od zrzutu logicznego, zwinąć indeksy itp.

Ale używają tego podejścia, ponieważ pozwala im to zachować niezawodność produktu.

Co możemy tutaj zrobić? Sprawmy, by stanowiska testowe były tanie i dajmy każdemu programiście własne stanowisko testowe.

I to jest możliwe.

I w tym podejściu, kiedy tworzymy cienkie klony dla każdego programisty, możemy je udostępnić na jednej maszynie. Na przykład, jeśli masz bazę danych o pojemności 10 TB i chcesz ją przekazać 10 programistom, nie musisz mieć baz danych XNUMX x XNUMX TB. Potrzebujesz tylko jednego komputera, aby wykonać cienkie izolowane kopie dla każdego programisty przy użyciu jednego komputera. Powiem ci, jak to działa trochę później.

Prawdziwy przykład:

• DB - 4,5 terabajta.

• Niezależne kopie możemy uzyskać w 30 sekund.

Nie musisz czekać na stanowisko testowe i polegać na jego wielkości. Możesz go zdobyć w kilka sekund. Będą to całkowicie odizolowane środowiska, ale dzielące się między sobą danymi.

To jest świetne. Tutaj mówimy o magii i równoległym wszechświecie.

W naszym przypadku działa to przy użyciu systemu OpenZFS.

OpenZFS to system plików kopiowania przy zapisie, który obsługuje migawki i klony po wyjęciu z pudełka. Jest niezawodny i skalowalny. Jest bardzo łatwa w zarządzaniu. Można go dosłownie wdrożyć w dwóch zespołach.

Istnieją inne opcje:

• lvm,

• Storage (na przykład Pure Storage).

Laboratorium bazy danych, o którym mówię, jest modułowe. Można zaimplementować za pomocą tych opcji. Ale na razie skupiliśmy się na OpenZFS, ponieważ były problemy szczególnie z LVM.

Jak to działa? Zamiast nadpisywać dane za każdym razem, gdy je zmieniamy, zapisujemy je po prostu zaznaczając, że te nowe dane pochodzą z nowego punktu w czasie, nowej migawki.

A w przyszłości, gdy będziemy chcieli cofnąć lub zrobić nowy klon z jakiejś starszej wersji, po prostu mówimy: „OK, daj nam te bloki danych, które są tak oznaczone”.

I ten użytkownik będzie pracował z takim zestawem danych. Będzie je sukcesywnie zmieniał, robił własne migawki.

I będziemy się rozgałęziać. Każdy programista w naszym przypadku będzie miał możliwość posiadania własnego klona, ​​który edytuje, a udostępniane dane będą udostępniane wszystkim.

Aby wdrożyć taki system w domu, musisz rozwiązać dwa problemy:

• Pierwszym jest źródło danych, skąd je weźmiesz. Możesz skonfigurować replikację z produkcją. Mam nadzieję, że możesz już korzystać z kopii zapasowych, które skonfigurowałeś. WAL-E, WAL-G lub Barman. Nawet jeśli korzystasz z rozwiązania chmurowego, takiego jak RDS lub Cloud SQL, możesz używać zrzutów logicznych. Nadal jednak zalecamy korzystanie z kopii zapasowych, ponieważ dzięki takiemu podejściu zachowasz również fizyczną strukturę plików, co pozwoli ci być jeszcze bliżej metryk, które zobaczysz w produkcji, w celu wykrycia istniejących problemów.

• Drugi to miejsce, w którym chcesz hostować Laboratorium bazy danych. Może to być chmura, może być on-premise. Należy tutaj powiedzieć, że ZFS obsługuje kompresję danych. I robi to całkiem dobrze.

Wyobraźmy sobie, że dla każdego takiego klona, ​​w zależności od operacji, które wykonamy z bazą, będzie rósł jakiś dev. W tym celu dev będzie również potrzebował miejsca. Ale ponieważ wzięliśmy bazę 4,5 terabajta, ZFS skompresuje ją do 3,5 terabajta. Może się to różnić w zależności od ustawień. I wciąż mamy miejsce dla dev.

Taki system można zastosować w różnych przypadkach.

• Są to programiści, administratorzy baz danych do sprawdzania poprawności zapytań, do optymalizacji.

• Można to wykorzystać w testach kontroli jakości, aby przetestować konkretną migrację, zanim wprowadzimy ją do produktu. Możemy również stworzyć specjalne środowiska dla QA z prawdziwymi danymi, w których mogą testować nowe funkcje. I zajmie to sekundy zamiast godzin oczekiwania, a może dni w niektórych innych przypadkach, w których cienkie kopie nie są używane.

• I kolejny przypadek. Jeśli firma nie ma skonfigurowanego systemu analitycznego, możemy wyizolować cienki klon bazy produktów i przekazać go do długich zapytań lub specjalnych indeksów, które można wykorzystać w analityce.

Z takim podejściem:

1. Niskie prawdopodobieństwo błędów na „prodzie”, ponieważ wszystkie zmiany testowaliśmy na pełnowymiarowych danych.

2. Mamy kulturę testowania, bo teraz nie musisz czekać godzinami na własne stoisko.

3. I nie ma bariery, nie ma czekania między testami. Naprawdę możesz iść i sprawdzić. I tak będzie lepiej, gdy przyspieszymy rozwój.

• Będzie mniej refaktoryzacji. Mniej błędów znajdzie się w prod. Później zmienimy je mniej.

• Możemy cofnąć nieodwracalne zmiany. To nie jest standardowe podejście.

1. Jest to korzystne, ponieważ dzielimy zasoby stanowisk testowych.

Już dobrze, ale co jeszcze można przyspieszyć?

Dzięki takiemu systemowi możemy znacznie obniżyć próg przystąpienia do takiego badania.

Teraz powstaje błędne koło, w którym programista, aby uzyskać dostęp do prawdziwych, pełnowymiarowych danych, musi zostać ekspertem. Trzeba mu zaufać w kwestii takiego dostępu.

Ale jak rosnąć, jeśli go nie ma. Ale co, jeśli masz do dyspozycji tylko bardzo mały zestaw danych testowych? Wtedy nie zdobędziesz żadnego prawdziwego doświadczenia.

Jak wyjść z tego kręgu? Jako pierwszy interfejs, wygodny dla programistów na każdym poziomie, wybraliśmy bota Slack. Ale może to być dowolny inny interfejs.

Co pozwala ci robić? Możesz wziąć konkretne zapytanie i wysłać je do specjalnego kanału dla bazy danych. W ciągu kilku sekund automatycznie wdrożymy cienki klon. Uruchommy to żądanie. Zbieramy dane i rekomendacje. Pokażmy wizualizację. A potem ten klon pozostanie, aby to zapytanie można było jakoś zoptymalizować, dodać indeksy itp.

A także Slack daje nam możliwości współpracy od razu po wyjęciu z pudełka. Ponieważ jest to tylko kanał, możesz zacząć omawiać tę prośbę bezpośrednio w wątku dotyczącym takiej prośby, pingować swoich kolegów, administratorów baz danych, którzy są w firmie.

Ale są oczywiście problemy. Ponieważ to jest prawdziwy świat i używamy serwera, na którym znajduje się wiele klonów jednocześnie, musimy skompresować ilość pamięci i mocy procesora dostępnej dla klonów.

Ale aby te testy były wiarygodne, musisz jakoś rozwiązać ten problem.

Oczywiste jest, że ważnym punktem są te same dane. Ale już to mamy. I chcemy osiągnąć tę samą konfigurację. I taką niemal identyczną konfigurację możemy podać.

Fajnie byłoby mieć taki sam sprzęt jak w produkcji, ale może się różnić.

Przypomnijmy sobie, jak Postgres działa z pamięcią. Mamy dwie skrytki. Jeden z systemu plików i jeden natywny Postgres, czyli Shared Buffer Cache.

Należy zauważyć, że współdzielona pamięć podręczna bufora jest przydzielana podczas uruchamiania Postgres, w zależności od rozmiaru określonego w konfiguracji.

A druga pamięć podręczna wykorzystuje całą dostępną przestrzeń.

A kiedy robimy kilka klonów na jednej maszynie okazuje się, że stopniowo zapełniamy pamięć. I w dobry sposób, wspólna pamięć podręczna bufora stanowi 25% całkowitej ilości pamięci dostępnej na komputerze.

I okazuje się, że jeśli nie zmienimy tego parametru, to będziemy mogli uruchomić tylko 4 instancje na jednej maszynie, czyli łącznie 4 takie cienkie klony. A to oczywiście źle, bo chcemy mieć ich znacznie więcej.

Ale z drugiej strony Buffer Cache służy do wykonywania zapytań o indeksy, czyli plan zależy od tego, jak duże są nasze pamięci podręczne. A jeśli po prostu weźmiemy ten parametr i zmniejszymy go, nasze plany mogą się bardzo zmienić.

Na przykład, jeśli mamy dużą pamięć podręczną na prod, to Postgres będzie wolał użyć indeksu. A jeśli nie, to będzie SeqScan. I jaki byłby sens, gdyby nasze plany się nie pokrywały?

Ale tutaj dochodzimy do wniosku, że tak naprawdę plan w Postgresie nie jest zależny od konkretnego rozmiaru określonego w Shared Buffer w planie, tylko od Effective_cache_size.

Efektywna_rozmiar_pamięci podręcznej to szacowana ilość dostępnej dla nas pamięci podręcznej, czyli suma pamięci podręcznej bufora i pamięci podręcznej systemu plików. Jest to ustawione przez config. I ta pamięć nie jest przydzielona.

A dzięki temu parametrowi możemy oszukać Postgresa, mówiąc, że faktycznie mamy dużo dostępnych danych, nawet jeśli ich nie mamy. I tak plany całkowicie zbiegną się z produkcją.

Ale to może wpłynąć na czas. Optymalizujemy zapytania według czasu, ale ważne jest, że czas zależy od wielu czynników:

• To zależy od obciążenia, które jest aktualnie na prod.

• Zależy to od charakterystyki samej maszyny.

I jest to parametr pośredni, ale tak naprawdę możemy optymalizować dokładnie o ilość danych, które to zapytanie odczyta, aby uzyskać wynik.

A jeśli chcesz, aby czas był zbliżony do tego, co zobaczymy w produkcji, musimy wziąć najbardziej podobny sprzęt i być może nawet więcej, aby wszystkie klony pasowały. Ale to jest kompromis, czyli dostaniesz te same plany, zobaczysz ile danych odczyta dane zapytanie i będziesz mógł wnioskować czy to zapytanie jest dobre (lub migracja) czy złe, trzeba to jeszcze zoptymalizować .

Przyjrzyjmy się, jak Joe jest specjalnie zoptymalizowany.

Weźmy żądanie z prawdziwego systemu. W tym przypadku baza danych zajmuje 1 terabajt. I chcemy policzyć liczbę świeżych postów, które miały więcej niż 10 polubień.

Piszemy wiadomość do kanału, klon został dla nas wdrożony. I zobaczymy, że takie żądanie zakończy się w 2,5 minuty. To pierwsza rzecz, na którą zwracamy uwagę.

B Joe pokaże Ci automatyczne rekomendacje na podstawie planu i wskaźników.

Zobaczymy, że zapytanie przetwarza zbyt dużo danych, aby uzyskać stosunkowo małą liczbę wierszy. Potrzebny jest jakiś wyspecjalizowany indeks, ponieważ zauważyliśmy, że w zapytaniu jest zbyt wiele przefiltrowanych wierszy.

Przyjrzyjmy się bliżej temu, co się stało. Rzeczywiście widzimy, że odczytaliśmy prawie półtora gigabajta danych z pamięci podręcznej plików lub nawet z dysku. A to niedobrze, bo mamy tylko 142 linie.

I wydawałoby się, że mamy tutaj skanowanie indeksu i powinno działać szybko, ale ponieważ odfiltrowaliśmy zbyt wiele wierszy (musieliśmy je policzyć), żądanie powoli zadziałało.

A stało się tak w planie ze względu na to, że warunki w zapytaniu i warunki w indeksie częściowo się nie zgadzają.

Spróbujmy uściślić indeks i zobaczyć, jak po tym zmieni się wykonanie zapytania.

Tworzenie indeksu trwało dość długo, ale teraz sprawdzamy zapytanie i widzimy, że czas zamiast 2,5 minuty to tylko 156 milisekund, co jest wystarczające. A odczytujemy tylko 6 megabajtów danych.

A teraz używamy tylko skanowania indeksu.

Kolejną ważną historią jest to, że chcemy przedstawić plan w bardziej zrozumiały sposób. Wdrożyliśmy wizualizację z wykorzystaniem Flame Graphs.

To inna prośba, bardziej intensywna. A Flame Graph budujemy według dwóch parametrów: jest to ilość danych, które dany węzeł naliczył w planie oraz timing, czyli czas wykonania węzła.

Tutaj możemy porównać ze sobą poszczególne węzły. I będzie jasne, który z nich zajmuje więcej lub mniej, co zwykle jest trudne do wykonania w innych metodach renderowania.

Oczywiście, wszyscy znają explain.depesz.com. Dobrą cechą tej wizualizacji jest to, że zapisujemy plan tekstu, a także umieszczamy kilka podstawowych parametrów w tabeli, abyśmy mogli sortować.

A programiści, którzy jeszcze nie zagłębiali się w ten temat, również korzystają z explain.depesz.com, ponieważ łatwiej jest im zorientować się, które metryki są ważne, a które nie.

Pojawiło się nowe podejście do wizualizacji - to explain.dalibo.com. Robią wizualizację drzewa, ale bardzo trudno jest porównać ze sobą węzły. Tutaj możesz dobrze zrozumieć strukturę, jednak jeśli jest duże żądanie, będziesz musiał przewijać w przód iw tył, ale także opcję.

Kolaboracja

I, jak powiedziałem, Slack daje nam możliwość współpracy. Na przykład, jeśli natrafimy na złożone zapytanie, które nie jest jasne, jak zoptymalizować, możemy wyjaśnić ten problem z naszymi współpracownikami w wątku na Slack.

Wydaje nam się, ż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 wersji open source. Możesz też użyć bota Joe. Możesz go wziąć już teraz i wdrożyć u siebie. Wszystkie przewodniki są tam dostępne.

Należy również zauważyć, że samo rozwiązanie nie jest rewolucyjne, bo istnieje Delphix, ale jest to rozwiązanie korporacyjne. Jest całkowicie zamknięty, jest bardzo drogi. Specjalizujemy się w Postgresie. To wszystko są produkty open source. Dołącz do nas!

Tutaj kończę. Dziękuję!

pytania

Cześć! Dzięki za raport! Bardzo interesujące, szczególnie dla mnie, ponieważ rozwiązałem ten sam problem jakiś czas temu. I tak mam szereg pytań. Mam nadzieję, że chociaż część z tego dostanę.

Zastanawiam się, jak obliczasz miejsce dla tego środowiska? Technologia oznacza, że ​​w pewnych okolicznościach twoje klony mogą urosnąć do maksymalnych rozmiarów. Z grubsza mówiąc, jeśli masz bazę danych o pojemności dziesięciu terabajtów i 10 klonów, łatwo jest zasymulować sytuację, w której każdy klon waży 10 unikalnych danych. Jak wyliczyć to miejsce, czyli tę deltę, o której mówiłeś, w której te klony będą żyły?

Dobre pytanie. Ważne jest, aby śledzić tutaj konkretne klony. A jeśli klon ma jakąś zbyt dużą zmianę, zaczyna rosnąć, wtedy możemy najpierw ostrzec użytkownika o tym, lub natychmiast zatrzymać ten klon, aby nie mieć sytuacji awaryjnej.

Tak, mam zagnieżdżone pytanie. To znaczy, jak zapewnić cykl życia tych modułów? Mamy ten problem i całą osobną historię. Jak to się stało?

Dla każdego klonu jest trochę ttl. Zasadniczo mamy stały ttl.

A co, jeśli nie tajemnica?

1 godzina, tj. bezczynny - 1 godzina. Jeśli nie jest używany, uderzamy go. Ale nie ma tu niespodzianki, ponieważ możemy wychować klona w kilka sekund. A jeśli potrzebujesz tego ponownie, proszę.

Interesuje mnie też dobór technologii, bo np. stosujemy równolegle kilka metod z tego czy innego powodu. Dlaczego ZFS? Dlaczego nie użyłeś LVM? Wspomniałeś, że były problemy z LVM. Jakie były problemy? Moim zdaniem najbardziej optymalną opcją jest pamięć pod względem wydajności.

Jaki jest główny problem z ZFS? Fakt, że musisz działać na tym samym hoście, tj. wszystkie instancje będą działać w tym samym systemie operacyjnym. A w przypadku przechowywania można podłączyć różne urządzenia. Wąskim gardłem są tylko te bloki, które znajdują się w systemie pamięci masowej. A kwestia wyboru technologii jest interesująca. Dlaczego nie LVM?

W szczególności możemy omówić LVM na meetupie. O przechowywaniu - to po prostu drogie. System ZFS możemy wdrożyć w dowolnym miejscu. Możesz wdrożyć go na swoim komputerze. Możesz po prostu pobrać repozytorium i wdrożyć je. ZFS jest instalowany prawie wszędzie, jeśli mówimy o Linuksie. Czyli otrzymujemy bardzo elastyczne rozwiązanie. A sam ZFS daje dużo po wyjęciu z pudełka. Możesz przesłać tyle danych, ile chcesz, podłączyć dużą liczbę dysków, są migawki. I, jak powiedziałem, jest łatwy w administrowaniu. Oznacza to, że wydaje się bardzo przyjemny w użyciu. Jest wypróbowany, ma wiele lat. Ma bardzo dużą społeczność, która rośnie. ZFS to bardzo niezawodne rozwiązanie.

Nikolai Samokhvalov: Czy mogę coś więcej skomentować? Nazywam się Nikolay, współpracujemy z Anatolijem. Zgadzam się, że przechowywanie jest świetne. A niektórzy z naszych klientów mają Pure Storage itp.

Anatolij słusznie zauważył, że stawiamy na modułowość. A w przyszłości możesz zaimplementować jeden interfejs - zrób migawkę, stwórz klona, ​​zniszcz klona. To wszystko jest łatwe. A przechowywanie jest fajne, jeśli jest.

Ale ZFS jest dostępny dla wszystkich. DelPhix już wystarczy, mają 300 klientów. Spośród nich fortune 100 ma 50 klientów, czyli są one skierowane do NASA itp. Czas, aby wszyscy zdobyli tę technologię. I dlatego mamy rdzeń open source. Mamy część interfejsu, która nie jest open source. To jest platforma, którą pokażemy. Chcemy jednak, aby była dostępna dla wszystkich. Chcemy zrobić rewolucję, aby wszyscy testerzy przestali zgadywać na laptopach. Musimy napisać SELECT i od razu zobaczyć, że jest wolny. Przestań czekać, aż DBA ci o tym powie. Oto główny cel. I myślę, że wszyscy do tego dojdziemy. I robimy to dla każdego. Dlatego ZFS, bo będzie dostępny wszędzie. Podziękowania dla społeczności za rozwiązywanie problemów i posiadanie licencji open source itp.*

Pozdrowienia! Dzięki za raport! Mam na imię Maksym. Zajmowaliśmy się tymi samymi problemami. Sami zdecydowali. W jaki sposób udostępniasz zasoby między tymi klonami? Każdy klon może w danym momencie zrobić coś własnego: jeden testuje jedną rzecz, inny inną, ktoś buduje indeks, ktoś ma ciężką pracę. A jeśli nadal możesz dzielić przez procesor, a następnie przez IO, jak dzielisz? To jest pierwsze pytanie.

A drugie pytanie dotyczy odmienności trybun. Powiedzmy, że mam tutaj ZFS i wszystko jest fajnie, ale klient na prod nie ma ZFS, ale na przykład ext4. Jak w tym przypadku?

Pytania są bardzo dobre. Wspomniałem trochę o tym problemie z faktem, że dzielimy się zasobami. A rozwiązanie jest takie. Wyobraź sobie, że testujesz na inscenizacji. Można też mieć taką sytuację w tym samym czasie, że ktoś daje jeden ładunek, ktoś inny. W rezultacie widzisz niezrozumiałe wskaźniki. Nawet ten sam problem może dotyczyć prod. Kiedy chcesz sprawdzić jakieś żądanie i widzisz, że jest z nim jakiś problem - działa wolno, to tak naprawdę problem nie leżał w żądaniu, ale w tym, że jest jakieś obciążenie równoległe.

I dlatego ważne jest tutaj, aby skupić się na tym, jaki będzie plan, jakie kroki podejmiemy w planie i ile danych do tego zbierzemy. Fakt, że np. nasze dyski będą czymś obciążone, wpłynie konkretnie na timing. Ale możemy oszacować, jak obciążone jest to żądanie na podstawie ilości danych. Nie jest tak ważne, że w tym samym czasie nastąpi jakaś egzekucja.

Mam dwa pytania. To jest bardzo fajna rzecz. Czy zdarzały się przypadki, w których kluczowe znaczenie miały dane produkcyjne, takie jak numery kart kredytowych? Czy coś już jest gotowe, czy to osobne zadanie? I drugie pytanie - czy jest coś takiego dla MySQL?

O danych. Będziemy robić zaciemnianie, dopóki tego nie zrobimy. Ale jeśli wdrożysz dokładnie Joe, jeśli nie dasz dostępu programistom, to nie ma dostępu do danych. Dlaczego? Ponieważ Joe nie pokazuje danych. Pokazuje tylko metryki, plany i tyle. Zrobiono to celowo, ponieważ jest to jedno z wymagań naszego klienta. Chcieli mieć możliwość optymalizacji bez udzielania wszystkim dostępu.

O MySQL. Ten system może być używany do wszystkiego, co przechowuje stan na dysku. A ponieważ zajmujemy się Postgresem, najpierw wykonujemy całą automatyzację Postgresa. Chcemy zautomatyzować pobieranie danych z kopii zapasowej. Konfigurujemy Postgres poprawnie. Wiemy jak dopasować plany itp.

Ale ponieważ system jest rozszerzalny, może być również używany do MySQL. I są takie przykłady. Yandex ma coś podobnego, ale nigdzie tego nie publikuje. Używają go wewnątrz Yandex.Metrica. I jest tylko opowieść o MySQL. Ale technologie są takie same, ZFS.

Dzięki za raport! Mam też kilka pytań. Wspomniałeś, że klonowanie można wykorzystać do analityki, na przykład do zbudowania tam dodatkowych indeksów. Czy możesz powiedzieć trochę więcej o tym, jak to działa?

I od razu zadam drugie pytanie o podobieństwo trybun, podobieństwo planów. Plan zależy również od statystyk zbieranych przez Postgres. Jak rozwiązać ten problem?

Według analityków nie ma konkretnych przypadków, bo jeszcze z tego nie korzystaliśmy, ale jest taka możliwość. Jeśli mówimy o indeksach, to wyobraź sobie, że zapytanie goni tabelę z setkami milionów rekordów i kolumną, która zwykle nie jest indeksowana w prod. I chcemy tam obliczyć pewne dane. Jeśli to żądanie zostanie wysłane do prod, to istnieje możliwość, że będzie to proste w prod, ponieważ żądanie będzie tam przetwarzane przez minutę.

Ok, zróbmy cienki klon, który nie jest straszny, aby zatrzymać się na kilka minut. A żeby wygodniej było czytać analitykę, dodamy indeksy dla tych kolumn, w których dane nas interesują.

Indeks będzie tworzony za każdym razem?

Możesz tak zrobić, żebyśmy dotykali danych, robili migawki, a następnie odzyskiwaliśmy z tej migawki i kierowaliśmy nowe żądania. Oznacza to, że możesz to zrobić, aby móc hodować nowe klony z już umieszczonymi indeksami.

Jeśli chodzi o pytanie o statystyki, jeśli przywrócimy z kopii zapasowej, jeśli wykonamy replikację, to nasze statystyki będą dokładnie takie same. Ponieważ mamy całą fizyczną strukturę danych, to znaczy, że przeniesiemy dane w takiej postaci, w jakiej są, wraz ze wszystkimi metrykami statystycznymi.

Oto kolejny problem. Jeśli korzystasz z rozwiązania chmurowego, to dostępne są tam tylko zrzuty logiczne, ponieważ Google, Amazon nie pozwalają na zrobienie fizycznej kopii. Będzie problem.

Dzięki za raport. Były tu dwa dobre pytania dotyczące MySQL i udostępniania zasobów. Ale w rzeczywistości wszystko sprowadza się do tego, że nie jest to temat konkretnego DBMS, ale systemu plików jako całości. W związku z tym kwestie współdzielenia zasobów powinny być również rozwiązywane stamtąd, nie na końcu, jak to jest w Postgresie, ale na przykład w systemie plików, na serwerze.

Moje pytanie jest trochę inne. Bliżej jej do wielowarstwowej bazy danych, gdzie jest kilka warstw. Na przykład skonfigurowaliśmy aktualizację obrazu o wielkości dziesięciu terabajtów, którą replikujemy. I specjalnie używamy tego rozwiązania do baz danych. Trwa replikacja, trwa aktualizacja danych. Równolegle pracuje 100 pracowników, którzy nieustannie odpalają te różne ujęcia. Co robić? Jak upewnić się, że nie ma konfliktu, że uruchomili jeden, a potem zmienił się system plików i wszystkie te zdjęcia poszły?

Nie pójdą, bo tak działa ZFS. Możemy przechowywać oddzielnie w jednym wątku zmiany systemu plików wynikające z replikacji. I zachowaj klony, których programiści używają na starszych wersjach danych. I to działa dla nas, wszystko jest w porządku.

Okazuje się, że aktualizacja odbędzie się jako dodatkowa warstwa, a wszystkie nowe zdjęcia już pójdą, bazując na tej warstwie, prawda?

Z poprzednich warstw, które pochodziły z poprzednich replikacji.

Poprzednie warstwy odpadną, ale będą nawiązywać do starej warstwy i czy wezmą nowe zdjęcia z ostatniej warstwy, która została odebrana w aktualizacji?

Ogólnie tak.

Wtedy w konsekwencji będziemy mieli aż figę warstw. A z czasem trzeba będzie je skompresować?

Tak, wszystko jest w porządku. Jest jakieś okno. Robimy cotygodniowe migawki. To zależy od tego, jaki masz zasób. Jeśli masz możliwość przechowywania dużej ilości danych, możesz przechowywać migawki przez długi czas. Same nie znikną. Nie będzie żadnego uszkodzenia danych. Jeśli migawki są nieaktualne, jak nam się wydaje, czyli zależy to od polityki w firmie, to możemy je po prostu usunąć i zwolnić miejsce.

Cześć, dzięki za raport! Pytanie o Joego. Powiedziałeś, że klient nie chciał dać wszystkim dostępu do danych. Ściśle mówiąc, jeśli dana osoba ma wynik analizy Wyjaśnij, może zerknąć do danych.

To jest tak. Na przykład możemy napisać: „WYBIERZ Z GDZIE e-mail = do tego”. Oznacza to, że nie zobaczymy samych danych, ale możemy zobaczyć pewne pośrednie znaki. Należy to zrozumieć. Ale z drugiej strony wszystko jest. Mamy audyt dziennika, mamy kontrolę nad innymi współpracownikami, którzy również widzą, co robią programiści. A jeśli ktoś spróbuje to zrobić, to służby bezpieczeństwa przyjdą do niego i zajmą się tym problemem.

Dzień dobry Dzięki za raport! Mam krótkie pytanie. Jeśli firma nie korzysta ze Slacka, czy jest z tym teraz jakieś powiązanie, czy też programiści mogą wdrażać instancje w celu połączenia aplikacji testowej z bazami danych?

Teraz jest link do Slacka, tzn. nie ma innego komunikatora, ale bardzo chcę wesprzeć też inne komunikatory. Co możesz zrobić? Możesz wdrożyć DB Lab bez Joe, przejść z pomocą REST API lub z pomocą naszej platformy i tworzyć klony i łączyć się z PSQL. Ale można to zrobić, jeśli jesteś gotowy dać swoim programistom dostęp do danych, ponieważ nie będzie już żadnego ekranu.

Nie potrzebuję tej warstwy, ale potrzebuję takiej możliwości.

Wtedy tak, można to zrobić.

Źródło: www.habr.com