Cassandra Datamodell med enkelt databaseeksempel

Selv Cassandra spørrespråket ligner SQL språk, er deres datamodelleringsmetoder helt forskjellige.

In Cassandra, kan en dårlig datamodell forringe ytelsen, spesielt når brukere prøver å implementere RDBMS-konseptene på Cassandra. Det er best å huske på noen regler beskrevet nedenfor.

Cassandra Datamodellregler

In Cassandra, skriver er ikke dyre. Cassandra støtter ikke joins, group by, OR-klausul, aggregeringer osv. Så du må lagre dataene dine på en slik måte at de skal være fullstendig gjenfinnbare. Så disse reglene må huskes når du modellerer data Cassandra.

Maksimer antall skrivinger

In Cassandra, skriver er veldig billig. Cassandra er optimalisert for høy skriveytelse. Så prøv å maksimere skrivingene dine for bedre leseytelse og datatilgjengelighet. Det er en avveining mellom dataskriving og datalesing. Så optimaliser dataleseytelsen din ved å maksimere antall dataskrivinger.

Maksimer dataduplisering

Datadenormalisering og dataduplisering er defacto of Cassandra. Diskplass er ikke dyrere enn minne, CPU-behandling og IO-drift. Som Cassandra er en distribuert database, så dataduplisering gir umiddelbar datatilgjengelighet og ikke noe enkelt punkt for feil.

Cassandra Mål for datamodellering

Du bør ha følgende mål mens du modellerer data Cassandra:

Spre data jevnt rundt Cluster

Du vil ha en lik mengde data på hver node av Cassandra ClusterData spres til forskjellige noder basert på partisjonsnøkler som er den første delen av primærnøkkelen. Prøv derfor å velge en kolonne med høy kardinalitet som partisjonsnøkkel for å spre data jevnt rundt klyngen.

Minimer antall partisjoner som leses mens du spør etter data

Partisjon er en gruppe poster med samme partisjonsnøkkel. Når lesespørringen utstedes, samler den inn data fra forskjellige noder fra forskjellige partisjoner.

Hvis det vil være mange partisjoner, må alle disse partisjonene besøkes for å samle inn spørringsdataene.

Det betyr ikke at partisjoner ikke skal opprettes. Hvis dataene dine er veldig store, kan du ikke lagre den enorme mengden data på den ene partisjonen. Den ene partisjonen vil bli tregere.

Så prøv å velge et balansert antall partisjoner.

God primærnøkkel inn Cassandra

Begge målene ovenfor kommer ned til én avgjørelse, så de to skjemaene nedenfor viser den samme tabellen med en dårlig nøkkel og deretter en god en.

La oss ta et eksempel og finne ut hvilken primærnøkkel som er god.

Her er tabellen MusicPlaylist.

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

I eksemplet ovenfor, tabellen MusicPlaylist,

• SongId er partisjonsnøkkelen, og
• SongName er klyngekolonnen
• Dataene vil bli gruppert basert på sangnavn. Bare én partisjon vil bli opprettet per sang-ID, og ​​fordi hver sang har en distinkt identifikator, inneholder hver partisjon én rad.

Datainnhentingen vil gå tregt av denne datamodellen på grunn av den dårlige primærnøkkelen.

Her er en annen tabell MusicPlaylist.

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

I eksemplet ovenfor, tabellen MusicPlaylist,

• SongId og Year er partisjonsnøkkelen, og
• SongName er klyngekolonnen.
• Data vil bli gruppert på grunnlag av SongName. I denne tabellen vil det bli opprettet en ny partisjon hvert år. Alle årets sanger vil være på samme node. Denne primærnøkkelen vil være svært nyttig for dataene.

Datainnhentingen vår vil være rask med denne datamodellen.

Modeller dataene dine inn Cassandra

Følgende ting bør huskes når du modellerer søkene dine:

Bestem hvilke spørsmål du vil støtte

Først av alt, bestemme hvilke søk du vil ha.

Trenger du for eksempel?

• tiltrer
• Gruppe av
• Filtrering på hvilken kolonne osv.

Lag tabell i henhold til dine spørsmål

Lag tabell i henhold til dine spørsmål. Lag en tabell som vil tilfredsstille dine spørsmål. Prøv å lage en tabell på en slik måte at et minimum antall partisjoner må leses.

De tre avsnittene som følger, anvender dette prinsippet på de tre relasjonstypene som finnes i nesten alle skjemaer.

