Cassandra luo hautakiviä, kun poistat tietoja. Joissakin olosuhteissa ylimääräinen hautakivi voi aiheuttaa pitkiä GC taukoja, viivettä, lukuvirheitä tai kasan virheitä. Tässä artikkelissa annetaan neuvoja hautakivien hallintaan.

Sisällysluettelo

mikä on hautakivi?

Cassandrassa poistettua dataa ei heti tyhjennetä levyltä. Sen sijaan Cassandra kirjoittaa erityisen arvon, joka tunnetaan hautakivenä, osoittaakseen, että tiedot on poistettu. Hautakivet estävät poistettujen tietojen palauttamisen lukujen aikana, ja mahdollistavat lopulta tietojen pudottamisen tiivistämisen kautta.

hautakivet ovat kirjoituksia – ne käyvät läpi normaalin kirjoituspolun, vievät tilaa levyltä ja hyödyntävät Cassandran johdonmukaisuuden mekanismeja. Hautakivet voidaan levittää koko klusterin kautta vihjeitä ja korjauksia. Jos klusteria hallitaan oikein, tämä varmistaa, että tiedot pysyvät poistettuina, vaikka solmu olisi alhaalla, kun poisto annetaan.

Hautakivet syntyvät:

• poista lausumat
• asettamalla TTL: t
• lisäämällä nolliarvoja
• lisäämällä tietoja kokoelman osiin.

mikä on hautakivien normaali elinkaari?

Hautakivet on kirjoitettu aikaleimalla. Ihanteellisissa olosuhteissa hautakivet (ja niihin liittyvät tiedot) pudotetaan tiivistämisen aikana, kun tietty aika on kulunut.

seuraavien kolmen kriteerin on täytyttävä, jotta hautakivet voidaan poistaa:

• hautakivet on luotu yli gc_grace_sekuntia sitten.
• hautakiven sisältävä taulukko on mukana tiivistyksessä.
• kaikki sstabilit, jotka voisivat sisältää olennaisen tiedon, osallistuvat tiivistämiseen.

jokaisessa taulukossa on gc_grace_seconds-asetus. Oletuksena tämä on asetettu 864000, joka vastaa 10 päivää. Tarkoituksena on antaa aikaa klusterin saavuttaa johdonmukaisuus kautta korjauksia (ja siten estää ylösnousemus poistettujen tietojen).

hautakivet pudotetaan tiivistämällä vain, jos kaikki sellaiset vakiot, jotka voisivat sisältää olennaisen tiedon, ovat mukana tiivistämisessä. Jos alkuperäisten tietojen kirjoittamisen ja poiston antamisen välillä on kulunut paljon aikaa, tämä käy epätodennäköisemmäksi:

• Kokoluokkainen Tiivistysstrategia tiivistää samankokoiset SST-tiedostot yhteen. Data pyrkii siirtymään suurempiin sstables ikääntyessään, joten hautakivi (uudessa, pieni sstable) on epätodennäköistä tiivistetään tietojen (vanhassa, suuri sstable).
• tasoitettu Tiivistysstrategia jaetaan moniin tasoihin, jotka tiivistetään erikseen. Hautakivi kirjoitetaan tasolle 0 ja se ”jahtaa” dataa tehokkaasti tasojen läpi-sen pitäisi lopulta saada kiinni.
• aika-ikkunan Tiivistämisstrategia (tai Päivämääräkohtainen Tiivistämisstrategia) ei koskaan tiivistä hautakiveä tietojen kanssa, jos ne on kirjoitettu eri aikaikkunoihin.

milloin hautakivet aiheuttavat ongelmia?

Levynkäyttö

kun tiedot poistetaan, tilaa ei varsinaisesti vapauteta ainakaan taulukon asetuksissa asetetulle gc_grace-jaksolle. Tämä voi aiheuttaa ongelmia, jos klusteri täyttyy nopeasti.

joissakin olosuhteissa tilaa ei koskaan vapauteta ilman manuaalista väliintuloa.

Lukusuoritus

vakavia suoritusongelmia voi esiintyä, jos lukemat kohtaavat suuria määriä hautakiviä.

suorituskykyyn liittyviä ongelmia esiintyy todennäköisimmin seuraavanlaisissa kyselytyypeissä:

