For mere information om persistens i Cassandra og andre noskl databaser, tjek hvad er Noskl?
at forstå betydningen af vedholdenhed er vigtig for evaluering af forskellige datalagringssystemer. I betragtning af vigtigheden af datalageret i de fleste moderne applikationer kan et dårligt informeret valg betyde betydelig nedetid eller tab af data. I dette indlæg vil vi diskutere Persistens og datalagerdesignmetoder og give en vis baggrund for disse i forbindelse med Cassandra.
persistens er “fortsættelsen af en effekt efter dens årsag er fjernet”. I forbindelse med lagring af data i et computersystem betyder det, at dataene overlever, efter at processen, som de blev oprettet med, er afsluttet. Med andre ord, for at en datalager skal betragtes som vedvarende, skal den skrive til ikke-flygtig lagring.
hvis du har brug for vedholdenhed i din datalager, skal du også forstå de fire mand design tilgange, som en datalager kan tage, og hvordan (eller hvis) disse designs giver vedholdenhed:
-
ren i hukommelsen, ingen vedholdenhed overhovedet, såsom memcaches eller Scalaris
-
In-hukommelse med periodiske snapshots, såsom Oracle Coherence eller Redis
-
Disk-baseret med update-in-place skriver, såsom
-
Commitlog-baseret, såsom alle traditionelle OLTP-databaser (Oracle, server osv.)
in-memory tilgange kan opnå flammende hastighed, men på bekostning af at være begrænset til et relativt lille datasæt. De fleste arbejdsbelastninger har relativt lille “hot” (aktiv) delmængde af deres samlede data; systemer, der kræver, at hele datsættet passer i hukommelsen snarere end kun den aktive del, er fine til cacher, men en dårlig pasform til de fleste andre applikationer. Da dataene kun er i hukommelsen, overlever de ikke procesafslutning. Derfor betragtes disse typer datalagre ikke som vedvarende.
den nemmeste måde at tilføje persistens til et in-memory-system er med periodiske snapshots til disk med et konfigurerbart interval. Således kan du miste op til det interval værd af opdateringer.
Update-in-place og commitlog-baserede systemer gemmer straks til ikke-flygtig hukommelse, men kun commitlog-baseret persistens giver holdbarhed-D i syre-med hver skrivning vedvarende, før succes returneres til klienten.
Cassandra implementerer et commit-log-baseret persistensdesign, men sørger samtidig for indstillelige niveauer af holdbarhed. Dette giver dig mulighed for at beslutte, hvad den rigtige afvejning er mellem sikkerhed og ydeevne. Du kan vælge, for hver skriveoperation, at vente på, at opdateringen bufferes til hukommelsen, skrives til disk på en enkelt maskine, skrives til disk på flere maskiner eller endda skrives til disk på flere maskiner i forskellige datacentre. Eller, du kan vælge at acceptere skriver en hurtigt som muligt, anerkender deres kvittering umiddelbart før de selv er blevet fuldt deserialiseret fra netværket.
i slutningen af dagen er du den eneste, der ved, hvad den rigtige ydelse/holdbarhed er for dine data. At tage en informeret beslutning om datalagerteknologier er afgørende for at tackle denne afvejning på dine vilkår. Fordi Cassandra giver en sådan tuneability, det er et logisk valg for systemer med et behov for en holdbar, performant datalager.