Cassandra Datamodell med enkelt databasexempel

Även Cassandra frågespråk liknar SQL språk, är deras datamodelleringsmetoder helt olika.

In Cassandra, kan en dålig datamodell försämra prestandan, särskilt när användare försöker implementera RDBMS-koncepten på Cassandra. Det är bäst att tänka på några regler som beskrivs nedan.

Cassandra Datamodellregler

In Cassandra, skriver är inte dyra. Cassandra stöder inte joins, group by, OR-klausul, aggregering etc. Så du måste lagra dina data på ett sådant sätt att de ska vara helt återtagbara. Så dessa regler måste hållas i åtanke när data modelleras in Cassandra.

Maximera antalet skrivningar

In Cassandra, skriver är mycket billiga. Cassandra är optimerad för hög skrivprestanda. Så försök att maximera dina skrivningar för bättre läsprestanda och datatillgänglighet. Det finns en avvägning mellan dataskrivning och dataläsning. Så optimera din dataläsprestanda genom att maximera antalet dataskrivningar.

Maximera dataduplicering

Datadenormalisering och dataduplicering är defacto of Cassandra. Diskutrymme är inte dyrare än minne, CPU-bearbetning och IO-drift. Som Cassandra är en distribuerad databas, så dataduplicering ger omedelbar datatillgänglighet och ingen enskild felpunkt.

Cassandra Datamodelleringsmål

Du bör ha följande mål när du modellerar in data Cassandra:

Sprid data jämnt runt Cluster

Du vill ha lika mycket data på varje nod av Cassandra ClusterData sprids till olika noder baserat på partitionsnycklar som är den första delen av primärnyckeln. Försök därför att välja en kolumn med hög kardinalitet som partitionsnyckel för att sprida data jämnt runt klustret.

Minimera antalet partitioner som läses när du frågar efter data

Partition är en grupp poster med samma partitionsnyckel. När läsfrågan utfärdas samlar den in data från olika noder från olika partitioner.

Om det kommer att finnas många partitioner, måste alla dessa partitioner besökas för att samla in frågedata.

Det betyder inte att partitioner inte ska skapas. Om dina data är väldigt stora kan du inte lagra den enorma mängden data på en enda partition. Den enskilda partitionen kommer att bli långsammare.

Så försök att välja ett balanserat antal partitioner.

Bra primär nyckel in Cassandra

Båda målen ovan handlar om ett enda beslut, så de två scheman nedan visar samma tabell med en dålig nyckel och sedan en sund.

Låt oss ta ett exempel och hitta vilken primärnyckel som är bra.

Här är tabellen MusicPlaylist.

CREATE TABLE MusicPlaylist (
    SongId int,
    SongName text,
    Year int,
    Singer text,
    PRIMARY KEY (SongId, SongName)
);

I exemplet ovan, tabellen MusicPlaylist,

• SongId är partitionsnyckeln, och
• SongName är klustringskolumnen
• Data kommer att klustras baserat på SongName. Endast en partition kommer att skapas per SongId, och eftersom varje låt har en distinkt identifierare innehåller varje partition en enda rad.

Datainhämtningen kommer att gå långsamt av denna datamodell på grund av den dåliga primärnyckeln.

Här är en annan tabell MusicPlaylist.

CREATE TABLE MusicPlaylist (
    SongId int,
    SongName text,
    Year int,
    Singer text,
    PRIMARY KEY ((SongId, Year), SongName)
);

I exemplet ovan, tabellen MusicPlaylist,

• SongId och Year är partitionsnyckeln, och
• SongName är klustringskolumnen.
• Data kommer att klustras på basis av SongName. I den här tabellen kommer en ny partition att skapas varje år. Alla årets låtar kommer att vara på samma nod. Denna primära nyckel kommer att vara mycket användbar för data.

Vår datahämtning kommer att gå snabbt med denna datamodell.

Modellera dina data i Cassandra

Följande saker bör tänkas på när du modellerar dina frågor:

Bestäm vilka frågor du vill stödja

Bestäm först och främst vilka frågor du vill ha.

Behöver du till exempel?

• Fogar
• Grupp av
• Filtrera på vilken kolumn osv.

Skapa tabell enligt dina frågor

Skapa tabell enligt dina frågor. Skapa en tabell som kommer att tillfredsställa dina frågor. Försök att skapa en tabell på ett sådant sätt att ett minimum antal partitioner behöver läsas.

De tre avsnitten som följer tillämpar den principen på de tre relationstyper som finns i nästan alla scheman.

Hantera ett till ett förhållande i Cassandra

