Cassandra Architectură și factor de replicare
⚡ Rezumat inteligent
Cassandra Arhitectura distribuie datele între nodurile peer fără un singur punct de defecțiune, folosind gossip pentru coordonare și replicare pentru durabilitate. Această pagină acoperă fiecare componentă, atât strategiile de replicare, cât și nivelurile de consistență, precum și căile interne de scriere și citire.

Cassandra este conceput pentru a se descurca Datele mari. CassandraCaracteristica principală a lui este de a stoca date pe mai multe noduri, fără un singur punct de defecțiune.
Motivul pentru acest tip de CassandraArhitectura lui a fost că defecțiunea hardware poate apărea în orice moment. Orice nod poate fi oprit. În caz de defecțiune pot fi utilizate datele stocate într-un alt nod. Prin urmare, Cassandra este proiectat cu arhitectura sa distribuită.
Cassandra stochează date pe diferite noduri cu o arhitectură de modă distribuită peer to peer.
Toate nodurile fac schimb de informații între ele folosind Protocol de bârfă. Bârfa este un protocol în Cassandra prin care nodurile pot comunica între ele.
Componente ale Cassandra Architectură
Există următoarele componente în Cassandra Architectura:

Diagrama de mai sus imbrica componentele: nodurile se află într-un centru de date, centrele de date se află într-un cluster, iar jurnalul de commit-uri, memtable-ul și SSTable-ul se află în fiecare nod individual.
Nod
Nodul este locul unde sunt stocate datele. Este componenta de bază a Cassandra.
Data Center
O colecție de noduri se numește centru de date. Multe noduri sunt clasificate ca un centru de date.
Cluster
Clusterul este colecția multor centre de date.
Jurnal de comitere
Fiecare operație de scriere este scrisă în Commit Log. Jurnalul de confirmare este utilizat pentru recuperarea în caz de accident.
Mem-masa
După ce datele sunt scrise în Commit log, datele sunt scrise în Mem-table. Datele sunt scrise temporar în Mem-table.
SSTable
Când Mem-table atinge un anumit prag, datele sunt stocate într-un fișier de disc SSTable. SSTable-urile sunt imuabile, așadar o actualizare scrie o nouă versiune în loc să o editeze pe cea veche, iar un proces de fundal numit compactare îmbină ulterior aceste versiuni și elimină rândurile înlocuite.
Replicarea datelor în Cassandra
Deoarece poate apărea o problemă hardware sau legătura poate fi oprită în orice moment în timpul procesului de date, este necesară o soluție pentru a oferi o copie de rezervă atunci când a apărut problema. Deci, datele sunt replicate pentru a asigura niciun punct de eșec unic.
Cassandra plasează replici ale datelor pe diferite noduri pe baza acestor doi factori.
- Unde să plasați următoarea replică este determinat de Strategia de replicare.
- În timp ce numărul total de replici plasate pe diferite noduri este determinat de Factorul de replicare.
Un factor de replicare înseamnă că există o singură copie a datelor, în timp ce trei factori de replicare înseamnă că există trei copii ale datelor pe trei noduri diferite.
Pentru a vă asigura că nu există un singur punct de eșec, factorul de replicare trebuie să fie trei.
Există două tipuri de strategii de replicare în Cassandra.
SimplaStrategy în Cassandra
SimpluStrategy este utilizat atunci când aveți un singur centru de date. SimpleStrategy plasează prima replică pe nodul selectat de partitioner. După aceea, replicile rămase sunt plasate în sensul acelor de ceasornic în inelul Nod.
Iată reprezentarea picturală a SimpleStrategy:

NetworkTopologyStrategia în Cassandra
NetworkTopologyStrategy este utilizat atunci când aveți mai mult de două centre de date. În NetworkTopologyStrategy, replicile sunt setate pentru fiecare centru de date separat. NetworkTopologyStrategy plasează replici în sensul acelor de ceasornic în inel până când ajunge la primul nod dintr-un alt rack. Această strategie încearcă să plaseze replici pe diferite rafturi în același centru de date.
Acest lucru se datorează motivului pentru care uneori pot apărea defecțiuni sau probleme în rack. Apoi, replicile de pe alte noduri pot furniza date.
Iată reprezentarea grafică a strategiei de topologie a rețelei:

Factorul de replicare decide câte copii există. Câte dintre aceste copii trebuie să răspundă la o anumită solicitare este o setare separată, descrisă în continuare.
Niveluri de consistență în Cassandra
Nivelul de consistență este setat per interogare, nu per cluster, ceea ce face ca Cassandra reglabil. Acesta precizează câte replici trebuie să confirme o scriere sau să răspundă la o citire înainte ca coordonatorul să răspundă clientului. Un nivel scăzut returnează date mai rapid; un nivel înalt returnează date care sunt cu siguranță mai actuale.
| Nivel | comportament | Utilizare tipică |
|---|---|---|
| ONE | O replică trebuie să răspundă. | Înregistrare în jurnal de mare randament unde o citire ocazională învechită este acceptabilă. |
| CVORUM | Majoritatea tuturor replicilor trebuie să răspundă, calculat ca (RF / 2) + 1. | Alegerea generală pentru consistență și disponibilitate echilibrate. |
| LOCAL_QUORUM | Majoritatea replicilor din centrul de date local trebuie să răspundă. | Clustere cu mai multe centre de date, deoarece evită latența între regiuni. |
| Toate colectiile | Fiecare replică trebuie să răspundă. | Rar. Un nod nefuncțional face ca solicitarea să eșueze complet. |
| orice (doar scrie) | O predare cu indicii este considerată un succes chiar dacă nu este accesibilă nicio replică. | Disponibilitate maximă la scriere, unde durabilitatea poate fi relaxată. |
Consistența puternică este garantată atunci când nivelul de citire plus nivelul de scriere depășește factorul de replicare. Cu un factor de replicare de trei, scrierea la QUORUM și citirea la QUORUM îndeplinesc această regulă, deoarece doi plus doi este mai mare decât trei. Scrierea la UNU și citirea la UNU nu o fac, prin urmare, o citire poate returna o valoare mai veche.
Când o replică este inaccesibilă, coordonatorul stochează o aluzie și îl redă odată ce nodul revine, ceea ce reprezintă modul în care nivelul ANY și o mare parte din Cassandramunca de autovindecare a comportamentului.
Scrie Operație în Cassandra
Coordonatorul trimite o cerere de scriere către replici. Dacă toate replicile sunt în stare de funcționare, vor primi o cerere de scriere, indiferent de nivelul lor de consistență.
Nivel de consistență determină câte noduri vor răspunde înapoi cu confirmarea succesului.
Nodul va răspunde înapoi cu confirmarea succesului dacă datele sunt scrise cu succes în jurnalul de comitere și memTable.
De exemplu, într-un singur centru de date cu factor de replicare egal cu trei, trei replici vor primi cerere de scriere. Dacă nivelul de consistență este unul, doar o replică va răspunde cu confirmarea succesului, iar celelalte două vor rămâne latente.
Să presupunem că două replici rămase pierd date din cauza căderii nodurilor sau a unei alte probleme, Cassandra va face rândul consistent prin mecanismul de reparare încorporat în Cassandra.
Aici este explicat cum are loc procesul de scriere Cassandra,
- Când cererea de scriere vine la nod, în primul rând, se înregistrează în jurnalul de comitere.
- "Atunci Cassandra scrie datele în tabelul mem. Datele scrise în tabelul mem pentru fiecare solicitare de scriere sunt, de asemenea, scrise separat în jurnalul de comitere. Mem-table este o dată stocată temporar în memorie, în timp ce Commit log înregistrează înregistrările tranzacțiilor în scopuri de backup.
- Când mem-table este plin, datele sunt eliminate în fișierul de date SSTable.

Deoarece tabelele SSTable nu sunt niciodată editate pe loc, o ștergere nu elimină rândul imediat. În schimb, un marker numit piatră de mormânt este scris, iar rândul dispare doar atunci când compactarea rulează după perioada de grație. Acesta este motivul pentru care sarcinile de lucru cu ștergere intensă încetinesc citirile până când compactarea recuperează.
Citiți Operație în Cassandra
Există trei tipuri de solicitări de citire pe care un coordonator le trimite la replici.
- Cerere directă
- Cerere de rezumat
- Citiți cererea de reparație
Coordonatorul trimite cererea directă uneia dintre replici. După aceea, coordonatorul trimite cererea de rezumat la numărul de replici specificat de nivelul de consistență și verifică dacă datele returnate sunt date actualizate.
După aceea, coordonatorul trimite cererea de rezumat la toate replicile rămase. Dacă vreun nod oferă o valoare depășită, o solicitare de reparare a citirii în fundal va actualiza datele respective. Acest proces se numește mecanism de reparare a citirii.
În interiorul replicii care primește solicitarea directă, ordinea de căutare este concepută pentru a evita atingerea discului ori de câte ori este posibil.
- memorabilă este verificată prima, deoarece cele mai noi scrieri nu au fost încă șterse.
- cache de rânduri, dacă este activat, poate răspunde întregii solicitări fără alte eforturi.
- A filtru de înflorire este consultat pentru fiecare tabel SSTable. Răspunde cu siguranță nu este prezent sau este posibil prezent, ceea ce permite omiterea majorității tabelelor SSTable fără a le citi.
- indexul partiției și rezumatul său localizează offset-ul exact în octeți în orice SSTable care supraviețuiește verificării filtrului bloom.
- Fragmentele corespondente din mai multe tabele SSTable sunt îmbinate, cea mai recentă marcaj temporal câștigând pentru fiecare coloană.
Filtrul bloom este pasul care menține citirile rapide pe măsură ce datele cresc, deoarece elimină aproape fiecare SSTable din considerare înainte de a avea loc orice căutare pe disc. Aplicarea acestor mecanisme pe mai multe mașini este acoperită în Cassandra grup tutorial.