• kyselyt, jotka kulkevat taulukon kaikkien osioiden yli (”valitse * keyspace.taulukko”)
• alueen kyselyt (”valitse * keyspace.taulukko, jossa arvo > x” tai ”missä arvo (arvo1, arvo2, …)”
• mikä tahansa kysely, joka voidaan suorittaa vain ”salli suodatus” – lausekkeella.

nämä suoritusongelmat johtuvat hautakivien käyttäytymisestä lukuaikana. Kantaman kyselyssä Cassandra-ajurisi käyttää normaalisti hakulaitteita, jolloin solmut voivat palauttaa rajoitetun määrän vastauksia kerrallaan. Kun kyseessä ovat Cassandran hautakivet, solmun on pidettävä kohtaamansa hautakivet muistissa ja palautettava ne koordinaattorille, jos joku muista jäljennöksistä ei tiedä, että asiaankuuluvat tiedot on poistettu. Hautakiviä ei voi paikantaa, koska on välttämätöntä palauttaa ne kaikki, joten latenssi ja muistin käyttö lisääntyvät suhteessa kohtaamiemme hautakivien määrään.

hautakivien kohtaaminen riippuu siitä, miten tiedot tallennetaan ja haetaan. Jos esimerkiksi Cassandraa käytetään tallentamaan dataa jonoon (mikä ei ole suositeltavaa), kyselijät saattavat törmätä kymmeniin tuhansiin hautakiviin palauttaakseen muutaman tietorivin.

Miten voin diagnosoida hautakiveen liittyviä ongelmia?

kyselyt, jotka kohtaavat suuria määriä hautakiviä, näkyvät lokissa. Oletusarvoisesti yli tuhannen hautakiven kohtaamisesta syntyy varoitus:

varoita org.apassit.cassandra.db.ReadCommand Lue 0 live riviä ja 87051 hautakiviä kyselyn valitse * esimerkistä.taulukko

oletuksena yli 100 000 hautakiven kohtaaminen saa kyselyn epäonnistumaan Tombstoneoverwhelming-poikkeuksella.

tarkistaaksesi, aiheuttavatko Tombstonen lukemat suorituskykyongelmia, tarkista, korreloivatko lukemat lukuviiveen ja GC-tauon keston lisääntymiseen.

Jos on selvää, että kyse on hautakivistä, seuraavat tekniikat voivat auttaa rajaamaan ongelman laajuutta:

• tietyssä kyselyssä palautettujen hautakivien määrä löytyy ajamalla kysely cqlsh: ssa jäljitys päällä.
• tilastot kussakin taulukossa äskettäin tavattujen hautakivien määrästä löytyvät nodetool cfstats.
• hallitun palvelumme klustereista äskettäin kohdattujen hautakivien tilastot löytyvät klusterisivulta Mittaristoista > Taulukkoinfo. Tämä sisältää eläviä soluja lukua ja keskiarvoa kohti ja enintään hautakiviä lukua kohti, eriteltynä solmun tai taulukon mukaan tiettynä ajanjaksona.
• tarkempaa tietoa varastoiduista hautakivistä löytyy ic-työkaluilla.

Miten voin välttää hautakiviongelmat?

seuraavat valinnat voivat auttaa:

• välttää kyselyt, jotka suoritetaan kaikilla taulukon osioilla (esim.kyselyt, joissa ei ole WHERE-lauseketta, tai mikä tahansa kysely, joka vaatii sallimaan suodatuksen).
• muuttaa vaihteluvälikyselyjä välttääkseen poistettujen tietojen kyselyt, tai käyttää suppeampaa dataväliä. Suorituskyky ongelmia ilmenee vain, jos hautakivet luetaan, ja skaalata määrä hautakiviä luetaan.
• Suunnittele tietomalli, jotta vältät suurten tietomäärien poistamisen.
• Jos suunnittelet kaikkien taulukon tietojen poistamista, katkaise tai pudota taulukko poistaaksesi kaikki tiedot tuottamatta hautakiviä.
• käytä oletusarvoa time-to-live. Tämä toimii tehokkaasti vain, jos tietojesi ensisijainen avain on aikaperusteinen, tietosi kirjoitetaan aikajärjestyksessä ja tiedot poistetaan tiettynä päivänä. Voit tehdä tämän asettamalla oletusarvon TTL taulukkotason vaihtoehdoissa ja asettamalla aikaan perustuvan tiivistämisstrategian (Timewindowcompaction Strategy, jos saatavilla, Datetieredcompaction Strategy muutoin). Tämä luo edelleen hautakiviä,mutta koko sstables tehokkaasti pudotetaan, kun TTL kaikki niiden sisältö on kulunut.

Miten pääsen eroon olemassa olevista hautakivistä?

useimmissa olosuhteissa paras lähestymistapa on odottaa, että hautakivi tiivistyy pois normaalisti. Jos kiireelliset suoritus-tai levynkäyttöongelmat vaativat välittömämpiä toimia, on olemassa kaksi nodetool-komentoa, joita voidaan käyttää pakottamaan tiivistyksiä, jotka voivat auttaa hautakivien pudottamisessa. Näitä tulisi pitää viimeisenä keinona-terveessä klusterissa, jossa on hyvin suunniteltu tietomalli, ei ole tarpeen suorittaa manuaalisia tiivistyksiä.

Running nodetool compact pakottaa kaikkien SST-kappaleiden tiivistymisen. Tämä vaatii paljon vapaata levytilaa. Keyspace – ja table-argumenteilla tiivistyminen tulisi rajata niihin taulukoihin, joissa hautakivet ovat ongelma. Taulukoissa, joissa käytetään koko-porrastettua Tiivistysstrategiaa, tämä komento voi johtaa yhden valtavan sstablen luomiseen, joka ei koskaan ole vertaisia, joiden kanssa kompakti; jos

lippu on käytettävissä, sitä tulee käyttää.

nodetool garbagecollect komento on saatavilla Cassandrasta 3.10 eteenpäin. Tämä komento suorittaa sarjan pienempiä tiivistyksiä, jotka tarkistavat myös päällekkäisiä SST-tiedostoja. Se on SUORITINTEHOKKAAMPI ja aikaa vievä kuin nodetool compact, mutta vaatii vähemmän vapaata levytilaa.

Hautakivet poistetaan vain, jos gc_grace_seconds on kulunut hautakivien luomisesta. Tarkoituksena gc_grace_seconds on tarjota aikaa korjauksia palauttaa johdonmukaisuus klusterin, joten ole varovainen, kun muuttaa sitä-ennenaikaisesti poistamalla hautakivet voi johtaa ylösnousemus poistetut tiedot. Myös gc_grace_seconds-asetus vaikuttaa vihjatun luovutuksen tuottamien vihjeiden vanhentumiseen, joten on vaarallista vähentää gc_grace_seconds vihjatun luovutusikkunan keston alapuolelle (oletuksena 3 tuntia).

korjaukset

korjaukset saattavat viivästyttää tai estää hautakivien pudottamisen. Kun täydellinen tai inkrementaalinen korjaus suoritetaan, siihen vaikuttaneet sstables merkitään korjatuiksi; myöhemmissä tiivistyksissä nämä taulukot tiivistetään erillään sstables, joita ei ole korjattu. Jos hautakivet ovat korjaamattomissa sstables ja varjostetut tiedot on korjattu sstables (tai päinvastoin), tietoja ei voida pudottaa, koska sstables ei voi tiivistää yhteen.
jos klusteriin tehdään säännöllisesti täysiä tai inkrementaalisia korjauksia, tämän ei pitäisi olla liian suuri ongelma, sillä hautakivet ja tiedot päätyvät lopulta korjattaviksi. Kuitenkin, jos sinulla on sekoitus korjattuja ja korjaamattomia tietoja, ja et ole säännöllisesti käynnissä korjauksia, tämä voi tulla ongelma. sstablemetadata voi auttaa sinua tarkistamaan sstables korjattu tila selvittää, onko tämä tapahtuu. Jos se on, se voi olla suositeltavaa asettaa kaikki sstables kuin korjaamaton sstablerepairedset jotta ne voidaan tiivistää yhteen.
Huomioithan, alialuekorjaukset eivät merkitse tietoja korjatuiksi.