Cassandra generál sírkövek, ha törli az adatokat. Bizonyos körülmények között a felesleges sírkövek hosszú GC-szüneteket, késleltetést, olvasási hibákat vagy kupachibákat okozhatnak. Ez a cikk tanácsokat ad a sírkövek kezeléséhez.

Tartalomjegyzék

mi az a sírkő?

a Cassandra-ban a törölt adatok nem törlődnek azonnal a lemezről. Ehelyett Cassandra egy speciális értéket ír, amelyet sírkőnek neveznek, jelezve, hogy az adatokat törölték. A sírkövek megakadályozzák a törölt adatok visszajuttatását az olvasás során, és végül lehetővé teszik az adatok tömörítéssel történő eldobását.

a sírkövek írások – átmennek a normál írási útvonalon, helyet foglalnak a lemezen, és használják a Cassandra konzisztencia mechanizmusait. Sírkövek lehet szaporítani az egész klaszter keresztül tippeket és javításokat. Ha egy fürtöt megfelelően kezelnek, ez biztosítja, hogy az adatok akkor is törlődnek, ha egy csomópont nem működik a Törlés kiadásakor.

sírkövek által generált:

• utasítások törlése
• TTLS beállítása
• null értékek beszúrása
• adatok beszúrása egy gyűjtemény részeibe.

mi a sírkövek normális életciklusa?

a sírkövek időbélyeggel vannak írva. Ideális körülmények között a sírkövek (és a hozzájuk kapcsolódó adatok) egy bizonyos idő elteltével a tömörítés során leesnek.

a következő három feltételnek kell teljesülnie a sírkövek eltávolításához:

• a sírkövek több mint gc_grace_seconds ezelőtt készültek.
• a sírkövet tartalmazó táblázat tömörítésben vesz részt.
• minden sstables, amely tartalmazhatja a vonatkozó adatokat, részt vesz a tömörítésben.

minden tábla rendelkezik egy gc_grace_seconds beállítással. Alapértelmezés szerint ez 864000-re van állítva, ami 10 napnak felel meg. A cél az, hogy időt biztosítson a klaszter számára a konzisztencia eléréséhez javítások révén (és ezáltal megakadályozza a törölt adatok feltámadását).

a sírköveket csak akkor ejtik le tömörítéssel, ha az összes sstables, amely tartalmazhatja a releváns adatokat, részt vesz a tömörítésben. Ha sok idő telt el az eredeti adatok írása és a Törlés kiadása között, ez kevésbé valószínű:

• a Méretszintű tömörítési stratégia hasonló méretű sstables-eket tömörít. Az adatok az életkor előrehaladtával általában nagyobb sstables-be költöznek, így a sírkő (egy új, kicsi sstable-ben) valószínűleg nem tömörül az adatokkal (egy régi, nagy sstable-ben).
• Leveled tömörítési stratégia van osztva több szinten, hogy tömörített külön-külön. A sírkő a 0. szintre lesz írva, és hatékonyan ‘üldözi’ az adatokat a szinteken keresztül – végül fel kell zárkóznia.
• időablak tömörítési stratégia (vagy Dátumszintű tömörítési stratégia) soha nem tömöríti a sírkövet az adatokkal, ha azokat különböző időablakokba írják.

mikor okoznak problémákat a sírkövek?

Lemezhasználat

az adatok törlésekor a hely valójában nem lesz felszabadítva legalább a táblázat beállításaiban beállított gc_grace időszakra. Ez problémákat okozhat, ha egy fürt gyorsan megtelik.

bizonyos körülmények között a tér soha nem szabadul fel kézi beavatkozás nélkül.

olvasási teljesítmény

súlyos teljesítményproblémák fordulhatnak elő, ha az olvasások nagyszámú sírkövekkel találkoznak.

teljesítményproblémák valószínűleg a következő típusú lekérdezésekkel fordulnak elő:

