Cassandra Architecture & Replikationsfaktor

⚡ Smart opsummering

Cassandra Arkitekturen distribuerer data på tværs af peer-noder uden et enkelt fejlpunkt (Single Point of Failure), hvor Gossip bruges til koordinering og replikering for holdbarhed. Denne side dækker alle komponenter, både replikeringsstrategier, konsistensniveauer og de interne skrive- og læsestier.

🕸️ Peer-to-peer-design: Hver node er lige og udveksler tilstand via Gossip-protokollen, så der findes ingen master, der kan fejle.
🧱 Opbevaringskomponenter: En skrivning lander i commit-loggen og memtabellen og flusher derefter til en uforanderlig SSTable på disken.
🔁 Replikationsstrategi: SimpleStrategy passer til ét datacenter, mens NetworkTopologyStrategy placerer replikaer pr. datacenter og pr. rack.
🔢 Replikationsfaktor: Tre kopier på tre noder er standardindstillingen for at fjerne et enkelt fejlpunkt.
⚖️ Konsistensniveauer: Det valgte niveau pr. forespørgsel bestemmer, hvor mange replikaer der skal bekræftes, før klienten besvares.
🔍 Læs sti: Direkte, digest- og læste reparationsanmodninger kombineres for at returnere aktuelle data og i det stille rette forældede replikaer.

Læs mere

Cassandra er designet til at håndtere Big data. Cassandra's hovedfunktion er at gemme data på flere noder uden et enkelt fejlpunkt.

Årsagen til denne slags Cassandra's arkitektur var, at hardwarefejlen kan opstå når som helst. Enhver node kan være nede. I tilfælde af fejl kan data gemt i en anden node bruges. Derfor, Cassandra er designet med sin distribuerede arkitektur.

Cassandra gemmer data på forskellige noder med en peer to peer distribueret modearkitektur.

Alle knudepunkter udveksler information med hinanden vha Sladder protokol. Sladder er en protokol i Cassandra hvormed noder kan kommunikere med hinanden.

Komponenter af Cassandra Architecture

Der er følgende komponenter i Cassandra Archilære:

Diagrammet ovenfor indlejrer komponenterne: noder sidder inde i et datacenter, datacentre sidder inde i en klynge, og commit-loggen, memtablen og SSTablen sidder inde i hver enkelt node.

Node

Node er det sted, hvor data gemmes. Det er den grundlæggende komponent af Cassandra.

Data Center

En samling af noder kaldes datacenter. Mange noder er kategoriseret som et datacenter.

Cluster

Klyngen er samlingen af mange datacentre.

Commit Log

Hver skriveoperation skrives til Commit Log. Commit log bruges til crash recovery.

Mem-bord

Efter data skrevet i Commit log, skrives data i Mem-tabel. Data skrives midlertidigt i Mem-tabel.

SSTable

Når en Mem-tabel når en bestemt tærskel, flyttes dataene til en SSTable-diskfil. SSTables er uforanderlige, så en opdatering skriver en ny version i stedet for at redigere den gamle, og en baggrundsproces kaldet komprimering fletter senere disse versioner og kasserer de erstattede rækker.

Datareplikering i Cassandra

Da hardwareproblem kan opstå, eller linket kan være nede på et hvilket som helst tidspunkt under dataprocessen, er en løsning påkrævet for at give en backup, når problemet er opstået. Så data replikeres for at sikre, at der ikke er et enkelt fejlpunkt.

Cassandra placerer replikaer af data på forskellige noder baseret på disse to faktorer.

Hvor den næste replika skal placeres, bestemmes af Replikeringsstrategi.
Mens det samlede antal replikaer placeret på forskellige noder bestemmes af Replikationsfaktor.

En replikeringsfaktor betyder, at der kun er en enkelt kopi af data, mens tre replikeringsfaktor betyder, at der er tre kopier af dataene på tre forskellige noder.

