Cassandra Datamodel med simpelt databaseeksempel

Skønt Cassandra forespørgselssproget ligner SQL sprog, er deres datamodelleringsmetoder helt forskellige.

In Cassandra, kan en dårlig datamodel forringe ydeevnen, især når brugere forsøger at implementere RDBMS-koncepterne på Cassandra. Det er bedst at huske på nogle få regler beskrevet nedenfor.

Cassandra Regler for datamodel

In Cassandra, skriver er ikke dyre. Cassandra understøtter ikke joins, group by, OR-klausul, aggregeringer osv. Du skal altså gemme dine data på en sådan måde, at de skal være fuldstændigt genfindelige. Så disse regler skal huskes, mens data modelleres ind Cassandra.

Maksimer antallet af skrivninger

In Cassandra, skriver er meget billige. Cassandra er optimeret til høj skriveydelse. Så prøv at maksimere dine skrivninger for bedre læseydelse og datatilgængelighed. Der er en afvejning mellem dataskrivning og datalæsning. Så optimer din datalæsningsydelse ved at maksimere antallet af dataskrivninger.

Maksimer dataduplikering

Datadenormalisering og dataduplikering er defacto af Cassandra. Diskplads er ikke dyrere end hukommelse, CPU-behandling og IOs-drift. Som Cassandra er en distribueret database, så dataduplikering giver øjeblikkelig datatilgængelighed og intet enkelt fejlpunkt.

Cassandra Mål for datamodellering

Du bør have følgende mål, mens du modellerer data ind Cassandra:

Fordel data jævnt rundt om Cluster

Du vil have en lige stor mængde data på hver node af Cassandra ClusterData spredes til forskellige noder baseret på partitionsnøgler, som er den første del af primærnøglen. Så prøv at vælge en kolonne med høj kardinalitet som partitionsnøgle for at sprede data jævnt rundt i klyngen.

Minimer antallet af læste partitioner, mens du forespørger data

Partition er en gruppe af poster med den samme partitionsnøgle. Når læseforespørgslen udsendes, indsamler den data fra forskellige noder fra forskellige partitioner.

Hvis der vil være mange partitioner, skal alle disse partitioner besøges for at indsamle forespørgselsdataene.

Det betyder ikke, at partitioner ikke skal oprettes. Hvis dine data er meget store, kan du ikke opbevare den enorme mængde data på den enkelte partition. Den enkelte partition vil blive langsommere.

Så prøv at vælge et afbalanceret antal partitioner.

God primær nøgle ind Cassandra

Begge ovenstående mål handler om én beslutning, så de to skemaer nedenfor viser den samme tabel med en dårlig nøgle og derefter en sund en.

Lad os tage et eksempel og finde ud af, hvilken primærnøgle der er god.

Her er tabellen MusicPlaylist.

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

I ovenstående eksempel, tabellen MusicPlaylist,

• SongId er partitionsnøglen, og
• SongName er klyngekolonnen
• Data vil blive grupperet på basis af SongName. Der oprettes kun én partition pr. SongId, og fordi hver sang har et unikt id, indeholder hver partition en enkelt række.

Datahentning vil være langsom af denne datamodel på grund af den dårlige primærnøgle.

Her er en anden tabel MusicPlaylist.

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

I ovenstående eksempel, tabellen MusicPlaylist,

• SongId og Year er partitionsnøglen, og
• SongName er klyngekolonnen.
• Data vil blive grupperet på basis af SongName. I denne tabel vil der hvert år blive oprettet en ny partition. Alle årets sange vil være på samme node. Denne primære nøgle vil være meget nyttig for dataene.

Vores datahentning vil være hurtig med denne datamodel.

Modellér dine data i Cassandra

Følgende ting skal huskes, når du modellerer dine forespørgsler:

Bestem, hvilke forespørgsler du vil støtte

Først og fremmest skal du bestemme, hvilke forespørgsler du ønsker.

Har du for eksempel brug for?

• Sammenføjninger
• Gruppe af
• Filtrering på hvilken kolonne mv.

Opret tabel i henhold til dine forespørgsler

Opret tabel i henhold til dine forespørgsler. Opret en tabel, der vil tilfredsstille dine forespørgsler. Prøv at oprette en tabel på en sådan måde, at et minimum antal partitioner skal læses.

De tre følgende afsnit anvender dette princip på de tre relationstyper, der findes i næsten alle skemaer.