• lekérdezések, amelyek egy táblázat összes partícióján futnak (“válassza a * lehetőséget a kulcstérből.táblázat”)
• tartomány lekérdezések (“select * from keyspace.táblázat, ahol érték > x”, vagy “WHERE value IN (value1, value2, …)”
• bármely lekérdezés, amely csak “szűrés engedélyezése” záradékkal futtatható.

ezek a teljesítményproblémák a sírkövek viselkedése miatt fordulnak elő olvasás közben. Egy tartomány lekérdezésben a Cassandra illesztőprogram általában lapozást használ, amely lehetővé teszi a csomópontok számára, hogy egyszerre korlátozott számú választ adjanak vissza. Amikor cassandra sírkövekről van szó, a csomópontnak meg kell őriznie a memóriában a talált sírköveket, és vissza kell küldenie őket a koordinátornak, arra az esetre, ha a többi másolat nem tudja, hogy a vonatkozó adatokat törölték. A sírköveket nem lehet lapozni, mert elengedhetetlen az összes visszaadása, így a késleltetés és a memóriahasználat arányosan növekszik a talált sírkövek számával.

az, hogy a sírkövek találkoznak-e, az adatok tárolásának és visszakeresésének módjától függ. Például, ha a Cassandra-t arra használják, hogy adatokat tároljon egy sorban (ami nem ajánlott), a lekérdezések több tízezer sírkövekkel találkozhatnak, hogy néhány sor adatot visszaadjanak.

hogyan diagnosztizálhatom a sírkővel kapcsolatos problémákat?

azok a lekérdezések, amelyek nagyszámú sírkövekkel találkoznak, megjelennek a naplókban. Alapértelmezés szerint egy több mint ezer sírkövet tartalmazó olvasás figyelmeztetést generál:

WARN org.apacs.cassandra.db.ReadCommand Read 0 élő sorok és 87051 sírkő cellák lekérdezéshez SELECT * from example.table

alapértelmezés szerint több mint 100 000 sírkő találkozása esetén a lekérdezés sikertelen lesz a TombstoneOverwhelmingException.

annak ellenőrzéséhez, hogy a sírkő-olvasások okoznak-e teljesítményproblémákat, ellenőrizze, hogy az olvasások korrelálnak-e az olvasási késleltetés növekedésével és a GC szünet időtartamával.

Ha egyértelmű, hogy a sírkövek a problémák, a következő technikák segíthetnek a probléma hatókörének szűkítésében:

• az adott lekérdezésben visszaadott sírkövek száma megtalálható a lekérdezés futtatásával a cqlsh-ban, engedélyezve a nyomkövetést.
• Az egyes táblázatokban a közelmúltban tapasztalt sírkövek számának statisztikája elérhető a nodetool cfstatskimenetén.
• a felügyelt szolgáltatásunkban lévő klaszterek esetében a legutóbb tapasztalt sírkövek statisztikái a klaszter oldalon érhetők el a metrikák listáiban> Table Info. Ez magában foglalja az élő cellákat olvasásonként, az átlagos és a maximális sírköveket olvasásonként, csomópontonként vagy táblázatonként lebontva egy adott időszakra.
• a tárolt sírkövekről részletesebb információk találhatók az ic-tools segítségével.

hogyan kerülhetem el a sírkő problémákat?

a következő lehetőségek segíthetnek:

• Kerülje el azokat a lekérdezéseket, amelyek a táblázat összes partícióján futnak (pl. WHERE záradék nélküli lekérdezések, vagy bármely olyan lekérdezés, amely lehetővé teszi a szűrést).
• változtassa meg a tartomány lekérdezéseit a törölt adatok lekérdezésének elkerülése érdekében, vagy szűkebb adattartományon működjön. Teljesítményproblémák csak akkor fordulnak elő, ha a sírkövek olvasásra kerülnek, és az olvasott sírkövek számával skálázódnak.
• tervezze meg az adatmodellt, hogy elkerülje a nagy mennyiségű adat törlését.
• Ha egy táblázat összes adatának törlését tervezi, csonkolja vagy dobja el a táblázatot az összes adat eltávolításához sírkövek létrehozása nélkül.
• alapértelmezett élettartam-érték használata. Ez csak akkor működik hatékonyan, ha az adatok elsődleges kulcsa időalapú, az adatok időrendi sorrendben vannak megírva, és az adatok egy ismert időpontban törlődnek. Ehhez állítson be egy alapértelmezett TTL-t a táblázatszintű beállításokban, és állítson be egy időalapú tömörítési stratégiát (TimeWindowCompactionStrategy, ha elérhető, DateTieredCompactionStrategy egyébként). Ez továbbra is sírköveket hoz létre, de az egész sstables hatékonyan eldobásra kerül, miután a TTL az összes tartalmukon elmúlt.

hogyan lehet megszabadulni a meglévő sírkövektől?

a legtöbb esetben a legjobb megközelítés az, ha megvárjuk, amíg a sírkő normálisan összenyomódik. Ha a sürgős teljesítmény vagy a lemezhasználati problémák azonnali cselekvést igényelnek, két nodetool parancs használható a tömörítés kényszerítésére, amelyek segíthetnek a sírkövek elejtésében. Ezeket végső megoldásnak kell tekinteni – egy jól megtervezett adatmodellel rendelkező egészséges klaszterben nem szükséges kézi tömörítést futtatni.

futásnodetool compact kényszeríti az összes sstables tömörítését. Ez nagy mennyiségű szabad lemezterületet igényel. A kulcstér és a tábla argumentumokat arra kell használni, hogy a tömörítést azokra a táblákra korlátozzák, ahol a sírkövek problémát jelentenek. Azokon a táblákon, ahol Méretszintű tömörítési stratégiát alkalmaznak, ez a parancs egy hatalmas létrehozásához vezethet sstable amelynek soha nem lesz társa, akivel kompakt lehet; ha a –split-output jelző elérhető, akkor azt kell használni.

a nodetool garbagecollect parancs a Cassandra 3.10-től érhető el. Ez a parancs egy sor kisebb tömörítést futtat, amelyek az átfedő sstables-eket is ellenőrzik. CPU-igényesebb és időigényesebb, mint a nodetool compact, de kevesebb szabad lemezterületet igényel.

a sírkövek csak akkor kerülnek eltávolításra, ha a gc_grace_seconds eltelt a sírkövek létrehozása óta. A gc_grace_seconds célja, hogy időt biztosítson a javításra a klaszter konzisztenciájának helyreállításához, ezért legyen óvatos a módosításakor – a sírkövek idő előtti eltávolítása a törölt adatok feltámadását eredményezheti. Ezenkívül a gc_grace_seconds beállítás befolyásolja a tippelt átadáshoz generált tippek lejáratát, ezért veszélyes a gc_grace_seconds csökkentése a tippelt átadási ablak időtartama alatt (alapértelmezés szerint 3 óra).

javítások

a javítások késleltethetik vagy megakadályozhatják a sírkövek leesését. Teljes vagy növekményes javítás futtatásakor az általa érintett sstables javításként van megjelölve; a későbbi tömörítések során ezeket a táblákat külön tömörítik a nem javított sstables-től. Ha a sírkövek javítatlan sstables – ben vannak, az árnyékolt adatok pedig javított sstables-ben vannak (vagy fordítva), az adatok nem dobhatók el, mert az sstables nem tömöríthető össze.
Ha rendszeresen teljes vagy növekményes javításokat végez a fürtön, ez nem lehet túl nagy probléma, mivel a sírkövek és az adatok végül javításra kerülnek. Ha azonban javított és nem javított adatok keveréke van, és nem rendszeresen végez javításokat, ez problémává válhat. sstablemetadata segítségével ellenőrizze a javított állapotát a sstables, hogy dolgozzanak ki, hogy ez történik. Ha igen, akkor tanácsos lehet az összes sstables-t megjavítatlanként beállítani az sstablerepairedset segítségével, hogy össze lehessen tömöríteni őket.
Felhívjuk figyelmét, hogy a subrange javítások nem jelölik meg az adatokat javítottként.