Cassandra ArchiTecture & Replication Factor
David Carter
⚡ Älykäs yhteenveto
Cassandra arkkitehtuuri jakaa dataa vertaissolmujen kesken ilman yksittäistä vikaantumispistettä käyttäen juoruja koordinointiin ja replikointiin kestävyyden takaamiseksi. Tämä sivu kattaa kaikki komponentit, sekä replikointistrategiat, yhdenmukaisuustasot että sisäiset kirjoitus- ja lukupolut.
Cassandra on suunniteltu käsittelemään Big Data. CassandraPääominaisuus on tallentaa tietoja useisiin solmuihin ilman yhtä vikakohtaa.
Syynä tällaiseen CassandraArkkitehtuuri oli, että laitteistovika voi tapahtua milloin tahansa. Mikä tahansa solmu voi olla alhaalla. Vian sattuessa voidaan käyttää toiseen solmuun tallennettuja tietoja. Siten, Cassandra on suunniteltu hajautetulla arkkitehtuurillaan.
Cassandra tallentaa tietoja eri solmuista peer to peer -hajautetulla muotiarkkitehtuurilla.
Kaikki solmut vaihtavat tietoja keskenään käyttämällä Juoruprotokolla. Juorut ovat protokolla Cassandra joiden avulla solmut voivat kommunikoida keskenään.
Komponentit Cassandra Archirakenne
Siinä on seuraavat komponentit Cassandra Archirakenne:
Yllä oleva kaavio sisäkkäisiä komponentteja: solmut sijaitsevat datakeskuksen sisällä, datakeskukset sijaitsevat klusterin sisällä ja commit-loki, memtable ja SSTable sijaitsevat jokaisen yksittäisen solmun sisällä.
Solmu
Solmu on paikka, johon tiedot tallennetaan. Se on peruskomponentti Cassandra.
Data Center
Solmujen kokoelmaa kutsutaan datakeskukseksi. Monet solmut on luokiteltu tietokeskuksiksi.
Cluster
Klusteri on monien datakeskusten kokoelma.
Sitoumusloki
Jokainen kirjoitustoiminto kirjoitetaan toimituslokiin. Toimituslokia käytetään kaatumisen palauttamiseen.
Muistipöytä
Toimituslokiin kirjoitetun tiedon jälkeen tiedot kirjoitetaan Mem-taulukkoon. Tiedot kirjoitetaan väliaikaisesti Mem-taulukkoon.
SSTable
Kun Mem-taulukko saavuttaa tietyn kynnyksen, tiedot tyhjennetään SSTable-levytiedostoon. SSTable-taulukot ovat muuttumattomia, joten päivitys kirjoittaa uuden version vanhan version muokkaamisen sijaan, ja taustalla suoritettava prosessi, jota kutsutaan tiivistämiseksi, yhdistää nämä versiot ja hylkää korvatut rivit.
Tietojen replikointi sisään Cassandra
Koska laitteisto-ongelma tai linkki voi olla poissa milloin tahansa tietojenkäsittelyn aikana, tarvitaan ratkaisu varmuuskopion luomiseksi, kun ongelma on ilmennyt. Joten tiedot kopioidaan, jotta varmistetaan, ettei yksittäinen vikakohta ole.
Cassandra sijoittaa datakopioita eri solmuihin näiden kahden tekijän perusteella.
- Seuraavan replikan sijoituspaikka määrittää Replikointistrategia.
- Vaikka eri solmuihin sijoitettujen replikoiden kokonaismäärä määräytyy Replikointitekijä.
Yksi replikointitekijä tarkoittaa, että tiedoista on vain yksi kopio, kun taas kolme replikointitekijää tarkoittaa, että tiedoista on kolme kopiota kolmessa eri solmussa.
Varmistaakseen, että ei ole yhtä vikakohtaa, replikointitekijän on oltava kolme.
Siinä on kahdenlaisia replikointistrategioita Cassandra.
SimpleStrategy sisään Cassandra
Yksinkertainen strategia käytetään, kun sinulla on vain yksi datakeskus. SimpleStrategy sijoittaa ensimmäisen replikan osioinnin valitsemaan solmuun. Sen jälkeen loput replikat sijoitetaan myötäpäivään solmurenkaaseen.
Tässä on kuvallinen esitys SimpleStrategysta:
NetworkTopologyStrategy sisään Cassandra
NetworkTopologyStrategy käytetään, kun sinulla on enemmän kuin kaksi datakeskusta. NetworkTopologyStrategyssa kopiot asetetaan jokaiselle datakeskukselle erikseen. NetworkTopologyStrategy sijoittaa replikat myötäpäivään renkaaseen, kunnes se saavuttaa toisen telineen ensimmäisen solmun. Tämä strategia yrittää sijoittaa replikoita eri telineisiin samassa palvelinkeskuksessa.
Tämä johtuu siitä, että telineessä voi joskus ilmetä vika tai ongelma. Sitten muiden solmujen replikat voivat tarjota tietoja.
Tässä on kuvallinen esitys verkkotopologiastrategiasta:
Replikaatiokerroin määrää, kuinka monta kopiota on olemassa. Se, kuinka monen näistä kopioista on vastattava tiettyyn pyyntöön, on erillinen asetus, jota kuvataan seuraavaksi.
Johdonmukaisuustasot Cassandra
Yhdenmukaisuustaso asetetaan kyselykohtaisesti eikä klusterikohtaisesti, mikä tekee siitä Cassandra viritettävä. Se määrittää, kuinka monen replikan on kuitattava kirjoitus tai vastattava lukuun, ennen kuin koordinaattori vastaa asiakkaalle. Matala taso palauttaa nopeammin; korkea taso palauttaa tietoja, jotka ovat varmasti ajankohtaisempia.
| Taso | Käyttäytyminen | Tyypillinen käyttö |
|---|---|---|
| ONE | Yhden kopion on vastattava. | Suuritehoinen lokikirjaus, jossa satunnainen vanhentunut luku on hyväksyttävä. |
| PÄIVÄYS | Kaikista replikoista enemmistön on vastattava, laskettuna kaavalla (RF / 2) + 1. | Yleiskäyttöinen valinta tasapainoisen johdonmukaisuuden ja saatavuuden kannalta. |
| PAIKALLINEN_PÄÄTÖSMÄYS | Suurimman osan paikallisen datakeskuksen replikoista on vastattava. | Usean datakeskuksen klusterit, koska se välttää alueiden välisen viiveen. |
| KAIKKI | Jokaisen kopion on vastattava. | Harvinainen. Yksi solmun kaatuminen aiheuttaa pyynnön täydellisen epäonnistumisen. |
| KAIKKI (vain kirjoitusoikeudet) | Vihjeellä tehty vaihto lasketaan onnistuneeksi, vaikka replikaan ei olisikaan yhteyttä. | Maksimaalinen kirjoitusapu, jossa kestävyydestä voidaan tinkiä. |
Vahva johdonmukaisuus on taattu, kun luku- ja kirjoitustason summa ylittää replikointikertoimen. Replikointikertoimen ollessa kolme QUORUM-tasolla kirjoittaminen ja QUORUM-tasolla lukeminen täyttävät tämän säännön, koska kaksi ynnä kaksi on suurempi kuin kolme. YKSI-tasolla kirjoittaminen ja YKSI-tasolla lukeminen eivät täyty, ja luku voi siksi palauttaa vanhemman arvon.
Kun replikaan ei saada yhteyttä, koordinaattori tallentaa vihje ja toistaa sen uudelleen, kun solmu palaa, mikä on tapa, jolla MIKÄ TAHANSA taso ja suuri osa siitä Cassandran itseään parantava käyttäytymismalli toimii.
Kirjoittaa Operavuonna Cassandra
Koordinaattori lähettää kopioille kirjoituspyynnön. Jos kaikki kopiot ovat valmiina, ne saavat kirjoituspyynnön johdonmukaisuustasosta riippumatta.
Johdonmukaisuustaso määrittää, kuinka monta solmua vastaa onnistumisvahvistuksella.
Solmu vastaa onnistumiskuittauksella, jos tiedot kirjoitetaan onnistuneesti toimituslokiin ja muistitaulukko.
Esimerkiksi yhdessä datakeskuksessa, jonka replikointikerroin on kolme, kolme replikaa vastaanottaa kirjoituspyynnön. Jos johdonmukaisuustaso on yksi, vain yksi replika vastaa onnistumisilmoituksella, ja loput kaksi pysyvät lepotilassa.
Oletetaan, että kaksi jäljellä olevaa replikaa menettää tietoja solmujen laskun tai muun ongelman vuoksi, Cassandra tekee rivistä yhtenäisen sisäänrakennetun korjausmekanismin ansiosta Cassandra.
Tässä selitetään, kuinka kirjoitusprosessi tapahtuu Cassandra,
- Kun solmulle tulee kirjoituspyyntö, se kirjautuu ensin toimituslokiin.
- Sitten Cassandra kirjoittaa tiedot mem-taulukkoon. Jokaisen kirjoituspyynnön mem-taulukkoon kirjoitetut tiedot kirjoitetaan myös toimituslokiin erikseen. Mem-taulukko on väliaikaisesti muistiin tallennettu tieto, kun taas Commit log kirjaa tapahtumatietueet varmuuskopiointia varten.
- Kun muistitaulukko on täynnä, tiedot huuhdellaan SSTable-datatiedostoon.
Koska SSTable-taulukoita ei koskaan muokata paikan päällä, poisto ei poista riviä välittömästi. Sen sijaan käytetään merkkiä, jota kutsutaan nimellä hautakivi kirjoitetaan, ja rivi katoaa vasta, kun pakkaus suoritetaan lisäajan jälkeen. Tästä syystä suuret poistotyömäärät hidastavat lukemista, kunnes pakkaus saavuttaa sen.
Lue Operavuonna Cassandra
Koordinaattori lähettää replikoihin kolmenlaisia lukupyyntöjä.
- Suora pyyntö
- Tiivistelmäpyyntö
- Lue korjauspyyntö
Koordinaattori lähettää suoran pyynnön yhdelle replikoista. Tämän jälkeen koordinaattori lähettää tiivistelmäpyynnön johdonmukaisuustason määrittämälle määrälle replikoita ja tarkistaa, onko palautettu data päivitettyä dataa.
Tämän jälkeen koordinaattori lähettää tiivistelmäpyynnön kaikille jäljellä oleville replikoille. Jos jokin solmu antaa vanhentuneen arvon, taustalukukorjauspyyntö päivittää tiedot. Tätä prosessia kutsutaan lukukorjausmekanismiksi.
Suoran pyynnön vastaanottavan replikan sisällä hakujärjestys on suunniteltu siten, että levylle ei kosketa aina kun mahdollista.
- muistitaulukko tarkistetaan ensin, koska uusimpia kirjoitustöitä ei ole vielä tyhjennetty.
- rivivälimuisti, jos käytössä, voi vastata koko pyyntöön ilman lisätoimia.
- A kukintasuodatin kyselyä käytetään jokaisen SSTable-taulukon kohdalla. Se vastaa joko definitely not present tai possibly present, minkä ansiosta useimmat SSTable-taulukot voidaan ohittaa lukematta niitä.
- osioindeksi ja sen yhteenveto paikantavat tarkan tavuoffsetin missä tahansa SSTable-taulukossa, joka selviää bloom-suodattimen tarkistuksesta.
- Useiden SSTable-taulukoiden vastaavat fragmentit yhdistetään, ja kunkin sarakkeen viimeisin aikaleima voittaa.
Bloom-suodatin on vaihe, joka pitää lukemat nopeina datan kasvaessa, koska se poistaa lähes kaikki SSTable-taulukot huomioon ottaen ennen levyn hakua. Näiden mekaniikoiden soveltamista useissa koneissa käsitellään seuraavassa. Cassandra klusteri opetusohjelma.
