Apache Cassandra: lagring af data i en klynge

5.1 Datadistribution

Lad os overveje, hvordan dataene fordeles afhængigt af nøglen blandt klyngeknuderne. Cassandra giver dig mulighed for at indstille en datadistributionsstrategi. Den første sådan strategi distribuerer data afhængigt af md5 nøgleværdien - en tilfældig partitioner. Den anden tager højde for bitrepræsentationen af ​​selve nøglen - den ordinære markup (byte-ordnet partitioner).

Den første strategi giver for det meste flere fordele, da du ikke behøver at bekymre dig om jævn fordeling af data mellem servere og sådanne problemer. Den anden strategi bruges i sjældne tilfælde, for eksempel hvis intervalforespørgsler (range scan) er nødvendige. Det er vigtigt at bemærke, at valget af denne strategi er foretaget før oprettelsen af ​​klyngen og faktisk ikke kan ændres uden en fuldstændig genindlæsning af dataene.

Cassandra bruger en teknik kendt som konsekvent hashing til at distribuere data. Denne tilgang giver dig mulighed for at distribuere data mellem noder og sikre dig, at når en ny node tilføjes og fjernes, er mængden af ​​overførte data lille. For at gøre dette tildeles hver node en etiket (token), som opdeler sættet af alle md5-nøgleværdier i dele. Da RandomPartitioner bruges i de fleste tilfælde, lad os overveje det.

Som sagt beregner RandomPartitioner en 128-bit md5 for hver nøgle. For at bestemme, i hvilke noder dataene vil blive lagret, gennemgår den simpelthen alle nodernes etiketter fra mindste til største, og når værdien af ​​etiketten bliver større end værdien af ​​md5-nøglen, så vil denne node sammen med en antallet af efterfølgende noder (i rækkefølgen af ​​etiketter) vælges til opbevaring. Det samlede antal valgte noder skal være lig med replikationsfaktoren. Replikeringsniveauet indstilles for hvert tasterum og giver dig mulighed for at justere redundansen af ​​data (dataredundans).

Før en node kan tilføjes til klyngen, skal den have en etiket. Procentdelen af ​​nøgler, der dækker afstanden mellem denne etiket og den næste, bestemmer, hvor meget data der vil blive gemt på noden. Hele sættet af etiketter til en klynge kaldes en ring.

Her er en illustration, der bruger det indbyggede nodetool-værktøj til at vise en klyngering med 6 noder med jævnt fordelte etiketter.

5.2 Datakonsistens ved skrivning

Cassandra cluster noder er ækvivalente, og klienter kan oprette forbindelse til enhver af dem, både til skrivning og læsning. Forespørgsler går gennem koordinationsstadiet, hvor serveren, efter at have fundet ud af ved hjælp af nøglen og markeringen, på hvilke noder dataene skal være placeret, sender anmodninger til disse noder. Vi vil kalde den node, der udfører koordineringen, for koordinatoren , og de noder, der er valgt til at gemme posten med den givne nøgle, replika noderne. Fysisk kan en af ​​replikaknuderne være koordinatoren - det afhænger kun af nøglen, opmærkningen og etiketterne.

For hver anmodning, både til læsning og skrivning, er det muligt at indstille niveauet for datakonsistens.

For en skrivning vil dette niveau påvirke antallet af replika-noder, der vil vente på bekræftelse af en vellykket gennemførelse af operationen (data skrevet), før kontrollen returneres til brugeren. For en ordens skyld er der disse konsistensniveauer:

