för mer information om uthållighet i Cassandra och andra NoSQL-databaser, kolla in vad är NoSQL?
att förstå betydelsen av uthållighet är viktigt för att utvärdera olika datalagringssystem. Med tanke på datalagrets betydelse i de flesta moderna applikationer kan ett dåligt informerat val innebära betydande driftstopp eller förlust av data. I det här inlägget diskuterar vi uthållighet och datalagringsdesignmetoder och ger lite bakgrund om dessa i samband med Cassandra.
Persistens är ”fortsättningen av en effekt efter att dess orsak har tagits bort”. I samband med lagring av data i ett datorsystem betyder det att data överlever efter att processen med vilken den skapades har avslutats. Med andra ord, för att en datalagring ska betraktas som beständig måste den skriva till icke-flyktig lagring.
om du behöver uthållighet i ditt datalager måste du också förstå de fyra mandesignmetoder som ett datalager kan ta och hur (eller om) dessa mönster ger uthållighet:
-
ren i minnet, ingen uthållighet alls, såsom memcaches eller Scalaris
-
i minnet med periodiska ögonblicksbilder, till exempel Oracle Coherence eller Redis
-
diskbaserad med uppdatering på plats skriver, till exempel MySQL ISAM eller MongoDB
-
Commitlog-baserade, till exempel alla traditionella OLTP-databaser (Oracle, SQL Server, etc.)
in-memory tillvägagångssätt kan uppnå blixtsnabb hastighet, men på bekostnad av att vara begränsad till en relativt liten datamängd. De flesta arbetsbelastningar har relativt små ”heta” (aktiva) delmängder av deras totala data; system som kräver att hela datset passar i minnet snarare än bara den aktiva delen är bra för cachar men en dålig passform för de flesta andra applikationer. Eftersom data endast finns i minnet kommer det inte att överleva processavslutningen. Därför anses dessa typer av datalager inte vara beständiga.
det enklaste sättet att lägga till uthållighet i ett minnessystem är med periodiska ögonblicksbilder till disk med ett konfigurerbart intervall. Således kan du förlora upp till det intervallets värde av uppdateringar.
Update-in-place och commitlog-baserade system lagrar till icke-flyktigt minne omedelbart, men endast commitlog-baserad uthållighet ger hållbarhet-D i syra-med varje skrivning kvarstod innan framgång returneras till klienten.
Cassandra implementerar en commit-log baserad uthållighet design, men samtidigt ger för avstämbara nivåer av hållbarhet. Detta gör att du bestämmer vad rätt avvägning är mellan säkerhet och prestanda. Du kan välja, för varje skrivoperation, att vänta på att uppdateringen ska buffras till minnet, skrivas till disk på en enda maskin, skrivas till disk på flera maskiner eller till och med skrivas till disk på flera maskiner i olika datacenter. Eller, du kan välja att acceptera skriver en snabbt som möjligt, bekräfta mottagandet omedelbart innan de ens har helt deserialized från nätverket.
i slutet av dagen är du den enda som vet vad rätt prestanda/hållbarhet avvägning är för dina data. Att fatta ett välgrundat beslut om datalagringsteknik är avgörande för att ta itu med denna avvägning på dina villkor. Eftersom Cassandra ger en sådan avstämbarhet är det ett logiskt val för system med behov av en hållbar datalagring.