Cassandra Architecture & Replication Factor
Szerkesztőség
⚡ Okos összefoglaló
Cassandra Az architektúra egyetlen meghibásodási pont nélkül osztja el az adatokat a peer csomópontok között, a koordinációhoz a gossip (szó szerinti fordítás) módszert, a tartósság érdekében pedig a replikációt használja. Ez az oldal minden komponenst lefed, mind a replikációs stratégiákat, mind a konzisztenciaszinteket, mind a belső írási és olvasási útvonalakat.
Cassandra kezelésére tervezték Big adatok. CassandraA fő jellemzője, hogy több csomóponton tárolja az adatokat egyetlen hibapont nélkül.
Az oka ennek a fajta CassandraAz architektúra az volt, hogy a hardverhiba bármikor előfordulhat. Bármely csomópont leállhat. Meghibásodás esetén egy másik csomópontban tárolt adatok használhatók. Ezért, Cassandra elosztott architektúrájával tervezték.
Cassandra különböző csomópontokon tárol adatokat egy peer to peer elosztott divatarchitektúrával.
Az összes csomópont információt cserél egymással a használatával Pletyka protokoll. A pletyka egy protokoll Cassandra amellyel a csomópontok kommunikálni tudnak egymással.
A Cassandra Architectúra
A következő összetevőket tartalmazza Cassandra Architectúra:
A fenti ábra egymásba ágyazza a komponenseket: a csomópontok egy adatközpontban, az adatközpontok egy klaszterben helyezkednek el, a commit napló, a memtable és az SSTable pedig minden egyes csomóponton belül található.
Csomópont
A csomópont az a hely, ahol az adatokat tárolják. Ez az alapvető összetevője Cassandra.
Adatközpont
A csomópontok gyűjteményét adatközpontnak nevezzük. Sok csomópont adatközpontként van besorolva.
Cluster
A fürt számos adatközpont gyűjteménye.
Végrehajtási napló
Minden írási művelet a véglegesítési naplóba kerül. A végrehajtási napló az összeomlás helyreállítására szolgál.
Mem-tábla
A Commit naplóba írt adatok után az adatok a Mem-táblázatba kerülnek. Az adatok ideiglenesen a Mem-táblába kerülnek.
SSTable
Amikor a Mem-tábla mérete elér egy bizonyos küszöbértéket, az adatok egy SSTable lemezfájlba kerülnek. Az SSTable-ok megváltoztathatatlanok, így egy frissítés új verziót ír a régi szerkesztése helyett, és egy tömörítésnek nevezett háttérfolyamat később egyesíti ezeket a verziókat, és elveti a felülírt sorokat.
Adatreplikáció be Cassandra
Mivel az adatfeldolgozás során bármikor előfordulhat hardverprobléma, vagy a kapcsolat leállhat, megoldásra van szükség a biztonsági másolat készítéséhez, amikor a probléma fellép. Így az adatok replikálódnak, hogy ne legyen egyetlen hibapont sem.
Cassandra e két tényező alapján különböző csomópontokra helyezi el az adatok replikáit.
- A következő replika elhelyezésének helyét a Replikációs stratégia.
- Míg a különböző csomópontokon elhelyezett replikák teljes számát a Replikációs tényező.
Az egy replikációs faktor azt jelenti, hogy az adatoknak csak egyetlen példánya van, míg a három replikációs faktor azt jelenti, hogy három különböző csomóponton van három másolat.
Annak érdekében, hogy ne legyen egyetlen hibapont, A replikációs faktornak háromnak kell lennie.
Kétféle replikációs stratégia létezik Cassandra.
SimpleStrategy in Cassandra
SimpleStrategy akkor használatos, ha csak egy adatközpontja van. A SimpleStrategy az első replikát a particionáló által kiválasztott csomópontra helyezi. Ezt követően a fennmaradó replikákat az óramutató járásával megegyező irányban helyezzük el a csomóponti gyűrűben.
Íme a SimpleStrategy képi ábrázolása:
NetworkTopologyStrategy in Cassandra
NetworkTopologyStrategy akkor használatos, ha kettőnél több adatközpontja van. A NetworkTopologyStrategy programban a replikák minden adatközponthoz külön vannak beállítva. A NetworkTopologyStrategy az óramutató járásával megegyező irányban helyezi el a replikákat a gyűrűben, amíg el nem éri egy másik rack első csomópontját. Ez a stratégia megpróbálja a replikákat ugyanabban az adatközpontban különböző állványokon elhelyezni.
Ennek az az oka, hogy néha meghibásodás vagy probléma léphet fel az állványban. Ezután a más csomópontokon lévő replikák szolgáltathatnak adatokat.
Íme a hálózati topológia stratégia képi ábrázolása:
A replikációs tényező határozza meg, hogy hány másolat létezik. Az, hogy ezek közül a másolatok közül hánynak kell válaszolnia egy adott kérésre, egy külön beállítás, amelyet a továbbiakban ismertetünk.
Konzisztenciaszintek a Cassandra
A konzisztenciaszint lekérdezésenként, nem pedig klaszterenként van beállítva, ami miatt Cassandra hangolható. Azt határozza meg, hogy hány replikának kell visszaigazolnia egy írást, vagy válaszolnia egy olvasásra, mielőtt a koordinátor válaszolna az ügyfélnek. Az alacsony szint gyorsabban, a magas szint pedig biztosan aktuálisabb adatokat ad vissza.
| Szintek | Viselkedés | Tipikus felhasználás |
|---|---|---|
| ONE | Egy másolatnak válaszolnia kell. | Nagy áteresztőképességű naplózás, ahol az alkalmankénti elavult beolvasás elfogadható. |
| HATÁROZATKÉPESSÉG | Az összes replika többségének válaszolnia kell, a számítás a következőképpen történik: (RF / 2) + 1. | Általános célú választás a kiegyensúlyozott konzisztencia és rendelkezésre állás érdekében. |
| HELYI_KÉPVISELŐ | A helyi adatközpontban található replikák többségének válaszolnia kell. | Több adatközpontú klaszterek, mivel elkerüli a régiók közötti késleltetést. |
| MINDEN | Minden replikának válaszolnia kell. | Ritka. Egyetlen csomópont leállása a kérés teljes meghiúsulását okozza. |
| ANY (csak írási jogosultságok) | A célzott átadás sikeresnek számít, még akkor is, ha egyetlen replika sem érhető el. | Maximális írási rendelkezésre állás, ahol a tartósság enyhíthető. |
Az erős konzisztencia akkor garantált, ha az olvasási szint és az írási szint összege meghaladja a replikációs tényezőt. Három replikációs tényező esetén a QUORUM-mal történő írás és a QUORUM-mal történő olvasás megfelel ennek a szabálynak, mivel a kettő meg kettő nagyobb, mint a három. Az EGY-gyel történő írás és EGY-gyel történő olvasás nem, ezért az olvasás régebbi értéket adhat vissza.
Amikor egy replika elérhetetlen, a koordinátor tárol egy célzás és visszajátssza, amint a csomópont visszatér, így működik ANY szint és a Cassandraöngyógyító viselkedésmódja működik.
Ír Operabe Cassandra
A koordinátor írási kérelmet küld a replikáknak. Ha az összes replika fent van, akkor írási kérést kapnak, függetlenül a konzisztencia szintjétől.
Konzisztencia szint meghatározza, hogy hány csomópont válaszol vissza a siker visszaigazolásával.
A csomópont a siker visszaigazolásával válaszol, ha az adatok sikeresen beírásra kerültek a véglegesítési naplóba, és memTable.
Például egyetlen adatközpontban, amelynek replikációs tényezője három, három replika kap írási kérést. Ha a konzisztencia szintje egy, akkor csak egy replika válaszol vissza a siker visszaigazolásával, a maradék kettő pedig alvó állapotban marad.
Tegyük fel, ha a fennmaradó két replika elveszíti az adatokat csomópont-leállás vagy más probléma miatt, Cassandra egységessé teszi a sort a beépített javítómechanizmussal Cassandra.
Itt elmagyarázzuk, hogyan megy végbe az írási folyamat Cassandra,
- Amikor írási kérés érkezik a csomóponthoz, mindenekelőtt bejelentkezik a véglegesítési naplóba.
- Majd Cassandra beírja az adatokat a mem-táblába. A mem-táblába írt adatok minden írási kérésnél külön is íródnak a véglegesítési naplóba. A mem-tábla egy ideiglenesen tárolt adat a memóriában, míg a Commit log naplózza a tranzakciós rekordokat biztonsági mentés céljából.
- Amikor a mem-table megtelt, az adatok az SSTable adatfájlba kerülnek.
Mivel az SSTable-ök soha nem szerkeszthetők helyben, a törlés nem távolítja el azonnal a sort. Ehelyett egy jelölő, az úgynevezett sírkő ki van írva, és a sor csak akkor tűnik el, ha a tömörítés a türelmi időszak után fut. Ezért lassítják a nagy törlési terhelések az olvasást, amíg a tömörítés utoléri.
Olvass Operabe Cassandra
Háromféle olvasási kérés létezik, amelyeket a koordinátor küld a replikáknak.
- Közvetlen kérés
- Digest kérés
- Olvassa el a javítási kérelmet
A koordinátor közvetlen kérést küld az egyik replikának. Ezt követően a koordinátor elküldi a kivonatkérést a konzisztenciaszint által meghatározott számú replikának, és ellenőrzi, hogy a visszaadott adat frissített adat-e.
Ezt követően a koordinátor kivonatkérést küld az összes fennmaradó replikának. Ha bármely csomópont elavult értéket ad, a háttérben történő olvasási javítási kérelem frissíti az adatokat. Ezt a folyamatot olvasási javítási mechanizmusnak nevezik.
A közvetlen kérést fogadó replikán belül a keresési sorrend úgy van kialakítva, hogy amennyire csak lehetséges, kerülje a lemez érintését.
- Az memtable először a kerül ellenőrzésre, mivel a legújabb írási műveletek még nem lettek kiürítve.
- Az sor gyorsítótár, ha engedélyezve van, további munka nélkül képes válaszolni a teljes kérésre.
- A virágzásszűrő minden SSTable esetében lekérdezésre kerül. A válasza definitely not present (határozottan nem jelen) vagy possibly present (lehetségesen jelen), így a legtöbb SSTable kihagyható beolvasás nélkül.
- Az partícióindex és az összegzése megkeresi a pontos bájt eltolást bármely olyan SSTable-en belül, amely túléli a bloom szűrő ellenőrzését.
- Több SSTables egyező töredékeit egyesíti a rendszer, minden oszlopban a legfrissebb időbélyeggel győztesen.
A bloom szűrő az a lépés, amely az adatmennyiség növekedésével gyors olvasást biztosít, mivel szinte az összes SSTable-t eltávolítja a figyelembe vételből, mielőtt bármilyen lemezkeresés megtörténne. Ezen mechanizmusok több gépen történő alkalmazását a ... részben tárgyaljuk. Cassandra fürt tutorial.