Håndtering af et-til-én-forhold i Cassandra

En til en relation betyder, at to tabeller har en til en korrespondance. For eksempel kan eleven kun tilmelde ét kursus, og jeg vil søge på en studerende, der i hvilket kursus en bestemt elev er tilmeldt.

Så i dette tilfælde skal dit tabelskema omfatte alle detaljerne om den studerende, der svarer til det pågældende kursus, såsom kursets navn, rullenummer på eleven, elevens navn osv.

Diagrammet ovenfor viser en enkelt tabel, der betjener forespørgslen, fordi én studerende er knyttet til præcis ét kursus.

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

Fordi Student_rollno er partitionsnøglen, læser et opslag efter rullenummer præcis én partition.

Håndtering af et til mange forhold i Cassandra

En til mange relationer betyder at have en til mange korrespondance mellem to tabeller.

For eksempel kan et kursus læses af mange studerende. Jeg vil søge efter alle de studerende, der studerer et bestemt kursus.

Så ved at forespørge på kursusnavnet, vil jeg have mange elevnavne, som vil studere et bestemt kursus.

Her bliver kursusnavnet partitionsnøglen, så alle studerende på et kursus lander i den samme partition, og elevnummeret bliver klyngekolonnen, så hver studerende forbliver en separat række.

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

Jeg kan hente alle eleverne til et bestemt kursus ved følgende forespørgsel.

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

Håndtering af mange til mange forhold i Cassandra

Mange til mange relationer betyder at have mange til mange korrespondance mellem to tabeller.

For eksempel kan et kursus læses af mange studerende, og en studerende kan også læse mange kurser.

Jeg vil søge efter alle de studerende, der studerer et bestemt kursus. Jeg vil også søge i hele det kursus, som en bestemt studerende studerer.

Så i dette tilfælde vil jeg have to tabeller, dvs. opdele problemet i to tilfælde. Dette er den tydeligste illustration af duplikeringsreglen: de samme fakta skrives to gange, så hver forespørgsel læser én partition.

Først vil jeg oprette en tabel, hvor du kan finde kurser af en bestemt studerende.

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

Jeg kan finde alle kurser af en bestemt studerende ved følgende forespørgsel.

SELECT * FROM Student_Course WHERE Student_rollno = 101;

For det andet vil jeg oprette en tabel, hvor du kan finde ud af, hvor mange studerende der studerer et bestemt kursus.

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

Jeg kan finde en studerende i et bestemt kursus ved følgende forespørgsel.

SELECT * FROM Course_Student WHERE Course_name = 'Cassandra';

Der skal skrives til begge tabeller, hver gang en studerende tilmelder sig et kursus, normalt inden for en enkelt logget batch, så de to kopier forbliver i takt.

Fælles Cassandra Fejl i datamodellering

De fleste dårlige skemaer gentager den samme håndfuld fejl, og hver tracvender tilbage til en vane, der er overført fra relationelt design.

• Ubegrænsede partitioner: Hvis du vælger en partitionsnøgle, f.eks. et landenavn, placeres millioner af rækker i én partition. Tilføj en tidsramme, f.eks. (land, måned), for at holde partitionerne inden for en fornuftig størrelse.
• Nøgler med meget lav kardinalitet: En partitionsnøgle med kun få mulige værdier, såsom et statusflag, koncentrerer al trafik på et par noder og lader resten være inaktiv.
• Brug af ALLOW FILTERING til at få en forespørgsel til at fungere: Den scanner alle partitioner og skjuler et modelleringsproblem. Hvis en forespørgsel har brug for det, skal skemaet bruge en anden tabel.
• Modellering af enheder i stedet for forespørgsler: At opbygge en elevtabel og en kurstabel og derefter forsøge at integrere dem i applikationen modvirker designets formål.
• Hyppige sletninger og overskrivninger: Hver sletning skriver en tombstone, der skal læses og springes over, indtil komprimering fjerner den, hvilket forsinker læsninger på aktive partitioner.

Ved at undgå disse holdes skemaet på linje med de regler, der er angivet øverst på denne side, og med de relationelle kontraster, der er opsummeret nedenfor.

Forskellen mellem RDBMS og Cassandra Datamodellering

Disse skemabeslutninger anvendes i praksis i Cassandra bord og tasterum selvstudier.

Ofte Stillede Spørgsmål