Cassandra Architecture & Replication Factor

Cassandra je navržen tak, aby zvládl Big dat. CassandraHlavní funkcí je ukládání dat na více uzlech bez jediného bodu selhání.

Důvod pro tento druh Cassandraarchitektura byla taková, že k selhání hardwaru může dojít kdykoli. Jakýkoli uzel může být dole. V případě poruchy lze použít data uložená v jiném uzlu. Proto, Cassandra je navržen s distribuovanou architekturou.

Cassandra ukládá data na různých uzlech pomocí distribuované módní architektury typu peer to peer.

Všechny uzly si vyměňují informace mezi sebou pomocí Gossip protokol. Gossip je protokol v Cassandra pomocí kterých mohou uzly mezi sebou komunikovat.

Komponenty Cassandra Architecture

V Cassandra Archistruktura:

Uzel

Uzel je místo, kde jsou uložena data. Je základní složkou Cassandra.

Data Center

Kolekce uzlů se nazývá datové centrum. Mnoho uzlů je kategorizováno jako datové centrum.

Cluster

Cluster je souborem mnoha datových center.

Zapsat protokol

Každá operace zápisu je zapsána do Commit Log. Commit log se používá pro obnovu po havárii.

Paměťový stůl

Po zápisu dat do Commit logu jsou data zapsána do Mem-table. Data jsou dočasně zapsána do tabulky Mem.

SSTable

Když Mem-table dosáhne určité prahové hodnoty, data se vyprázdní do souboru disku SSTable.

Replikace dat v Cassandra

Vzhledem k tomu, že kdykoli během zpracování dat může dojít k problémům s hardwarem nebo k výpadku spojení, je vyžadováno řešení, které poskytne zálohu, když se problém vyskytne. Data jsou tedy replikována pro zajištění žádného jediného bodu selhání.

Cassandra umístí repliky dat na různé uzly na základě těchto dvou faktorů.

• Kam umístit další repliku je určeno Strategie replikace.
• Zatímco celkový počet replik umístěných na různých uzlech je určen Replikační faktor.

Jeden faktor replikace znamená, že existuje pouze jedna kopie dat, zatímco tři faktor replikace znamená, že existují tři kopie dat na třech různých uzlech.

Aby se zajistilo, že neexistuje jediný bod selhání, replikační faktor musí být tři.

Existují dva druhy replikačních strategií Cassandra.

SimpleStrategy v Cassandra

SimpleStrategy se používá, když máte pouze jedno datové centrum. SimpleStrategy umístí první repliku na uzel vybraný rozdělovačem oddílů. Poté jsou zbývající repliky umístěny ve směru hodinových ručiček do kruhu Node.

Zde je obrázková reprezentace SimpleStrategy:

NetworkTopologyStrategy v Cassandra

NetworkTopologyStrategy se používá, když máte více než dvě datová centra. V NetworkTopologyStrategy se repliky nastavují pro každé datové centrum zvlášť. NetworkTopologyStrategy umístí repliky do kruhu ve směru hodinových ručiček, dokud nedosáhne prvního uzlu v jiném stojanu. Tato strategie se pokouší umístit repliky do různých stojanů ve stejném datovém centru.

To je způsobeno tím, že někdy může dojít k selhání nebo problému ve stojanu. Data pak mohou poskytovat repliky na jiných uzlech.

Zde je obrázkové znázornění strategie topologie sítě:

Napsat Operavstoupit Cassandra

Koordinátor odešle žádost o zápis do replik. Pokud jsou všechny repliky aktivní, obdrží požadavek na zápis bez ohledu na úroveň jejich konzistence.

Úroveň konzistence určuje, kolik uzlů odpoví zpět s potvrzením úspěchu.

Uzel odpoví zpět s potvrzením úspěchu, pokud jsou data úspěšně zapsána do protokolu odevzdání a memTable.

Například v jediném datovém centru s replikačním faktorem rovným třem obdrží požadavek na zápis tři repliky. Pokud je úroveň konzistence jedna, pouze jedna replika odpoví zpět s potvrzením úspěchu a zbývající dvě zůstanou nečinné.

Předpokládejme, že pokud zbývající dvě repliky ztratí data kvůli výpadkům uzlů nebo jinému problému, Cassandra díky vestavěnému opravnému mechanismu bude řádek konzistentní Cassandra.

Zde je vysvětleno, jak probíhá proces zápisu Cassandra,

1. Když do uzlu přijde požadavek na zápis, nejprve se zapíše do protokolu odevzdání.
2. Pak Cassandra zapíše data do mem-tabulky. Data zapsaná v mem-tabulce při každém požadavku na zápis se také zapisují do protokolu odevzdání samostatně. Tabulka paměti je dočasně uložená data v paměti, zatímco Commit log zaznamenává záznamy transakcí pro účely zálohování.
3. Když je tabulka mem plná, data se vyprázdní do datového souboru SSTable.

číst Operavstoupit Cassandra

Existují tři typy požadavků na čtení, které koordinátor odesílá do replik.

1. Přímá žádost
2. Žádost o výtah
3. Přečtěte si žádost o opravu

Koordinátor odešle přímou žádost jedné z replik. Poté koordinátor odešle žádost o souhrn na počet replik určený úrovní konzistence a zkontroluje, zda jsou vrácená data aktualizovaná data.

Poté koordinátor odešle žádost o souhrn všem zbývajícím replikám. Pokud některý uzel uvede zastaralou hodnotu, žádost o opravu čtení na pozadí aktualizuje tato data. Tento proces se nazývá mechanismus opravy čtení.

Shrnutí

• Tento tutoriál vysvětluje Cassandra vnitřní architektura a jak Cassandra replikuje, zapisuje a čte data v různých fázích.
• Zde je také vysvětleno jak Cassandra udržuje úroveň konzistence během celého procesu.
• Komponenty Cassandra Architecture: Node, Data Center, Cluster, Commit Log, Mem-table, SSTable
• Jeden faktor replikace znamená, že existuje pouze jedna kopie dat, zatímco tři faktor replikace znamená, že existují tři kopie dat na třech různých uzlech.
• SimpleStrategy se používá, když máte pouze jedno datové centrum.
• NetworkTopologyStrategy se používá, když máte více než dvě datová centra.