Cassandra generuje nagrobki po usunięciu danych. W niektórych okolicznościach nadmiar nagrobków może powodować długie pauzy GC, opóźnienia, błędy odczytu lub błędy sterty. Ten artykuł zawiera porady dotyczące zarządzania nagrobkami.

spis treści

co to jest nagrobek?

w Cassandrze usunięte DANE nie są natychmiast usuwane z dysku. Zamiast tego Cassandra zapisuje specjalną wartość, znaną jako nagrobek, aby wskazać, że dane zostały usunięte. Nagrobki zapobiegają zwracaniu usuniętych danych podczas odczytu i ostatecznie pozwalają na upuszczenie danych poprzez zagęszczenie.

płyty nagrobne są zapisywane – przechodzą przez normalną ścieżkę zapisu, zajmują miejsce na dysku i wykorzystują mechanizmy spójności Kasandry. Nagrobki mogą być propagowane w całej gromadzie poprzez podpowiedzi i naprawy. Jeśli klaster jest prawidłowo zarządzany, zapewnia to, że dane pozostaną usunięte, nawet jeśli węzeł jest wyłączony po wydaniu usunięcia.

nagrobki są generowane przez:

• Usuń polecenia
• ustawienie TTLs
• Wstawianie wartości null
• wstawianie danych do części kolekcji.

jaki jest normalny cykl życia nagrobków?

nagrobki są pisane ze znacznikiem czasu. W idealnych okolicznościach nagrobki (i związane z nimi dane) zostaną upuszczone podczas zagęszczania po upływie pewnego czasu.

aby nagrobki mogły zostać usunięte, muszą być spełnione następujące trzy kryteria:

• nagrobki powstały ponad gc_grace_seconds ago.
• tablica zawierająca nagrobek bierze udział w zagęszczeniu.
• wszystkie sstables, które mogą zawierać odpowiednie dane, są zaangażowane w zagęszczanie.

każda tabela ma ustawienie gc_grace_seconds. Domyślnie jest to 864000, co odpowiada 10 dni. Intencją jest zapewnienie czasu klastrowi na osiągnięcie spójności poprzez naprawy (a tym samym zapobieganie przywracaniu usuniętych danych).

nagrobki zostaną upuszczone przez zagęszczanie tylko wtedy, gdy wszystkie sstables, które mogą zawierać odpowiednie dane, są zaangażowane w zagęszczanie. Jeśli upłynęło dużo czasu między zapisaniem oryginalnych danych a wydaniem DELETE, staje się to mniej prawdopodobne:

• Wielowarstwowa Strategia zagęszczania skompaktuje sstables o podobnym rozmiarze. Dane mają tendencję do przenoszenia się do większych sstables w miarę starzenia się, więc nagrobek (w nowym, małym sstable) jest mało prawdopodobne, aby być zagęszczony z danymi (w starym, dużym sstable).
• wyrównana Strategia zagęszczania jest podzielona na wiele poziomów, które są zagęszczane oddzielnie. Nagrobek zostanie zapisany na poziomie 0 i będzie skutecznie „gonił” dane przez poziomy – powinien w końcu nadrobić zaległości.
• Strategia zagęszczania w oknie czasowym (lub Strategia zagęszczania z datą) nigdy nie zmaksymalizuje nagrobka z danymi, jeśli są one zapisane w różnych oknach czasowych.

kiedy nagrobki powodują problemy?

wykorzystanie dysku

gdy dane zostaną usunięte, przestrzeń nie zostanie zwolniona przynajmniej przez okres gc_grace ustawiony w Ustawieniach tabeli. Może to powodować problemy, jeśli klaster szybko się zapełnia.

w pewnych okolicznościach przestrzeń nigdy nie zostanie uwolniona bez ręcznej interwencji.

Czytaj wydajność

poważne problemy z wydajnością mogą wystąpić, jeśli czyta się dużą liczbę nagrobków.

problemy z wydajnością najczęściej występują w przypadku następujących typów zapytań:

• zapytania, które działają na wszystkich partycjach w tabeli („select * from keyspace.tabela”)
• zapytania zakresu („select * from keyspace.table WHERE value > x”, or „WHERE value IN (value1, value2,…)”
• każde zapytanie, które można uruchomić tylko z klauzulą „Zezwól na filtrowanie”.

problemy te występują z powodu zachowania się nagrobków podczas czytania. W zapytaniu range sterownik Cassandra zwykle używa stronicowania, co pozwala węzłom zwracać ograniczoną liczbę odpowiedzi naraz. Gdy w grę wchodzą nagrobki Cassandry, węzeł musi zachować w pamięci napotkane nagrobki i zwrócić je koordynatorowi, na wypadek gdyby jedna z pozostałych replik nie wiedziała, że odpowiednie dane zostały usunięte. Nagrobki nie mogą być przywoływane, ponieważ konieczne jest zwrócenie wszystkich z nich, więc opóźnienie i wykorzystanie pamięci zwiększają się proporcjonalnie do liczby napotkanych nagrobków.

to, czy nagrobki zostaną napotkane, zależy od sposobu przechowywania i pobierania danych. Na przykład, jeśli Cassandra jest używana do przechowywania danych w kolejce (co nie jest zalecane), zapytania mogą napotkać dziesiątki tysięcy nagrobków, aby zwrócić kilka wierszy danych.

Jak zdiagnozować problemy związane z nagrobkiem?

zapytania, które napotkają dużą liczbę nagrobków pojawią się w logach. Domyślnie odczyt ponad tysiąca nagrobków wygeneruje Ostrzeżenie:

WARN org.Apacz.cassandra.db.ReadCommand przeczytaj 0 żywych wierszy i 87051 komórek nagrobka dla zapytania wybierz * z przykładu.table

domyślnie napotkanie więcej niż 100 000 nagrobków spowoduje, że zapytanie nie powiedzie się z wyjątkiem TombstoneOverwhelmingException.

aby sprawdzić, czy odczyty tombstone powodują problemy z wydajnością, sprawdź, czy odczyty korelują ze wzrostem opóźnienia odczytu i czasu przerwy GC.

Jeśli jest jasne, że nagrobki są problemem, następujące techniki mogą pomóc zawęzić zakres problemu:

• liczba nagrobków zwróconych w danym zapytaniu można znaleźć, uruchamiając zapytanie w cqlsh z włączonym śledzeniem.
• statystyki dotyczące liczby nagrobków napotkanych ostatnio w każdej tabeli są dostępne w wyjściu znodetool cfstats.
• dla klastrów w naszej zarządzanej usłudze statystyki dla Ostatnio napotkanych nagrobków są dostępne na stronie klastra w listach metryk> informacje o tabeli. Obejmuje To żywe komórki na odczyt oraz średnie i maksymalne nagrobki na odczyt, w podziale na węzeł lub tabelę dla danego okresu czasu.
• bardziej szczegółowe informacje na temat przechowywanych nagrobków można znaleźć za pomocą ic-tools.

jak uniknąć problemów z nagrobkami?

następujące opcje mogą pomóc:

• unikaj zapytań, które będą uruchamiane na wszystkich partycjach w tabeli (np. zapytania bez klauzuli WHERE lub jakiekolwiek zapytanie wymagające filtrowania ALLOW).
• zmienia zapytania zakresu, aby uniknąć zapytań o usunięte DANE lub działa na węższym zakresie danych. Problemy z wydajnością występują tylko wtedy, gdy nagrobki są odczytywane i skaluj z liczbą odczytanych nagrobków.
• Zaprojektuj model danych, aby uniknąć usuwania dużych ilości danych.
• jeśli planujesz usunąć wszystkie dane w tabeli, obcinaj lub upuść tabelę, aby usunąć wszystkie dane bez generowania nagrobków.
• używa domyślnej wartości czasu życia. Działa to efektywnie tylko wtedy, gdy klucz główny Twoich danych jest oparty na czasie, Twoje dane są zapisane w porządku chronologicznym, a dane zostaną usunięte w znanym terminie. Aby to zrobić, Ustaw domyślny TTL w opcjach na poziomie tabeli i ustaw strategię zagęszczania opartą na czasie (TimeWindowCompactionStrategy, jeśli jest dostępna, DateTieredCompactionStrategy w przeciwnym razie). To nadal będzie tworzyć nagrobki, ale całe sstables będą skutecznie upuszczane po TTL na całej ich zawartości przeszły.

Jak pozbyć się istniejących nagrobków?

w większości przypadków najlepszym podejściem jest oczekiwanie na normalne zagęszczenie nagrobka. Jeśli pilne problemy z wydajnością lub użytkowaniem dysku wymagają bardziej natychmiastowego działania, istnieją dwie komendy nodetool, które mogą zostać użyte do wymuszenia zagęszczenia, co może pomóc w upuszczeniu nagrobków. Należy je uznać za ostateczność – w zdrowym klastrze z dobrze zaprojektowanym modelem danych nie ma potrzeby ręcznego zagęszczania.

uruchomienie nodetool compact wymusza zagęszczenie wszystkich sstables. Wymaga to dużej ilości wolnego miejsca na dysku. Argumenty Keyspace i table powinny być używane w celu ograniczenia zagęszczania do tabel, w których problemem są nagrobki. W tabelach, w których stosowana jest strategia zagęszczania warstw wielkości, polecenie to może doprowadzić do utworzenia jednego ogromnego sstable, który nigdy nie będzie miał rówieśników do zagęszczenia; jeśli dostępna jest flaga–split-output, należy jej użyć.

polecenie nodetool garbagecollect jest dostępne od wersji Cassandra 3.10. To polecenie uruchamia serię mniejszych kompakcji, które również sprawdzają nakładające się na siebie sstables. Jest bardziej wymagający procesora i czasochłonny niż nodetool compact, ale wymaga mniej wolnego miejsca na dysku.

nagrobki zostaną usunięte tylko wtedy, gdy gc_grace_seconds upłynęły od czasu utworzenia nagrobków. Zamierzonym celem gc_grace_seconds jest zapewnienie czasu na naprawy w celu przywrócenia spójności klastra, więc należy zachować ostrożność podczas modyfikowania go-przedwczesne usunięcie nagrobków może skutkować przywróceniem usuniętych danych. Ponadto, ustawienie gc_grace_seconds wpływa na wygaśnięcie podpowiedzi generowanych dla sugerowanego przekazania, więc niebezpieczne jest skrócenie gc_grace_seconds poniżej czasu trwania okna sugerowanego przekazania (domyślnie 3 godziny).

naprawy

naprawy mogą opóźnić lub uniemożliwić upuszczenie nagrobków. Po uruchomieniu pełnej lub przyrostowej naprawy, tabele sstables, których to dotyczy, są oznaczone jako naprawione; w kolejnych zagęszczeniach te tabele będą zagęszczane oddzielnie od sstables, które nie zostały naprawione. Jeśli nagrobki znajdują się w unrepaired sstables, a zacienione dane są w naprawionych sstables (lub odwrotnie), dane nie mogą zostać usunięte, ponieważ sstables nie mogą być zagęszczane razem.
Jeśli regularnie wykonujesz pełne lub stopniowe naprawy klastra, nie powinno to być zbyt dużym problemem, ponieważ nagrobki i dane w końcu zostaną naprawione. Jeśli jednak masz połączenie naprawionych i nie naprawionych danych, a naprawy nie są regularnie przeprowadzane, może to stać się problemem. sstablemetadata może pomóc ci sprawdzić naprawiony status Twoich sstables, aby dowiedzieć się, czy tak się dzieje. Jeśli tak, może być wskazane ustawienie wszystkich sstables jako nieparowanych z sstablerepairedset, aby mogły być zagęszczane razem.
pamiętaj, że naprawy podrzędne nie oznaczają danych jako naprawionych.