Kiedyś w odległej przyszłości automatyczne usuwanie zbędnych danych będzie jednym z ważnych zadań SZBD [1]. W międzyczasie sami musimy zadbać o usunięcie lub przeniesienie zbędnych danych do tańszych systemów przechowywania. Załóżmy, że decydujesz się usunąć kilka milionów wierszy. Dość proste zadanie, zwłaszcza jeśli warunek jest znany i istnieje odpowiedni indeks. "DELETE FROM table1 WHERE col1 = :value" - co może być prostszego, prawda?
Video:
-
W komitecie programu Highload jestem od pierwszego roku, czyli od 2007 roku.
-
Z Postgresem jestem od 2005 roku. Używał go w wielu projektach.
-
Grupa z RuPostges również od 2007 roku.
-
Urosliśmy do ponad 2100 uczestników Meetup. Drugie miejsce na świecie po Nowym Jorku, przez długi czas wyprzedzane przez San Francisco.
-
Mieszkam w Kalifornii od kilku lat. Częściej zajmuję się firmami amerykańskimi, w tym dużymi. Są aktywnymi użytkownikami Postgres. A tam są różne ciekawe rzeczy.
jest moją firmą. Zajmujemy się automatyzacją zadań, które eliminują spowolnienia rozwojowe.
Jeśli coś robisz, to czasami są jakieś wtyczki wokół Postgres. Powiedzmy, że musisz poczekać, aż administrator ustawi dla ciebie stanowisko testowe, lub musisz poczekać, aż DBA ci odpowie. Znajdujemy takie wąskie gardła w procesie rozwoju, testowania i administracji i próbujemy je wyeliminować za pomocą automatyzacji i nowych podejść.
Byłem niedawno w VLDB w Los Angeles. To największa konferencja poświęcona bazom danych. I pojawił się raport, że w przyszłości DBMS będzie nie tylko przechowywać, ale także automatycznie usuwać dane. To jest nowy temat.
W świecie zettabajtów jest coraz więcej danych - to 1 000 000 petabajtów. A już teraz szacuje się, że na świecie zgromadzonych jest ponad 100 zettabajtów danych. A jest ich coraz więcej.
I co z tym zrobić? Wiadomo, że trzeba go usunąć. Oto link do tego ciekawego raportu. Ale jak dotąd nie zostało to zaimplementowane w DBMS.
Ci, którzy potrafią liczyć pieniądze, chcą dwóch rzeczy. Chcą, abyśmy usunęli, więc technicznie powinniśmy być w stanie to zrobić.
To, co opowiem dalej, to jakaś abstrakcyjna sytuacja zawierająca zbiór rzeczywistych sytuacji, czyli swego rodzaju zestawienie tego, co naprawdę przydarzyło się mnie i otaczającym mnie bazom wiele razy, wiele lat. Grabie są wszędzie i wszyscy cały czas na nie nadepną.
Powiedzmy, że mamy bazę lub kilka baz, które rosną. A niektóre rekordy są oczywiście śmieciami. Na przykład użytkownik zaczął coś tam robić, ale tego nie skończył. A po pewnym czasie wiemy, że tego niedokończonego nie da się już przechowywać. Oznacza to, że chcielibyśmy wyczyścić niektóre śmieci, aby zaoszczędzić miejsce, poprawić wydajność itp.
Ogólnie zadaniem jest zautomatyzowanie usuwania określonych rzeczy, określonych linii w jakiejś tabeli.
I mamy taką prośbę, o której dziś porozmawiamy, czyli o wywóz śmieci.
Poprosiliśmy o to doświadczonego programistę. Przyjął tę prośbę, sam sprawdził - wszystko działa. Testowane na inscenizacji - wszystko jest w porządku. Rozwinięte - wszystko działa. Raz dziennie uruchamiamy - wszystko jest w porządku.
Baza danych rośnie i rośnie. Daily DELETE zaczyna działać nieco wolniej.
Wtedy rozumiemy, że mamy teraz firmę marketingową i ruch będzie kilkukrotnie większy, więc postanawiamy chwilowo wstrzymać niepotrzebne rzeczy. I zapomnij wrócić.
Kilka miesięcy później przypomnieli sobie. A ten programista zrezygnował lub jest zajęty czymś innym, poinstruował innego, aby go zwrócił.
Sprawdził dev, inscenizację - wszystko jest w porządku. Oczywiście nadal musisz posprzątać to, co się nagromadziło. Sprawdził, wszystko działa.
Co się potem dzieje? Wtedy wszystko nam się wali. Spada tak, że w pewnym momencie wszystko spada. Wszyscy są w szoku, nikt nie rozumie, co się dzieje. I wtedy okazuje się, że sprawa była w tym DELETE.
Coś poszło nie tak? Oto lista tego, co mogło pójść nie tak. Który z nich jest najważniejszy?
-
Np. nie było recenzji, czyli ekspert DBA jej nie przeglądał. Wprawnym okiem od razu znalazłby problem, a poza tym ma dostęp do prod, na którym narosło kilka milionów linii.
-
Może coś źle sprawdzili.
-
Być może sprzęt jest przestarzały i musisz zaktualizować tę bazę.
-
Albo coś jest nie tak z samą bazą danych i musimy przejść z Postgres do MySQL.
-
A może coś jest nie tak z operacją.
-
Może są jakieś błędy w organizacji pracy i trzeba kogoś zwolnić i zatrudnić najlepszych?
Nie było kontroli DBA. Gdyby istniał DBA, zobaczyłby te kilka milionów linii i nawet bez żadnych eksperymentów powiedziałby: „Oni tego nie robią”. Załóżmy, że gdyby ten kod był w GitLab, GitHub i byłby proces code review i nie było czegoś takiego, że bez zgody DBA ta operacja odbyłaby się na prod, to oczywiście DBA powiedziałby: „Tego nie da się zrobić ”.
I powiedziałby, że będziesz miał problemy z dyskowym IO i wszystkie procesy będą szaleć, mogą być blokady, a także zablokujesz autovacuum na kilka minut, więc to nie jest dobre.
Drugi błąd - sprawdzili w złym miejscu. Widzieliśmy po fakcie, że na prod zgromadziło się dużo śmieciowych danych, ale programista nie zgromadził danych w tej bazie danych i nikt nie stworzył tych śmieci podczas inscenizacji. W związku z tym było 1 linii, które szybko się sprawdziły.
Rozumiemy, że nasze testy są słabe, to znaczy, że zbudowany proces nie łapie problemów. Nie przeprowadzono odpowiedniego eksperymentu DB.
Idealny eksperyment najlepiej przeprowadzić na tym samym sprzęcie. Nie zawsze da się to zrobić na tym samym sprzęcie, ale bardzo ważne jest, aby była to pełnowymiarowa kopia bazy danych. To jest to, co głoszę od kilku lat. A rok temu mówiłem o tym, można to wszystko obejrzeć na YouTube.
Może nasz sprzęt jest kiepski? Jeśli spojrzysz, to opóźnienie skoczyło. Widzieliśmy, że wykorzystanie wynosi 100%. Oczywiście, gdyby to były nowoczesne dyski NVMe, to pewnie byłoby nam o wiele łatwiej. I może nie kładlibyśmy się z tego.
Jeśli masz chmury, aktualizacja jest tam łatwa. Podniesione nowe repliki na nowym sprzęcie. przełączenie. I wszystko jest dobrze. Całkiem łatwe.
Czy można jakoś dotknąć mniejszych dysków? I tutaj, tylko z pomocą DBA, zagłębiamy się w pewien temat zwany strojeniem punktów kontrolnych. Okazuje się, że nie mieliśmy strojenia punktów kontrolnych.
Co to jest punkt kontrolny? Jest w dowolnym DBMS. Gdy w pamięci znajdują się dane, które ulegają zmianie, nie są one natychmiast zapisywane na dysku. Informacja o zmianie danych jest najpierw zapisywana w dzienniku zapisu z wyprzedzeniem. I w pewnym momencie DBMS decyduje, że nadszedł czas, aby zrzucić rzeczywiste strony na dysk, abyśmy w przypadku awarii mogli zrobić mniej REDO. To jest jak zabawka. Jeśli zginiemy, grę rozpoczniemy od ostatniego punktu kontrolnego. I wszystkie DBMS to implementują.
Ustawienia w Postgres są opóźnione. Są one przeznaczone dla wolumenów danych i transakcji sprzed 10-15 lat. Punkt kontrolny nie jest wyjątkiem.
Oto informacje z naszego raportu kontrolnego Postgres, czyli automatycznej kontroli stanu. A oto kilka terabajtów bazy danych. I dobrze widać, że w prawie 90% przypadków wymuszono punkty kontrolne.
Co to znaczy? Są tam dwa ustawienia. Punkt kontrolny może przyjść po przekroczeniu limitu czasu, na przykład za 10 minut. Lub może nadejść, gdy wypełniono dość dużo danych.
Domyślnie max_wal_saze jest ustawione na 1 gigabajt. W rzeczywistości dzieje się tak naprawdę w Postgresie po 300-400 megabajtach. Zmieniłeś tak wiele danych, że nadszedł Twój punkt kontrolny.
A jak nikt tego nie dostrajał, a serwis się rozrastał, a firma dużo zarabia, ma dużo transakcji, to punkt kontrolny pojawia się raz na minutę, czasem co 30 sekund, a czasem nawet się pokrywa. To jest całkiem złe.
I musimy zadbać o to, by zdarzało się to rzadziej. Oznacza to, że możemy podnieść max_wal_size. I będzie pojawiać się rzadziej.
Ale opracowaliśmy całą metodologię, jak to zrobić poprawniej, czyli jak podjąć decyzję o wyborze ustawień, wyraźnie opartą na konkretnych danych.
W związku z tym przeprowadzamy dwie serie eksperymentów na bazach danych.
Pierwsza seria - zmieniamy max_wal_size. I przeprowadzamy masową operację. Najpierw robimy to na domyślnym ustawieniu 1 gigabajta. I wykonujemy ogromne USUWANIE wielu milionów linii.
Sami widzicie, jak nam jest ciężko. Widzimy, że dysk IO jest bardzo zły. Patrzymy, ile wygenerowaliśmy WAL, ponieważ jest to bardzo ważne. Zobaczmy, ile razy zdarzył się punkt kontrolny. I widzimy, że nie jest dobrze.
Następnie zwiększamy max_wal_size. My powtarzamy. Zwiększamy, powtarzamy. I tak wiele razy. W zasadzie 10 punktów jest dobre, gdzie 1, 2, 4, 8 gigabajtów. I patrzymy na zachowanie konkretnego systemu. Oczywiste jest, że tutaj sprzęt powinien być jak na prod. Musisz mieć te same dyski, taką samą ilość pamięci i te same ustawienia Postgres.
I w ten sposób wymienimy nasz system i wiemy jak DBMS będzie się zachowywał w przypadku złej masy DELETE, jak będzie sprawdzał.
Punkt kontrolny w języku rosyjskim to punkty kontrolne.
Przykład: USUŃ kilka milionów wierszy według indeksu, wiersze są „rozrzucone” na stronach.
Oto przykład. To jest jakaś baza. A przy domyślnym ustawieniu 1 gigabajta dla max_wal_size jest bardzo jasne, że nasze dyski trafiają na półkę do nagrywania. Ten obraz jest typowym objawem bardzo chorego pacjenta, czyli naprawdę źle się czuł. I była jedna pojedyncza operacja, było tylko USUŃ kilka milionów linii.
Jeśli taka operacja jest dozwolona w prodzie, to po prostu się położymy, bo jasne jest, że jedno USUŃ zabija nas w pułku.
Dalej, gdzie 16 gigabajtów, jasne jest, że zęby już zniknęły. Z zębami już lepiej, czyli pukamy w sufit, ale nie jest tak źle. Była tam pewna dowolność. Po prawej stronie jest zapis. I liczba operacji - drugi wykres. I jasne jest, że oddychamy już trochę łatwiej, gdy mamy 16 gigabajtów.
A gdzie 64 gigabajty widać, że stało się zupełnie lepiej. Już zęby są wystające, są większe szanse na przeżycie innych operacji i zrobienie czegoś z dyskiem.
Dlaczego tak jest?
Zagłębię się trochę w szczegóły, ale ten temat, jak przeprowadzić tuning punktów kontrolnych, może zaowocować całym raportem, więc nie będę dużo wczytywał, ale trochę nakreślę, jakie są trudności.
Jeśli punkt kontrolny zdarza się zbyt często i aktualizujemy nasze wiersze nie po kolei, ale znajdujemy po indeksie, co jest dobre, bo nie usuwamy całej tabeli, to może się zdarzyć, że najpierw dotknęliśmy pierwszej strony, potem tysięcznej, a potem wrócił do pierwszego. A jeśli pomiędzy tymi wizytami na pierwszej stronie, checkpoint już ją zapisał na dysku, to zapisze ponownie, bo pobrudziliśmy ją po raz drugi.
I zmusimy punkt kontrolny do zapisywania go wiele razy. W jaki sposób byłyby dla niego zbędne operacje.
Ale to nie wszystko. Strony mają 8 kilobajtów w Postgresie i 4 kilobajty w Linuksie. I jest ustawienie full_page_writes. Jest domyślnie włączony. I to jest poprawne, ponieważ jeśli go wyłączymy, to istnieje niebezpieczeństwo, że w przypadku awarii zostanie uratowana tylko połowa strony.
Zachowanie zapisu do WAL dziennika przesyłania jest takie, że gdy mamy punkt kontrolny i zmieniamy stronę po raz pierwszy, cała strona, czyli całe 8 kilobajtów, trafia do dziennika przesyłania, chociaż zmieniliśmy tylko line, która waży 100 bajtów. I musimy spisać całą stronę.
W kolejnych zmianach będzie tylko konkretna krotka, ale po raz pierwszy zapisujemy wszystko.
I odpowiednio, jeśli punkt kontrolny powtórzył się, musimy zacząć wszystko od nowa i przepchnąć całą stronę. Przy częstych punktach kontrolnych, kiedy przechodzimy przez te same strony, full_page_writes = on będzie więcej niż mogłoby być, czyli generujemy więcej WAL. Więcej trafia do replik, do archiwum, na dysk.
W związku z tym mamy dwa zwolnienia.
Jeśli zwiększymy max_wal_size, okaże się, że ułatwiamy pracę zarówno dla punktu kontrolnego, jak i dla autora wal. I to jest świetne.
Włóżmy terabajt i żyjmy z tym. Co w tym złego? To źle, bo w razie awarii będziemy się wspinać godzinami, bo punkt kontrolny był dawno temu i sporo się już zmieniło. I musimy zrobić to wszystko PONOWNIE. I tak robimy drugą serię eksperymentów.
Robimy operację i widzimy, kiedy punkt kontrolny ma się zakończyć, celowo zabijamy -9 Postgres.
A potem zaczynamy od nowa i zobaczymy jak długo będzie rósł na tym sprzęcie, czyli ile PONOWNIE zrobi w tej złej sytuacji.
Dwukrotnie zaznaczę, że sytuacja jest zła. Po pierwsze, rozbiliśmy się tuż przed zakończeniem punktu kontrolnego, więc mamy dużo do stracenia. A po drugie, mieliśmy ogromną operację. A jeśli punkty kontrolne przekroczyłyby limit czasu, najprawdopodobniej od ostatniego punktu kontrolnego wygenerowano by mniej WAL. Oznacza to, że jest to podwójny przegrany.
Mierzymy taką sytuację dla różnych rozmiarów max_wal_size i rozumiemy, że jeśli max_wal_size wynosi 64 gigabajty, to w podwójnym najgorszym przypadku będziemy się wspinać przez 10 minut. I zastanawiamy się, czy nam to pasuje, czy nie. To jest pytanie biznesowe. Musimy pokazać ten obraz osobom odpowiedzialnym za decyzje biznesowe i zapytać: „Jak długo możemy maksymalnie leżeć w razie problemu? Czy w najgorszej sytuacji możemy położyć się na 3-5 minut? I podejmujesz decyzję.
I tu jest ciekawy punkt. Mamy kilka doniesień o Patroni na konferencji. A może go używasz. To jest automatyczne przełączanie awaryjne dla Postgres. Mówiły o tym GitLab i Data Egret.
A jeśli masz autofailover, który następuje w 30 sekund, to może możemy położyć się na 10 minut? Ponieważ w tym momencie przełączymy się na replikę i wszystko będzie dobrze. To jest kwestia sporna. Nie znam jasnej odpowiedzi. Po prostu czuję, że ten temat dotyczy nie tylko odzyskiwania po awarii.
Jeśli mamy długą rekonwalescencję po porażce, to w wielu innych sytuacjach będziemy czuli się nieswojo. Na przykład w tych samych eksperymentach, kiedy coś robimy i czasami musimy czekać 10 minut.
Nadal nie posunąłbym się za daleko, nawet jeśli mamy automatyczne przełączanie awaryjne. Z reguły wartości takie jak 64, 100 gigabajtów są dobrymi wartościami. Czasami warto nawet wybrać mniej. Ogólnie rzecz biorąc, jest to subtelna nauka.
Aby wykonać iteracje, na przykład max_wal_size =1, 8, musisz powtórzyć operację masową wiele razy. Zrobiłeś to. I na tej samej bazie chcesz to zrobić jeszcze raz, ale już wszystko usunąłeś. Co robić?
Później opowiem o naszym rozwiązaniu, o tym, co robimy, aby iterować w takich sytuacjach. I to jest najbardziej poprawne podejście.
Ale w tym przypadku mieliśmy szczęście. Jeśli, jak mówi tutaj „BEGIN, DELETE, COFNIJ”, możemy powtórzyć DELETE. Oznacza to, że jeśli sami to anulowaliśmy, możemy to powtórzyć. I fizycznie u ciebie dane będą leżeć w tym samym miejscu. Nawet nie masz wzdęć. Możesz iterować po takich DELETE.
To DELETE z ROLLBACK jest idealne do dostrajania punktów kontrolnych, nawet jeśli nie masz odpowiednio wdrożonych laboratoriów baz danych.
Zrobiliśmy tabliczkę z jedną kolumną „i”. Postgres ma kolumny narzędziowe. Są niewidoczne, chyba że wyraźnie o to poproszą. Są to: ctid, xmid, xmax.
Ctid to adres fizyczny. Strona zerowa, pierwsza krotka na stronie.
Widać, że po ROOLBACK krotka pozostała w tym samym miejscu. Oznacza to, że możemy spróbować ponownie, będzie zachowywać się w ten sam sposób. To jest najważniejsze.
Xmax to czas śmierci krotki. Został ostemplowany, ale Postgres wie, że transakcja została wycofana, więc nie ma znaczenia, czy jest to 0, czy jest to wycofana transakcja. Sugeruje to, że możliwe jest iterowanie po DELETE i sprawdzanie zbiorczych operacji zachowania systemu. Możesz tworzyć laboratoria baz danych dla biednych.
Tu chodzi o programistów. Również w przypadku DBA zawsze karcą programistów za to: „Dlaczego wykonujecie takie długie i trudne operacje?”. To zupełnie inny temat prostopadły. Kiedyś była administracja, teraz będzie rozwój.
Oczywiście nie rozpadliśmy się na kawałki. Jest jasne. Nie sposób nie rozbić takiego DELETE na stos milionów linii na części. Będzie to zrobione przez 20 minut i wszystko się położy. Ale niestety nawet doświadczeni programiści popełniają błędy, nawet w bardzo dużych firmach.
Dlaczego ważne jest, aby się złamać?
-
Jeśli widzimy, że dysk jest twardy, zwolnijmy go. A jeśli jesteśmy zepsuci, możemy dodać przerwy, możemy spowolnić dławienie.
-
I długo nie będziemy blokować innych. W niektórych przypadkach nie ma to znaczenia, jeśli usuwasz prawdziwe śmieci, z którymi nikt nie pracuje, najprawdopodobniej nie zablokujesz nikogo oprócz pracy autovacuum, ponieważ będzie czekać na zakończenie transakcji. Ale jeśli usuniesz coś, o co ktoś inny może poprosić, zostanie on zablokowany, nastąpi swego rodzaju reakcja łańcuchowa. Należy unikać długich transakcji na stronach internetowych i w aplikacjach mobilnych.
To jest interesujące. Często widzę, że programiści pytają: „Jaki rozmiar pakietu powinienem wybrać?”.
Oczywiste jest, że im większy rozmiar pakietu, tym mniejszy narzut transakcyjny, tj. dodatkowy narzut związany z transakcjami. Ale jednocześnie wydłuża się czas tej transakcji.
Mam bardzo prostą zasadę: bierz tyle, ile możesz, ale nie przekraczaj liczby plików wykonywalnych na sekundę.
Dlaczego sekunda? Wyjaśnienie jest bardzo proste i zrozumiałe dla każdego, nawet dla osób nietechnicznych. Widzimy reakcję. Weźmy 50 milisekund. Jeśli coś się zmieniło, nasze oko zareaguje. Jeśli mniej, to trudniej. Jeśli coś odpowiada po 100 milisekundach, na przykład kliknąłeś myszką, a odpowiedziało ci po 100 milisekundach, już czujesz to niewielkie opóźnienie. Sekunda jest już postrzegana jako hamulce.
W związku z tym, jeśli podzielimy nasze operacje masowe na 10-sekundowe serie, istnieje ryzyko, że kogoś zablokujemy. I będzie działać przez kilka sekund, a ludzie już to zauważą. Dlatego wolę nie robić więcej niż sekundę. Ale jednocześnie nie dziel tego bardzo dokładnie, ponieważ koszty ogólne transakcji będą zauważalne. Baza będzie twardsza i mogą pojawić się inne problemy.
Wybieramy wielkość paczki. W każdym przypadku możemy to zrobić inaczej. Może być zautomatyzowany. I jesteśmy przekonani o skuteczności przetwarzania jednej paczki. Oznacza to, że wykonujemy USUWANIE jednego pakietu lub AKTUALIZACJĘ.
Nawiasem mówiąc, wszystko, o czym mówię, dotyczy nie tylko USUWANIA. Jak się domyślacie, są to wszelkie masowe operacje na danych.
I widzimy, że plan jest doskonały. Możesz zobaczyć skanowanie indeksu, skanowanie tylko indeksu jest jeszcze lepsze. I mamy do czynienia z niewielką ilością danych. I mniej niż sekunda się spełnia. Super.
I nadal musimy upewnić się, że nie ma degradacji. Bywa, że pierwsze opakowania szybko się sprawdzają, a potem jest coraz gorzej. Proces jest taki, że trzeba dużo testować. Właśnie do tego służą laboratoria baz danych.
I jeszcze musimy coś przygotować, żeby to pozwoliło nam poprawnie podążać za tym w produkcji. Na przykład możemy zapisać czas w dzienniku, możemy napisać, gdzie teraz jesteśmy i kogo teraz usunęliśmy. A to pozwoli nam zrozumieć, co dzieje się później. A jeśli coś pójdzie nie tak, szybko znajdź problem.
Jeśli musimy sprawdzić skuteczność żądań i musimy wielokrotnie iterować, to istnieje coś takiego jak bot kolega. Jest już gotowy. Jest używany codziennie przez dziesiątki programistów. I wie, jak w 30 sekund oddać na żądanie ogromną terabajtową bazę danych, własną kopię. I możesz tam coś usunąć i powiedzieć RESET, i usunąć to ponownie. Możesz w ten sposób poeksperymentować. Widzę przyszłość dla tego czegoś. I już to robimy.
Czym są strategie partycjonowania? Widzę 3 różne strategie partycjonowania, których używają programiści pakietu.
Pierwsza jest bardzo prosta. Mamy identyfikator numeryczny. Podzielmy to na różne interwały i pracujmy z tym. Wada jest jasna. W pierwszym segmencie możemy mieć 100 linii prawdziwych śmieci, w drugim 5 linii lub wcale, albo wszystkie 1 linii okaże się śmieciami. Bardzo nierówna praca, ale łatwo ją złamać. Wzięli maksymalny identyfikator i rozbili go. To naiwne podejście.
Druga strategia to zrównoważone podejście. Jest używany w Gitlabie. Wzięli i przejrzeli stół. Znaleźliśmy granice pakietów identyfikatorów, tak aby każdy pakiet miał dokładnie 10 000 rekordów. I ustaw je w kolejce. A potem przetwarzamy. Możesz to zrobić w wielu wątkach.
Nawiasem mówiąc, również w pierwszej strategii możesz to zrobić w kilku wątkach. To nie jest trudne.
Ale jest fajniejsze i lepsze podejście. To jest trzecia strategia. A jeśli to możliwe, lepiej go wybrać. Robimy to na podstawie specjalnego indeksu. W tym przypadku najprawdopodobniej będzie to indeks zgodny z naszym stanem śmieci i identyfikatorem. Dołączymy identyfikator, aby był to skan tylko indeksu, abyśmy nie przechodzili do sterty.
Ogólnie skanowanie samego indeksu jest szybsze niż skanowanie indeksu.
I szybko znajdujemy nasze identyfikatory, które chcemy usunąć. BATCH_SIZE wybieramy z góry. I nie tylko je zdobywamy, ale zdobywamy je w specjalny sposób i natychmiast je hakujemy. Ale blokujemy tak, że jeśli już są zablokowane, to ich nie zamykamy, tylko przechodzimy dalej i bierzemy kolejne. To jest dla zablokowanego pominięcia aktualizacji. Ta super funkcja Postgresa pozwala nam pracować w kilku wątkach, jeśli chcemy. Jest to możliwe w jednym strumieniu. I tutaj jest CTE - to jest jedna prośba. I mamy prawdziwe usunięcie na drugim piętrze tego CTE - returning *. Możesz zwrócić identyfikator, ale tak jest lepiej *jeśli nie masz dużo danych w każdej linii.
Dlaczego tego potrzebujemy? To jest to, co musimy zgłosić z powrotem. W rzeczywistości usunęliśmy teraz tak wiele linii. I mamy granice według ID lub created_at w ten sposób. Możesz zrobić min, max. Można zrobić coś innego. Można tu dużo upchać. I jest bardzo wygodny do monitorowania.
Jest jeszcze jedna uwaga dotycząca indeksu. Jeśli uznamy, że do tego zadania potrzebny jest specjalny indeks, to musimy się upewnić, że nie psuje on aktualizacji sterty tylko krotek. Czyli Postgres ma takie statystyki. Można to zobaczyć w pg_stat_user_tables dla twojej tabeli. Możesz sprawdzić, czy używane są gorące aktualizacje, czy nie.
Są sytuacje, w których nowy indeks może je po prostu odciąć. I masz wszystkie inne aktualizacje, które już działają, zwolnij. Nie tylko dlatego, że pojawił się indeks (każdy indeks trochę spowalnia aktualizacje, ale trochę), ale tutaj i tak go rujnuje. I niemożliwe jest wykonanie specjalnej optymalizacji dla tej tabeli. To się czasami zdarza. To taka subtelność, o której niewiele osób pamięta. A te grabie są łatwe do nadepnięcia. Czasami zdarza się, że musisz znaleźć podejście z drugiej strony i nadal obejść się bez tego nowego indeksu, lub zrobić inny indeks, lub w inny sposób, na przykład, możesz użyć drugiej metody.
Ale to jest najbardziej optymalna strategia, jak podzielić na partie i strzelać do partii z jednym żądaniem, usunąć trochę itp.
Długie transakcje
Zablokowane automatyczne odkurzanie -
problem z blokowaniem -
Błąd nr 5 jest duży. Nikolai z Okmeter mówił o monitorowaniu Postgres. Idealny monitoring Postgres niestety nie istnieje. Niektóre są bliżej, niektóre dalej. Okmeter jest wystarczająco blisko ideału, ale brakuje wielu rzeczy i trzeba je dodać. Musisz być na to gotowy.
Na przykład najlepiej monitorować martwe krotki. Jeśli masz dużo martwych rzeczy na stole, coś jest nie tak. Lepiej zareagować już teraz, inaczej może dojść do degradacji i możemy się położyć. Zdarza się.
Jeśli istnieje duże IO, jasne jest, że nie jest to dobre.
Długie transakcje też. Długie transakcje nie powinny być dozwolone w OLTP. A oto link do fragmentu, który pozwala wziąć ten fragment i już śledzić długie transakcje.
Dlaczego długie transakcje są złe? Ponieważ wszystkie zamki zostaną zwolnione dopiero na końcu. I pieprzymy wszystkich. Dodatkowo blokujemy automatyczne odkurzanie dla wszystkich stołów. Wcale nie jest dobrze. Nawet jeśli masz włączoną funkcję gorącej gotowości w replice, nadal jest źle. Generalnie nigdzie nie lepiej unikać długich transakcji.
Jeśli mamy wiele stołów, które nie są odkurzane, musimy mieć alert. Tutaj taka sytuacja jest możliwa. Możemy pośrednio wpływać na działanie autopróżni. To fragment z Avito, który nieco poprawiłem. I okazało się, że jest to ciekawe narzędzie, aby zobaczyć, co mamy z autovacuum. Na przykład niektóre stoły czekają tam i nie będą czekać na swoją kolej. Trzeba też umieścić go w monitoringu i mieć alert.
I wydaje bloki. Las drzew blokowych. Lubię coś od kogoś wziąć i udoskonalić. Tutaj wziąłem fajny rekurencyjny CTE z Data Egret, który pokazuje las drzew śluz. To dobre narzędzie diagnostyczne. A na jego podstawie można też zbudować monitoring. Ale należy to zrobić ostrożnie. Musisz zrobić dla siebie mały statement_timeout. A lock_timeout jest pożądany.
Czasami wszystkie te błędy występują łącznie.
Moim zdaniem główny błąd jest tutaj organizacyjny. Jest organizacyjny, bo technika nie ciągnie. To jest numer 2 - sprawdzili w złym miejscu.
Sprawdziliśmy w złym miejscu, bo nie mieliśmy produkcyjnego klona, na którym łatwo sprawdzić. Deweloper może w ogóle nie mieć dostępu do środowiska produkcyjnego.
I sprawdziliśmy, że nie ma. Gdybyśmy tam zajrzeli, sami byśmy to zobaczyli. Deweloper widział to wszystko nawet bez DBA, jeśli sprawdził to w dobrym środowisku, gdzie jest ta sama ilość danych i identyczna lokalizacja. Zobaczyłby całą tę degradację i wstydziłby się.
Więcej o automatycznej próżni. Po przeprowadzeniu ogromnego przeglądu kilku milionów linii nadal musimy wykonać REPACK. Jest to szczególnie ważne w przypadku indeksów. Poczują się źle, gdy wszystko tam posprzątamy.
A jeśli chcesz przywrócić codzienne sprzątanie, to sugerowałbym robić to częściej, ale w mniejszych ilościach. Może to być raz na minutę lub nawet częściej trochę. I musisz monitorować dwie rzeczy: aby ta rzecz nie miała błędów i aby nie pozostawała w tyle. Sztuczka, którą pokazałem, rozwiąże ten problem.
To, co robimy, jest open source. Jest opublikowany na GitLabie. I robimy to tak, aby ludzie mogli sprawdzać nawet bez DBA. Robimy laboratorium bazy danych, czyli nazywamy komponent bazowy, nad którym aktualnie pracuje Joe. I możesz pobrać kopię produkcji. Teraz jest implementacja Joe dla luzu, możesz tam powiedzieć: „wyjaśnij taką a taką prośbę” i natychmiast uzyskaj wynik dla swojej kopii bazy danych. Możesz tam nawet USUNĄĆ i nikt tego nie zauważy.
Powiedzmy, że masz 10 terabajtów, my tworzymy laboratorium bazy danych również 10 terabajtów. A dzięki równoczesnym bazom danych o pojemności 10 terabajtów, 10 programistów może pracować jednocześnie. Każdy może robić, co chce. Może usuwać, upuszczać itp. To taka fantazja. Porozmawiamy o tym jutro.
Nazywa się to cienkim udostępnianiem. To subtelne zaopatrzenie. Jest to pewnego rodzaju fantazja, która znacznie usuwa opóźnienia w rozwoju, testowaniu i czyni świat lepszym miejscem pod tym względem. Oznacza to, że po prostu pozwala uniknąć problemów z operacjami masowymi.
Przykład: baza danych o pojemności 5 terabajtów, uzyskanie kopii w mniej niż 30 sekund. I to nawet nie zależy od rozmiaru, to znaczy nie ma znaczenia, ile terabajtów.
Dziś możesz iść do i zagłębić się w nasze narzędzia. Możesz się zarejestrować, aby zobaczyć, co tam jest. Możesz zainstalować tego bota. Jest wolne. Pisać.
pytania
Bardzo często w rzeczywistych sytuacjach okazuje się, że danych, które powinny pozostać w tabeli, jest znacznie mniej niż to, co trzeba usunąć. Oznacza to, że w takiej sytuacji często łatwiej jest wdrożyć takie podejście, gdy łatwiej jest stworzyć nowy obiekt, skopiować tam tylko niezbędne dane i trunkingować starą tabelę. Oczywiste jest, że w tej chwili potrzebne jest podejście programowe, podczas gdy będziesz się zmieniać. Jak wygląda to podejście?
To bardzo dobre podejście i bardzo dobre zadanie. Jest bardzo podobny do tego, co robi pg_repack, jest bardzo podobny do tego, co musisz zrobić, gdy tworzysz identyfikatory 4 bajty. Wiele frameworków zrobiło to kilka lat temu i tylko płyty urosły i trzeba je przekonwertować na 8 bajtów.
To zadanie jest dość trudne. Zrobiliśmy to. I trzeba bardzo uważać. Są zamki itp. Ale to się robi. Oznacza to, że standardowym podejściem jest użycie pg_repack. Deklarujesz taką etykietę. A zanim zaczniesz przesyłać do niego dane migawki, deklarujesz również jedną tablicę, która śledzi wszystkie zmiany. Istnieje sztuczka, dzięki której możesz nawet nie śledzić niektórych zmian. Są subtelności. A potem przełączasz się, wprowadzając zmiany. Nastąpi krótka przerwa, kiedy zamkniemy wszystkich, ale generalnie tak się dzieje.
Jeśli spojrzysz na pg_repack na GitHub, to tam, kiedy było zadanie konwersji identyfikatora z int 4 na int 8, pojawił się pomysł, aby użyć samego pg_repack. Jest to również możliwe, ale jest to trochę hack, ale zadziała również w tym przypadku. Możesz interweniować w wyzwalacz, którego używa pg_repack i powiedzieć tam: „Nie potrzebujemy tych danych”, czyli przesyłamy tylko to, czego potrzebujemy. A potem po prostu się zmienia i tyle.
Przy takim podejściu nadal otrzymujemy drugą kopię tabeli, w której dane są już poindeksowane i bardzo równo ułożone z pięknymi indeksami.
Wzdęcia nie występują, to dobre podejście. Ale wiem, że są próby opracowania do tego automatyzacji, czyli rozwiązania uniwersalnego. Mogę cię skontaktować z tą automatyzacją. Jest napisany w Pythonie, co jest dobrą rzeczą.
Jestem tylko trochę ze świata MySQL, więc przyszedłem posłuchać. I my stosujemy to podejście.
Ale to tylko wtedy, gdy mamy 90%. Jeśli mamy 5%, to niezbyt dobrze jest z niego korzystać.
Dzięki za raport! Jeśli nie ma zasobów, aby wykonać pełną kopię prod, czy istnieje jakiś algorytm lub formuła do obliczenia obciążenia lub rozmiaru?
Dobre pytanie. Jak dotąd jesteśmy w stanie znaleźć wieloterabajtowe bazy danych. Nawet jeśli sprzęt nie jest taki sam, na przykład mniej pamięci, mniej procesora i dyski nie są dokładnie takie same, ale nadal to robimy. Jeśli nie ma absolutnie nigdzie, musisz pomyśleć. Daj mi pomyśleć do jutra, przyszedłeś, porozmawiamy, to jest dobre pytanie.
Dzięki za raport! Zacząłeś od tego, że jest fajny Postgres, który ma takie a takie ograniczenia, ale się rozwija. I to wszystko jest w dużej mierze kulą. Czy to wszystko nie stoi w sprzeczności z rozwojem samego Postgresa, w którym pojawi się jakiś deferent DELETE lub coś innego, co powinno utrzymywać na niskim poziomie to, co próbujemy rozmazać niektórymi z naszych dziwnych środków tutaj?
Jeśli powiedzieliśmy w SQL, aby usuwać lub aktualizować wiele rekordów w jednej transakcji, to w jaki sposób Postgres może je tam rozpowszechniać? Jesteśmy fizycznie ograniczeni w działaniu. Jeszcze długo będziemy to robić. I zamkniemy w tym czasie itp.
Gotowe z indeksami.
Mogę założyć, że to samo dostrajanie punktów kontrolnych można zautomatyzować. Kiedyś może być. Ale w takim razie nie bardzo rozumiem pytanie.
Pytanie brzmi, czy istnieje taki wektor rozwoju, który idzie tu i tam, a tutaj twój idzie równolegle? Te. Czy oni jeszcze o tym nie myśleli?
Mówiłem o zasadach, które można stosować teraz. Jest jeszcze jeden bot , dzięki temu możesz wykonać automatyczne dostrajanie punktów kontrolnych. Czy kiedyś będzie w Postgresie? Nie wiem, jeszcze o tym nie dyskutowano. Daleko nam jeszcze do tego. Ale są naukowcy, którzy tworzą nowe systemy. I wpychają nas w automatyczne indeksy. Są zmiany. Na przykład możesz spojrzeć na automatyczne dostrajanie. Automatycznie dobiera parametry. Ale nie zrobi jeszcze dla ciebie strojenia punktów kontrolnych. Oznacza to, że podniesie wydajność, bufor powłoki itp.
A jeśli chodzi o strojenie punktu kontrolnego, możesz to zrobić: jeśli masz tysiąc klastrów i inny sprzęt, różne maszyny wirtualne w chmurze, możesz użyć naszego bota robić automatykę. A max_wal_size zostanie automatycznie wybrany zgodnie z twoimi ustawieniami docelowymi. Ale jak dotąd nie jest to nawet bliskie w rdzeniu, niestety.
Dzień dobry Mówił pan o niebezpieczeństwach długich transakcji. Powiedziałeś, że autopróżnia jest blokowana w przypadku usunięcia. Jak jeszcze nam szkodzi? Ponieważ mówimy bardziej o zwolnieniu miejsca i możliwości jego wykorzystania. Czego jeszcze nam brakuje?
Autovacuum może nie jest tutaj największym problemem. A fakt, że długa transakcja może zablokować inne transakcje, ta możliwość jest bardziej niebezpieczna. Może się spotkać lub nie. Jeśli się spotka, może być bardzo źle. A z autovacuum - to też jest problem. Istnieją dwa problemy z długimi transakcjami w OLTP: blokady i autopróżnia. A jeśli masz włączone sprzężenie zwrotne w trybie gotowości w replice, nadal będziesz otrzymywać automatyczną blokadę próżniową na urządzeniu głównym, nadejdzie z repliki. Ale przynajmniej nie będzie żadnych zamków. I będą lokacje. Mówimy o zmianach danych, więc blokady są tutaj ważnym punktem. A jeśli to wszystko trwa bardzo, bardzo długo, to coraz więcej transakcji jest blokowanych. Mogą ukraść innych. I pojawiają się drzewa lok. Podałem link do fragmentu. I ten problem staje się bardziej zauważalny szybciej niż problem z autopróżnią, która może się tylko kumulować.
Dzięki za raport! Rozpocząłeś swoje zgłoszenie od stwierdzenia, że wykonałeś niepoprawny test. Kontynuowaliśmy nasz pomysł, że musimy zabrać ten sam sprzęt, z bazą w ten sam sposób. Powiedzmy, że daliśmy deweloperowi bazę. I spełnił prośbę. I wydaje się, że ma się dobrze. Ale on nie sprawdza na żywo, ale na przykład na żywo mamy obciążenie 60-70%. I nawet jeśli użyjemy tego strojenia, nie działa to zbyt dobrze.
Ważne jest posiadanie eksperta w zespole i korzystanie z ekspertów DBA, którzy potrafią przewidzieć, co stanie się z rzeczywistym obciążeniem w tle. Kiedy właśnie wprowadziliśmy nasze czyste zmiany, widzimy obraz. Ale bardziej zaawansowane podejście, kiedy zrobiliśmy to samo ponownie, ale z obciążeniem symulowanym z produkcją. To całkiem fajne. Do tego czasu musisz dorosnąć. To jak dorosły. Po prostu spojrzeliśmy na to, co mamy, a także na to, czy mamy wystarczające zasoby. To dobre pytanie.
Gdy robimy już śmieciowy wybór i mamy np. usuniętą flagę
To właśnie autovacuum robi automatycznie w Postgresie.
Och, czy on to robi?
Autovacuum jest śmieciarzem.
Dziękuję!
Dzięki za raport! Czy istnieje opcja natychmiastowego zaprojektowania bazy danych z partycjonowaniem w taki sposób, aby wszystkie śmieci zabrudziły się z głównej tabeli gdzieś z boku?
Oczywiście mieć.
Czy w takim razie można się zabezpieczyć, jeśli zablokowaliśmy stolik, z którego nie należy korzystać?
Oczywiście, że mam. Ale to jak pytanie o jajko i kurę. Jeśli wszyscy wiemy, co wydarzy się w przyszłości, to oczywiście zrobimy wszystko fajnie. Ale biznes się zmienia, są nowe kolumny, nowe żądania. A potem – ups, chcemy to usunąć. Ale ta idealna sytuacja w życiu się zdarza, ale nie zawsze. Ale ogólnie to dobry pomysł. Wystarczy skrócić i już.
Źródło: www.habr.com