4.1 Beskrivning

Apache Cassandra är ett distribuerat databashanteringssystem som tillhör klassen av NoSQL-system och är designat för att skapa mycket skalbara och pålitliga lagringar av enorma datamatriser som presenteras i form av en hash.

Inledningsvis utvecklades projektet i inälvorna av Facebook och 2009 överfördes under Apache Software Foundations vingar, denna organisation fortsätter att utveckla projektet. Industriella lösningar baserade på Cassandra används för att tillhandahålla tjänster till företag som Cisco, IBM, Cloudkick, Reddit, Digg, Rackspace, Huawei, Netflix, Apple, Instagram, GitHub, Twitter och Spotify. År 2011 hade det största serverklustret som betjänade en enda databas under Cassandra mer än 400 maskiner och innehöll mer än 300 TB data.

Skrivet på Java-språket implementerar det ett distribuerat hashsystem som liknar DynamoDB, vilket ger nästan linjär skalbarhet med ökande datavolym. Den använder en datalagringsmodell baserad på en familj av kolumner, som skiljer sig från system som MemcacheDB, som endast lagrar data i ett nyckel-värdepar, genom möjligheten att lagra hash med flera nivåer av kapsling.

Tillhör kategorin feltolerant DBMS: data som placeras i databasen replikeras automatiskt till flera noder i ett distribuerat nätverk eller till och med jämnt fördelat i flera datacenter. När en nod misslyckas, plockas dess funktioner upp i farten av andra noder, nya noder läggs till i klustret och uppdatering av Cassandra-versionen görs direkt, utan ytterligare manuell intervention och omkonfigurering av andra noder.

Det rekommenderas dock starkt att återskapa nycklar (etiketter) för varje nod, inklusive befintliga, för att bevara kvaliteten på lastbalanseringen. Nyckelgenerering för befintliga noder kan undvikas i fallet med en multipel ökning av antalet noder (2 gånger, 3 gånger, och så vidare).

4.2 Datamodell

I Cassandra-terminologin arbetar en applikation med ett tangentutrymme, vilket motsvarar konceptet med ett databasschema i relationsmodellen. Detta tangentutrymme kan innehålla flera kolumnfamiljer, vilket motsvarar konceptet med en relationstabell.

I sin tur innehåller kolumnfamiljer kolumner (kolumn), som kombineras med nyckeln (radnyckel) i posten (raden). Kolumnen består av tre delar: namn (kolumnnamn), tidsstämpel (tidsstämpel) och värde (värde). Kolumnerna i en post är ordnade. Till skillnad från en relationsdatabas finns det inga begränsningar för om poster (och vad gäller databasen är dessa rader) innehåller kolumner med samma namn som i andra poster - nej.

Kolumnfamiljer kan vara av flera slag, men i den här artikeln kommer vi att utelämna denna detalj. Även i de senaste versionerna av Cassandra blev det möjligt att utföra frågor för att definiera och ändra data (DDL, DML) med CQL-språket, samt skapa sekundära index.

Det specifika värdet som lagras i cassandra identifieras av:

  • keyspace är en bindning till applikationen (domänen). Låter dig vara värd för data från olika applikationer i samma kluster;
  • en kolumnfamilj är en bindning till en fråga;
  • nyckeln är en bindning till en klusternod. Nyckeln bestämmer vilka noder de sparade kolumnerna kommer att hamna på;
  • kolumnnamn är en bindning till ett attribut i posten. Låter dig lagra flera värden i en post.

Varje värde är associerat med en tidsstämpel, ett användarspecificerat nummer som används för att lösa konflikter under inspelning: ju större siffra, desto nyare kolumn beaktas, och när den jämförs skriver den över gamla kolumner.

4.3 Datatyper

Efter datatyper: tangentutrymme och kolumnfamilj är strängar (namn); tidsstämpel är ett 64-bitars nummer; och nyckeln, kolumnnamnet och kolumnvärdet är en array av byte. Cassandra har också konceptet med datatyper. Dessa typer kan specificeras (valfritt) av utvecklaren när en kolumnfamilj skapas.

För kolumnnamn kallas detta en komparator, för värden och nycklar kallas det en validator. Den första definierar vilka bytevärden som är tillåtna för kolumnnamn och hur man beställer dem. Det andra är vilka bytevärden som är giltiga för kolumn- och nyckelvärden.

Om dessa datatyper inte är inställda, lagrar cassandra värdena och jämför dem som bytesträngar (BytesType) eftersom de faktiskt lagras internt.

Datatyperna är:

  • BytesType : alla bytesträngar (ingen validering)
  • AsciiType : ASCII-sträng
  • UTF8Typ : UTF-8-sträng
  • IntegerType : tal med godtycklig storlek
  • Int32Type : 4-byte nummer
  • LongType : 8-byte nummer
  • UUIDTyp : UUID typ 1 eller 4
  • TimeUUIDType : Typ 1 UUID
  • DateType : 8-byte tidsstämpelvärde
  • BooleanType : två värden: true = 1 eller false = 0
  • FloatType : 4-byte flyttal
  • DoubleType : 8-byte flyttal
  • DecimalType : ett tal med en godtycklig storlek och en flyttal
  • CounterColumnType : 8 byte räknare

I Cassandra är alla dataskrivningsoperationer alltid omskrivningsoperationer, det vill säga om en kolumn med samma nyckel och namn som redan finns kommer till kolumnfamiljen, och tidsstämpeln är större än den som sparas, så skrivs värdet över . De registrerade värdena ändras aldrig, bara nyare kolumner kommer in med nya värden.

Att skriva till Cassandra är snabbare än att läsa. Detta förändrar det tillvägagångssätt som tas i designen. Om vi ​​betraktar Cassandra ur synvinkeln att designa en datamodell, är det lättare att föreställa sig en kolumnfamilj inte som en tabell, utan som en materialiserad vy - en struktur som representerar data från en komplex fråga, men lagrar den på disk.

Istället för att försöka komponera data på något sätt med hjälp av frågor, är det bättre att försöka lagra allt som kan behövas för denna fråga i målfamiljen. Det vill säga, det är nödvändigt att inte närma sig från sidan av relationer mellan enheter eller relationer mellan objekt, utan från sidan av frågor: vilka fält måste väljas; i vilken ordning journalerna ska gå; vilka data relaterade till de viktigaste bör begäras tillsammans - allt detta bör redan lagras i kolumnfamiljen.

Antalet kolumner i en post är teoretiskt begränsat till 2 miljarder. Detta är en kort avvikelse, och mer information finns i artikeln om design och optimeringstekniker. Och låt oss nu fördjupa oss i processen att spara data till Cassandra och läsa den.