Håndtere ett til ett forhold i Cassandra

En til en relasjon betyr at to tabeller har en til en korrespondanse. For eksempel kan studenten registrere kun ett emne, og jeg ønsker å søke på en student som i hvilket emne en bestemt student er registrert i.

Så i dette tilfellet bør tabellskjemaet ditt omfatte alle detaljene til studenten i samsvar med det aktuelle kurset, som navnet på kurset, rullenummeret til studenten, studentnavnet osv.

Diagrammet ovenfor viser én enkelt tabell som betjener spørringen, fordi én student er tilordnet nøyaktig ett kurs.

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

Fordi Student_rollno er partisjonsnøkkelen, leser et oppslag etter rullnummer nøyaktig én partisjon.

Håndtere ett til mange forhold i Cassandra

En til mange relasjoner betyr å ha en til mange korrespondanse mellom to tabeller.

For eksempel kan et emne studeres av mange studenter. Jeg vil søke etter alle studentene som studerer et bestemt emne.

Så ved å spørre på emnenavn, vil jeg ha mange studentnavn som skal studere et bestemt emne.

Her blir kursnavnet partisjonsnøkkelen slik at alle studentene i et kurs havner i samme partisjon, og rullenummeret blir klyngekolonnen slik at hver student forblir en egen rad.

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

Jeg kan hente alle studentene for et bestemt kurs ved å bruke følgende spørring.

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

Håndtere mange til mange forhold i Cassandra

Mange til mange relasjoner betyr å ha mange til mange korrespondanse mellom to tabeller.

For eksempel kan et emne studeres av mange studenter, og en student kan også studere mange emner.

Jeg vil søke etter alle studentene som studerer et bestemt emne. Jeg ønsker også å søke i hele kurset som en bestemt student studerer.

Så i dette tilfellet vil jeg ha to tabeller, dvs. dele problemet inn i to tilfeller. Dette er den tydeligste illustrasjonen av dupliseringsregelen: de samme faktaene skrives to ganger, slik at hver spørring leser én partisjon.

Først vil jeg lage en tabell der du kan finne kurs av en bestemt student.

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

Jeg kan finne alle kursene til en bestemt student ved å følge spørsmålet nedenfor.

SELECT * FROM Student_Course WHERE Student_rollno = 101;

For det andre vil jeg lage en tabell der du kan finne hvor mange studenter som studerer et bestemt kurs.

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

Jeg kan finne en student i et bestemt kurs ved å følge spørsmålet nedenfor.

SELECT * FROM Course_Student WHERE Course_name = 'Cassandra';

Begge tabellene må skrives til hver gang en student blir med i et kurs, vanligvis innenfor én loggført gruppe, slik at de to kopiene holder takt.

Felles Cassandra Feil i datamodellering

De fleste dårlige skjemaer gjentar den samme håndfullen feil, og hver tracgår tilbake til en vane overført fra relasjonsdesign.

• Ubegrensede partisjoner: Å velge en partisjonsnøkkel, for eksempel et landsnavn, legger millioner av rader inn i én partisjon. Legg til en tidsramme, for eksempel (land, måned), for å holde partisjonene innenfor en fornuftig størrelse.
• Nøkler med svært lav kardinalitet: En partisjonsnøkkel med bare noen få mulige verdier, for eksempel et statusflagg, konsentrerer all trafikk på noen få noder og lar resten være inaktiv.
• Bruk ALLOW FILTERING for å få en spørring til å fungere: Den skanner hver partisjon og skjuler et modelleringsproblem. Hvis en spørring trenger det, trenger skjemaet en annen tabell.
• Modellering av enheter i stedet for spørringer: Å bygge en studenttabell og en kurstabell, og deretter prøve å koble dem sammen i applikasjonen, motvirker designets formål.
• Hyppige slettinger og overskrivinger: Hver sletting skriver en tombstone som må leses og hoppes over inntil komprimering fjerner den, noe som reduserer lesingen på aktive partisjoner.

Ved å unngå disse holdes skjemaet i samsvar med reglene som er angitt øverst på denne siden, og med de relasjonelle kontrastene som er oppsummert nedenfor.

Forskjellen mellom RDBMS og Cassandra Datamodellering

Disse skjemaavgjørelsene anvendes i praksis i Cassandra bord og tasterom opplæringsprogrammer.

Spørsmål og svar