For at sikre, at der ikke er et enkelt fejlpunkt, replikationsfaktor skal være tre.

Der er to slags replikeringsstrategier i Cassandra.

SimpleStrategy i Cassandra

Simpel Strategi bruges, når du kun har ét datacenter. SimpleStrategy placerer den første replika på den node, der er valgt af partitioneren. Derefter placeres resterende replikaer med uret i Node-ringen.

Her er den billedlige repræsentation af SimpleStrategy:

Netværk Topologi Strategi i Cassandra

Netværkstopologistrategi bruges, når du har mere end to datacentre. I NetworkTopologyStrategy indstilles replikaer for hvert datacenter separat. NetworkTopologyStrategy placerer replikaer i urets retning i ringen, indtil den når den første node i et andet rack. Denne strategi forsøger at placere replikaer på forskellige racks i det samme datacenter.

Dette skyldes, at der nogle gange kan opstå fejl eller problemer i stativet. Så kan replikaer på andre noder levere data.

Her er den billedlige repræsentation af netværkstopologistrategien:

Replikeringsfaktoren bestemmer, hvor mange kopier der findes. Hvor mange af disse kopier der skal besvare en given anmodning, er en separat indstilling, som beskrives nedenfor.

Konsistensniveauer i Cassandra

Konsistensniveauet indstilles pr. forespørgsel snarere end pr. klynge, hvilket er det, der gør Cassandra justerbar. Den angiver, hvor mange replikaer der skal kvittere for en skrivning eller svare på en læsning, før koordinatoren svarer klienten. Et lavt niveau returnerer hurtigere; et højt niveau returnerer data, der er mere sikkert aktuelle.

Niveau	Adfærd	Typisk brug
ONE	Én replika skal svare.	Højkapacitetslogning, hvor en lejlighedsvis forældet aflæsning er acceptabel.
KVORUM	Et flertal af alle replikaer skal svare, beregnet som (RF / 2) + 1.	Det generelle valg for afbalanceret konsistens og tilgængelighed.
LOKAL_KVORUM	Et flertal af replikaerne i det lokale datacenter skal reagere.	Klynger med flere datacentre, fordi det undgår latenstid på tværs af regioner.
ALLE	Enhver replika skal svare.	Sjælden. Én node nede får anmodningen til at mislykkes fuldstændigt.
NOGEN (kun skriver)	En antydet overdragelse tæller som succes, selvom ingen replika er tilgængelig.	Maksimal skrivetilgængelighed, hvor holdbarheden kan lempes.

Stærk konsistens garanteres, når læseniveauet plus skriveniveauet overstiger replikationsfaktoren. Med en replikationsfaktor på tre opfylder skrivning ved QUORUM og læsning ved QUORUM denne regel, fordi to plus to er større end tre. Skrivning ved EN og læsning ved EN gør det ikke, og en læsning kan derfor returnere en ældre værdi.

Når en replika ikke kan nås, gemmer koordinatoren en vink og afspiller det igen, når noden vender tilbage, hvilket er sådan niveauet ALLE og meget af Cassandras selvhelbredende adfærdsarbejde.

Skrive Operation i Cassandra

Koordinatoren sender en skriveanmodning til replikaer. Hvis alle replikaerne er oppe, vil de modtage skriveanmodning uanset deres konsistensniveau.

Konsistensniveau bestemmer, hvor mange noder der vil svare tilbage med succesbekræftelsen.

Noden vil svare tilbage med succesbekræftelsen, hvis data er skrevet med succes til commit-loggen og memTabel.

For eksempel vil tre replikaer modtage skriveanmodninger i et enkelt datacenter med en replikeringsfaktor lig med tre. Hvis konsistensniveauet er ét, vil kun én replika svare tilbage med succesbekræftelsen, og de resterende to vil forblive i dvale.