• ET - koordinatoren sender anmodninger til alle replika noder, men efter at have ventet på bekræftelse fra den første node, returnerer kontrollen til brugeren;
• TO - det samme, men koordinatoren venter på bekræftelse fra de to første knudepunkter, før han returnerer kontrol;
• TRE - lignende, men koordinatoren venter på bekræftelse fra de første tre knudepunkter, før han returnerer kontrol;
• KVORUM - et kvorum er indsamlet: koordinatoren venter på bekræftelse af posten fra mere end halvdelen af ​​replikaknuderne, nemlig runde (N / 2) + 1, hvor N er replikationsniveauet;
• LOCAL_QUORUM - Koordinatoren venter på bekræftelse fra mere end halvdelen af ​​replikaknuderne i det samme datacenter, hvor koordinatoren er placeret (potentielt forskellig for hver anmodning). Giver dig mulighed for at slippe af med de forsinkelser, der er forbundet med at sende data til andre datacentre. Problemerne med at arbejde med mange datacentre behandles i denne artikel i forbifarten;
• EACH_QUORUM - Koordinatoren venter på bekræftelse fra mere end halvdelen af ​​replikaknuderne i hvert datacenter, uafhængigt af hinanden;
• ALLE - koordinatoren venter på bekræftelse fra alle replika-noder;
• ANY - gør det muligt at skrive data, selvom alle replika noder ikke reagerer. Koordinatoren venter enten på det første svar fra en af ​​replikaknuderne eller på, at dataene bliver gemt ved hjælp af en antydet overdragelse på koordinatoren.

5.3 Datakonsistens ved læsning

For aflæsninger vil konsistensniveauet påvirke antallet af replika-noder, der vil blive læst fra. Til læsning er der disse konsistensniveauer:

• ET - koordinatoren sender anmodninger til den nærmeste replikaknude. Resten af ​​replikaerne læses også til læst reparation med den sandsynlighed, der er angivet i cassandra-konfigurationen;
• TO er ens, men koordinatoren sender anmodninger til de to nærmeste knudepunkter. Værdien med det største tidsstempel vælges;
• TRE - svarende til den tidligere mulighed, men med tre noder;
• KVORUM - et kvorum opsamles, det vil sige, at koordinatoren sender anmodninger til mere end halvdelen af ​​replikaknuderne, nemlig runde (N / 2) + 1, hvor N er replikationsniveauet;
• LOCAL_QUORUM - et quorum indsamles i det datacenter, hvori koordineringen finder sted, og dataene med det seneste tidsstempel returneres;
• EACH_QUORUM - Koordinatoren returnerer data efter mødet med beslutningsdygtighed i hvert af datacentrene;
• ALLE - Koordinatoren returnerer data efter læsning fra alle replika-noder.

Det er således muligt at justere tidsforsinkelserne for læse- og skriveoperationer og justere konsistensen (tune-konsistensen), såvel som tilgængeligheden (tilgængeligheden) af hver type operation. Faktisk er tilgængelighed direkte relateret til konsistensniveauet for læsninger og skrivninger, da det bestemmer, hvor mange replika-noder, der kan gå ned og stadig blive bekræftet.

Hvis antallet af noder, som skrivebekræftelsen kommer fra, plus antallet af noder, hvorfra læsningen foretages, er større end replikationsniveauet, så har vi en garanti for, at den nye værdi altid vil blive læst efter skrivningen, og dette kaldes stærk konsistens (stærk konsistens). I mangel af stærk konsistens er der en mulighed for, at en læseoperation vil returnere forældede data.

Under alle omstændigheder vil værdien til sidst forplante sig mellem replikaer, men først efter at koordinationsventen er afsluttet. Denne udbredelse kaldes eventuel konsistens. Hvis ikke alle replika-noder er tilgængelige på tidspunktet for skrivningen, vil før eller senere gendannelsesværktøjer såsom afhjælpende læsninger og anti-entropi-knudereparation komme i spil. Mere om dette senere.

Med et QUORUM læse- og skrivekonsistensniveau vil stærk konsistens således altid blive opretholdt, og dette vil være en balance mellem læse- og skrivelatens. Med ALLE skrivninger og EN læsninger vil der være stærk konsistens, og læsninger vil være hurtigere og mere tilgængelige, dvs. antallet af mislykkede noder, hvor en læsning stadig vil blive afsluttet, kan være større end med QUORUM.

For skriveoperationer kræves alle replika-arbejderknudepunkter. Når man skriver ONE, læser ALLE, vil der også være streng konsistens, og skriveoperationer vil være hurtigere, og skrivetilgængeligheden vil være stor, fordi det vil være nok til kun at bekræfte, at skriveoperationen fandt sted på mindst én af serverne, mens læsning er langsommere og kræver alle replika noder. Hvis en applikation ikke har et krav om streng konsistens, så er det muligt at fremskynde både læse- og skriveoperationer, samt forbedre tilgængeligheden ved at indstille lavere konsistensniveauer.