Cassandra datamodell med enkelt eksempel

Innholdsfortegnelse:

Anonim

Selv om Cassandra-spørrespråket ligner på SQL-språk, er datamodelleringsmetodene deres helt forskjellige.

I 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 som er beskrevet nedenfor.

I denne veiledningen vil du lære-

  • Cassandra Data Model Rules
  • Modellér dataene dine i Cassandra
  • Håndtering av et til et forhold
  • Håndtere en til mange relasjoner
  • Håndtere mange til mange forhold

Cassandra Data Model Rules

I Cassandra er ikke skrivinger dyre. Cassandra støtter ikke sammenføyninger, gruppere etter, ELLER klausuler, aggregeringer osv. Så du må lagre dataene dine på en slik måte at de skal kunne hentes helt ut. Så disse reglene må man huske på når man modellerer data i Cassandra.

  1. Maksimer antall skrivinger

    I Cassandra er det veldig billig å skrive. Cassandra er optimalisert for høy skriveytelse. Så prøv å maksimere dine skriv for bedre leseytelse og datatilgjengelighet. Det er en kompromiss mellom dataskriving og dataavlesning. Så optimaliser dataene dine ved å maksimere antall dataskrifter.

  2. Maksimer dataduplisering

    Data denormalisering og data duplisering er defacto av Cassandra. Diskplass er ikke dyrere enn minne, CPU-prosessering og IO-drift. Siden Cassandra er en distribuert database, gir dataduplisering øyeblikkelig datatilgjengelighet og ikke noe eneste feilpunkt.

Datamodelleringsmål

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

  1. Spre data jevnt rundt klyngen

    Du vil ha like mye data på hver node i Cassandra-klyngen. Data spres til forskjellige noder basert på partisjonsnøkler som er den første delen av primærnøkkelen. Så prøv å velge heltall som hovednøkkel for å spre data jevnt rundt klyngen.

  2. Minimer antall partisjoner som er lest 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 spørringsdataene.

    Det betyr ikke at partisjoner ikke skal opprettes. Hvis dataene dine er veldig store, kan du ikke beholde den enorme mengden data på den ene partisjonen. Enkeltpartisjonen blir redusert.

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

God primærnøkkel

La oss ta et eksempel og finne 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 eksempelet ovenfor, tabell MusicPlaylist,

  • Songid er partisjonsnøkkelen, og
  • SongName er klyngekolonnen
  • Data blir gruppert på grunnlag av SongName. Bare en partisjon vil bli opprettet med SongId. Det vil ikke være noen annen partisjon i tabellen MusicPlaylist.

Datainnhentingen vil være treg 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 eksempelet ovenfor, tabell MusicPlaylist,

  • Songid og Year er partisjonsnøkkelen, og
  • SongName er klyngekolonnen.
  • Data blir gruppert på grunnlag av SongName. I denne tabellen vil det hvert år opprettes en ny partisjon. Alle årets sanger vil være på samme node. Denne primære nøkkelen vil være veldig nyttig for dataene.

Datainnhentingen vil være rask av denne datamodellen.

Modellér dataene dine i Cassandra

Følgende ting bør huskes når du modellerer spørsmålene dine.

  1. Bestem hvilke spørsmål du vil støtte
  2. Først av alt, bestem hvilke spørsmål du vil ha.

    Trenger du for eksempel?

    • Blir med
    • Gruppe av
    • Filtrering på hvilken kolonne etc.
  3. Lag tabell i henhold til dine spørsmål

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

Håndtering av et til et forhold

Ett til ett forhold betyr at to tabeller har en til en korrespondanse. For eksempel kan studenten bare registrere ett kurs, og jeg vil søke på en student det kurset en bestemt student er registrert i.

Så i dette tilfellet bør bordskjemaet ditt omfatte alle detaljene til studenten som tilsvarer det aktuelle kurset, som navnet på kurset, rull ikke studenten, studentnavnet etc.

Create table Student_Course(Student rollno int primary key,Student_name text,Course_name text,);

Håndtere en til mange relasjoner

Et til mange forhold betyr å ha en til mange korrespondanse mellom to tabeller.

Et kurs kan for eksempel studeres av mange studenter. Jeg vil søke i alle studentene som studerer et bestemt kurs.

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

Create table Student_Course(Student_rollno int,Student_name text,Course_name text,);

Jeg kan hente alle studentene til et bestemt kurs ved hjelp av følgende spørsmål.

Select * from Student_Course where Course_name='Course Name';

Håndtere mange til mange forhold

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

Et kurs kan for eksempel studeres av mange studenter, og en student kan også studere mange kurs.

Jeg vil søke i alle studentene som studerer et bestemt kurs. Også, jeg vil søke i hele kurset som en bestemt student studerer.

Så i dette tilfellet vil jeg ha to tabeller, dvs. dele problemet opp i to tilfeller.

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

Create table Student_Course(Student_rollno int primary key,Student_name text,Course_name text,);

Jeg kan finne alle kursene til en bestemt student ved hjelp av følgende spørsmål. ->

Select * from Student_Course where student_rollno=rollno;

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 primary key,Student_name text,student_rollno int);

Jeg kan finne en student på et bestemt emne ved hjelp av følgende spørsmål.

Select * from Course_Student where Course_name=CourseName;

Forskjellen mellom RDBMS og Cassandra Data Modeling

RDBMS

Cassandra

Lagrer data i normalisert form

Lagrer data i denormalisert form

Arv dbms; strukturerte data

Bred rekke butikk, dynamisk; strukturerte og ustrukturerte data

Sammendrag

Datamodellering i Cassandra er annerledes enn andre RDBMS-databaser. Cassandra datamodellering har noen regler. Disse reglene må følges for god datamodellering. I tillegg til disse reglene så vi tre forskjellige tilfeller for datamodellering og hvordan vi skulle håndtere dem.