Antag, at hvis de resterende to replikaer mister data på grund af knudepunkter eller et andet problem, Cassandra vil gøre rækken ensartet ved den indbyggede reparationsmekanisme i Cassandra.

Her er det forklaret, hvordan skriveprocessen foregår i Cassandra,

Når skriveanmodning kommer til noden, logger den først og fremmest på commit-loggen.
Derefter Cassandra skriver dataene i mem-tabellen. Data skrevet i mem-tabellen på hver skriveanmodning skriver også i commit-log separat. Mem-table er en midlertidigt gemt data i hukommelsen, mens Commit-log logger transaktionsposterne til sikkerhedskopieringsformål.
Når mem-tabellen er fuld, tømmes data til SSTable-datafilen.

Da SSTAbeller aldrig redigeres på stedet, fjerner en sletning ikke rækken med det samme. I stedet bruges en markør kaldet en gravsten er skrevet, og rækken forsvinder kun, når komprimeringen kører efter respitperioden. Det er derfor, at tunge sletningsbelastninger forsinker læsningen, indtil komprimeringen indhenter den.

Læs Operation i Cassandra

Der er tre typer læseanmodninger, som en koordinator sender til replikaer.

Direkte anmodning
Sammenfatningsanmodning
Læs reparationsanmodning

Koordinatoren sender direkte anmodning til en af replikaerne. Derefter sender koordinatoren sammenfatningsanmodningen til det antal replikaer, der er angivet af konsistensniveauet, og kontrollerer, om de returnerede data er opdaterede data.

Derefter sender koordinatoren en sammenfatningsanmodning til alle de resterende replikaer. Hvis en node giver en forældet værdi, vil en anmodning om baggrundslæsereparation opdatere disse data. Denne proces kaldes læsereparationsmekanisme.

Inde i den replika, der modtager den direkte anmodning, er opslagsrækkefølgen designet til at undgå at berøre disken, hvor det er muligt.

memtable kontrolleres først, da de nyeste skrivninger endnu ikke er blevet ryddet.
rækkecache, hvis aktiveret, kan besvare hele anmodningen uden yderligere arbejde.
A blomstringsfilter konsulteres for hver SSTable. Den svarer absolut ikke til stede eller muligvis til stede, hvilket gør det muligt at springe de fleste SSTAbeller over uden at læse dem.
partitionsindeks og dens oversigt finder det nøjagtige byte-offset i enhver SSTable, der overlever bloom-filtertjekket.
Matchende fragmenter fra flere SSTAbeller flettes sammen, hvor det seneste tidsstempel vinder for hver kolonne.

Bloom-filteret er det trin, der holder læsninger hurtige, efterhånden som data vokser, fordi det fjerner næsten alle SSTables fra overvejelse, før der finder en disksøgning sted. Anvendelse af disse mekanikker på tværs af flere maskiner er dækket i Cassandra klynge tutorial.

Ofte Stillede Spørgsmål

Hver node kontakter et par peers hvert sekund og deler status om sig selv og alle, den kender: liveness, load, schema version og token range. Sådan forbliver en klynge koordineret uden en master.

Komprimering fletter flere SSTAbeller sammen til én, keeping den nyeste version af hver kolonne og kasserer tombstone-markerede rækker. Uden den ville en læsning skulle berøre gradvist flere filer.

Virtuelle noder opdeler hver fysisk maskines andel af tokenringen i mange små områder. Dette spreder data mere jævnt og gør det langt hurtigere at tilføje eller erstatte en node end manuel tokentildeling.

AI kan anvende reglen om en læsning plus skrivning, der er større end replikeringsfaktoren, og foreslå en parring, men den acceptable stalitet for hver forespørgsel er en forretningsbeslutning, der skal angives først.

AI læser nodetool-output og -målinger godt, så den er effektiv til at opdage hot-partitioner, tombstone-opbygning og komprimeringsefterslæb. Enhver konfigurationsændring, den foreslår, bør stadig testes på en staging-klynge.