a sírkövek életciklusának vizsgálata az Apache Cassandra-ban

ez a bejegyzés a sírkövek életciklusával és kezelésével kapcsolatos blogbejegyzések sorozatának első része.

az Adatok törlése és lejárata a Cassandra-ban olyan dolog, amit gondosan meg kell terveznie. Különösen akkor, ha egyszerre hatalmas mennyiségű adatot töröl. Megfelelő tervezés nélkül ez problémákat okozhat a fürtben, mint például az olvasási késleltetés és a Lemezhasználat lábnyomának növekedése. Ebben a bejegyzésben leírom, hogyan lehet ezt kezelni és annak figyelmeztetéseit.

először nézzük át az alapokat. A Cassandra-ban a lemezen létező adatfájlok (SSTables) megváltoztathatatlan fájlok. Amikor törölünk valamit a Cassandra – ban, egy új SSTable jön létre, amely jelölőt tartalmaz. Ez a jelölő jelzi, hogy melyik partíciót, sort vagy cellát távolították el a Törlés időbélyegével együtt. Ezt a törlési jelölőt sírkőnek hívják.

a törölt adatok és a sírkő együtt létezhetnek a lemezen a gc_grace_seconds nevű időszak alatt, amely alapértelmezés szerint 10 nap. Ez idő alatt, bár az adatok továbbra is létezhetnek a meghajtón, lekérdezés esetén nem kerülnek vissza az ügyfélhez. Ami azt jelenti, hogy ügyfél szempontjából az adatok törlődnek, amint végrehajtja a delete utasítást. Működési szempontból azonban mind az adatok, mind a sírkő továbbra is létezhet, és helyet foglalhat el a lemezen. Ezt a törölt adatot, amely még mindig létezik a lemezen, “árnyékolt adatoknak” nevezzük.”

NB.: Az előző bekezdésben azt mondom, hogy az adatok és a sírkövek “továbbra is együtt létezhetnek a lemezen” (hangsúlyozva a “kannát”), mert ha tömörítés történik, amely magában foglalja az adatokat és a sírköveket, akkor az adatokat kilakoltatják. De a sírkő megmarad, ha a gc_grace_seconds nem telt el.

a gc_grace_seconds egy biztonsági mechanizmus annak biztosítására, hogy a sírkőnek elegendő ideje legyen replikálni minden olyan csomópontra, amely rendelkezik az árnyékolt adatok másolatával. Ahhoz, hogy ez a biztonsági mechanizmus sikeres legyen, képesnek kell lennie a fürt javítására minden gc_grace_seconds. Ez azt jelenti, hogy ha az alapértelmezett 10 napot használja a gc_grace_seconds számára, akkor a javítást 10 naponként el kell kezdeni és be kell fejezni. A javítás célja a zombi adatok megakadályozása a klaszterben. Nem megyek bele a részletekbe, hogy ez hogyan történhet meg, de alapvetően a zombi adatok akkor fordulnak elő, amikor törli az adatokat, de valamikor később visszatér.

a gc_grace_seconds letelte után az adatok és a sírkő végre kilakoltathatók a lemezről, helyreállítva az általuk korábban használt lemezterületet (1.ábra). A lemezterület felszabadítására szolgáló ETA az egyik első pont, amelyet tisztázni szeretnék ebben a bejegyzésben. A Cassandra használatakor sokan meglepőnek találják ezt a mechanizmust, azaz hogy az adatok törlése után az adatok továbbra is léteznek a lemezen. Ez a zavar általában gyorsan tisztázódik, amint az emberek megismerik a sírköveket és a gc_grace_seconds-t. Úgy tűnik azonban, hogy az operátorok hajlamosak azt gondolni, hogy az adatokat és a sírköveket közvetlenül a gc_grace_seconds befejezése után kilakoltatják. Valójában fontos tudni, hogy ez nem (és nem hajlamos) igaz. Általában hosszabb ideig tart, mint a gc_grace_seconds, hogy ez a kilakoltatás megtörténjen, és a lemezterület helyreálljon.

1. ábra-az árnyékolt adatok tömörítése lejárt és nem lejárt sírkövekkel

a fent említett kilakoltatás akkor történik, amikor a tömörítés az árnyékolt adatokat és a sírkövet tartalmazó táblákat érinti. Csak ezután az adatok hatékonyan eltávolítják, és a lemezterület helyreáll. Fontos megjegyezni, hogy még akkor is, ha a gc_grace_seconds elmúlt, és az árnyékolt adatokkal rendelkező SSTable tömörítve van egy másik sstable-vel, amely nem rendelkezik a sírkővel, akkor az árnyékolt adatok nem törlődnek. Ugyanez történik a sírkő jelölőkkel is, azaz ha a sírkővel ellátott SSTable nincs tömörítve az összes olyan SSTables-szel, amelyek még rendelkeznek törölt adatokkal, akkor a sírkő nem kerül kilakoltatásra a lemezről. Ennek oka az, hogy a tömörítés során Cassandra nem tudja, mi van az SSTables-ben, amelyek nem vesznek részt a tömörítésben. Tehát nem tudja tudni, hogy eldobhatja az adatokat, mivel nem látja a sírkövet. Láthatjuk ezt a 2. ábrán, ahol, bár gc_grace_seconds telt el mindkét sírkövek, semmi kilakoltatták után tömörítés.

2. ábra-az árnyékolt adatok és sírköveik külön tömörítése

az adatok és a sírkő jelölő által használt lemez miatt a sírkövek felhalmozódása befolyásolhatja az olvasási késleltetést, mert Cassandrának sok sírkövet kell olvasnia, mielőtt élő adatokat adna vissza.

az adatok törlése általában nem jelent problémát, ha ezek a törlések kicsik és ritkák. Mert a természetes tömörítési életciklus alatt Cassandra végül visszanyeri a lemezterületet és a megtisztított sírköveket. Ha azonban egyszerre nagy mennyiségű adatot töröl, az sok sírkövet hoz létre, és gyorsan befolyásolhatja az olvasási késleltetést.

ha ad-hoc alapon nagy mennyiségű adatot kell törölnie, akkor a következő blogbejegyzésben néhány lépést megtehet a kockázatok csökkentése érdekében.

e-mail

szerző

  • Pedro Gordo

érdekel a Pedro-val való együttműködés? Ütemezzen be egy technikai hívást.

Vélemény, hozzászólás?

Az e-mail-címet nem tesszük közzé.