En till en relation betyder att två tabeller har en till en korrespondens. Studenten kan till exempel bara registrera en kurs, och jag vill söka på en student som i vilken kurs en viss student är registrerad i.

Så i det här fallet bör ditt tabellschema omfatta alla detaljer om studenten som motsvarar den specifika kursen som kursens namn, elevens rollnummer, studentnamn, etc.

Diagrammet ovan visar en enda tabell som hanterar frågan, eftersom en student mappas till exakt en kurs.

CREATE TABLE Student_Course (
    Student_rollno int PRIMARY KEY,
    Student_name text,
    Course_name text
);

Eftersom Student_rollno är partitionsnyckeln, läser en sökning efter rullnummer exakt en partition.

Hantera ett till många förhållande i Cassandra

En till många relationer innebär att ha en till många överensstämmelse mellan två tabeller.

Till exempel kan en kurs läsas av många studenter. Jag vill söka efter alla studenter som läser en viss kurs.

Så genom att fråga efter kursnamn kommer jag att ha många studentnamn som kommer att studera en viss kurs.

Här blir kursnamnet partitionsnyckeln så att varje student på en kurs hamnar i samma partition, och rullnumret blir klusterkolumnen så att varje student förblir en distinkt rad.

CREATE TABLE Student_Course (
    Course_name text,
    Student_rollno int,
    Student_name text,
    PRIMARY KEY (Course_name, Student_rollno)
);

Jag kan hämta alla elever för en viss kurs genom följande fråga.

SELECT * FROM Student_Course WHERE Course_name = 'Course Name';

Hantera många till många relationer i Cassandra

Många till många relationer innebär att ha många till många korrespondens mellan två tabeller.

Till exempel kan en kurs läsas av många studenter, och en student kan också läsa många kurser.

Jag vill söka efter alla studenter som läser en viss kurs. Jag vill också söka igenom hela kursen som en viss student läser.

Så i det här fallet kommer jag att ha två tabeller, dvs. dela upp problemet i två fall. Detta är den tydligaste illustrationen av dupliceringsregeln: samma fakta skrivs två gånger så att varje fråga läser en partition.

Först kommer jag att skapa en tabell där du kan hitta kurser av en viss student.

CREATE TABLE Student_Course (
    Student_rollno int,
    Course_name text,
    Student_name text,
    PRIMARY KEY (Student_rollno, Course_name)
);

Jag kan hitta alla kurser av en viss student genom följande fråga.

SELECT * FROM Student_Course WHERE Student_rollno = 101;

För det andra kommer jag att skapa en tabell där du kan se hur många studenter som läser en viss kurs.

CREATE TABLE Course_Student (
    Course_name text,
    Student_rollno int,
    Student_name text,
    PRIMARY KEY (Course_name, Student_rollno)
);

Jag kan hitta en student i en viss kurs genom följande fråga.

SELECT * FROM Course_Student WHERE Course_name = 'Cassandra';

Båda tabellerna måste skrivas till varje gång en student går med i en kurs, normalt inom en enda loggad batch så att de två kopiorna hålls i takt.

Gemensam Cassandra Misstag i datamodellering

De flesta dåliga scheman upprepar samma handfull fel, och varje tracgår tillbaka till en vana som är hämtad från relationell design.

• Obegränsade partitioner: Att välja en partitionsnyckel, till exempel ett landsnamn, placerar miljontals rader i en partition. Lägg till en tidsperiod, till exempel (land, månad), för att hålla partitionerna inom en rimlig storlek.
• Nycklar med mycket låg kardinalitet: En partitionsnyckel med endast ett fåtal möjliga värden, till exempel en statusflagga, koncentrerar all trafik till ett fåtal noder och lämnar resten inaktiv.
• Använda ALLOW FILTERING för att få en fråga att fungera: Den skannar varje partition och döljer ett modelleringsproblem. Om en fråga behöver det behöver schemat en annan tabell.
• Modellera entiteter istället för frågor: Att bygga en studenttabell och en kurstabell, och sedan försöka koppla ihop dem i applikationen, omintetgör syftet med designen.
• Ofta förekommande borttagningar och överskrivningar: Varje borttagning skriver en tombstone som måste läsas och hoppas över tills komprimering tar bort den, vilket saktar ner läsningar på heta partitioner.

Genom att undvika dessa bibehålls schemat i linje med reglerna som anges högst upp på denna sida, och med de relationella kontraster som sammanfattas nedan.

Skillnaden mellan RDBMS och Cassandra Datamodellering

Dessa schemabeslut tillämpas i praktiken i Cassandra bord och tangentutrymme Handledningar.

Vanliga frågor