Cassandra Model podataka s primjerom jednostavne baze podataka

Iako Cassandra jezik upita nalikuje SQL jeziku, njihove metode modeliranja podataka potpuno su različite.

In Cassandra, loš podatkovni model može pogoršati performanse, posebno kada korisnici pokušavaju implementirati koncepte RDBMS-a Cassandra. Najbolje je imati na umu nekoliko pravila koja su navedena u nastavku.

Cassandra Pravila podatkovnog modela

In Cassandra, piše nisu skupi. Cassandra ne podržava pridruživanje, grupiranje po, klauzulu OR, združivanje, itd. Dakle, morate pohraniti svoje podatke na takav način da bi trebali biti potpuno dostupni. Stoga se ova pravila moraju imati na umu tijekom modeliranja podataka Cassandra.

Maksimizirajte broj pisanja

In Cassandra, piše vrlo su jeftini. Cassandra optimiziran je za visoke performanse pisanja. Stoga pokušajte maksimizirati svoja pisanja za bolje performanse čitanja i dostupnost podataka. Postoji kompromis između pisanja i čitanja podataka. Stoga optimizirajte performanse čitanja podataka maksimiziranjem broja pisanja podataka.

Povećajte umnožavanje podataka

Denormalizacija podataka i dupliciranje podataka su defacto of Cassandra. Prostor na disku nije skuplji od memorije, CPU obrade i rada IO-a. Kao Cassandra je distribuirana baza podataka, tako da dupliciranje podataka pruža trenutnu dostupnost podataka i nema jedinstvene točke kvara.

Cassandra Ciljevi modeliranja podataka

Tijekom modeliranja podataka trebali biste imati sljedeće ciljeve Cassandra:

Ravnomjerno rasporedite podatke oko Cluster

Želite jednaku količinu podataka na svakom čvoru Cassandra ClusterPodaci se raspoređuju na različite čvorove na temelju particijskih ključeva koji su prvi dio primarnog ključa. Stoga pokušajte odabrati stupac visoke kardinalnosti kao particijski ključ za ravnomjernu raspodjelu podataka po klasteru.

Minimizirajte broj particija koje se čitaju tijekom upita za podatke

Particija je grupa zapisa s istim ključem particije. Kada se izda upit za čitanje, on prikuplja podatke iz različitih čvorova s ​​različitih particija.

Ako će biti mnogo particija, tada sve te particije treba posjetiti radi prikupljanja podataka upita.

To ne znači da se particije ne bi trebale stvarati. Ako su vaši podaci jako veliki, ne možete pohraniti tu ogromnu količinu podataka na jednoj particiji. Jedna particija će biti usporena.

Stoga pokušajte odabrati uravnotežen broj particija.

Dobar primarni ključ Cassandra

Oba gore navedena cilja svode se na jednu odluku, pa dvije sheme u nastavku prikazuju istu tablicu s lošim ključem, a zatim i ispravnim.

Uzmimo primjer i pronađimo koji je primarni ključ dobar.

Ovdje je tablica MusicPlaylist.

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

U gornjem primjeru, tablica MusicPlaylist,

• SongId je ključ particije i
• SongName je stupac klasteriranja
• Podaci će biti grupirani na temelju naziva pjesme (SongName). Za svaki identifikator pjesme (SongId) bit će kreirana samo jedna particija, a budući da svaka pjesma ima zaseban identifikator, svaka particija sadrži jedan redak.

Dohvaćanje podataka bit će sporo s ovim podatkovnim modelom zbog lošeg primarnog ključa.

Evo još jedne tablice MusicPlaylist.

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

U gornjem primjeru, tablica MusicPlaylist,

• SongId i Year su ključ particije, a
• SongName je stupac klasteriranja.
• Podaci će se grupirati na temelju naziva pjesme. U ovoj će se tablici svake godine izraditi nova particija. Sve će pjesme godine biti na istom čvoru. Ovaj primarni ključ će biti vrlo koristan za podatke.

Naše će dohvaćanje podataka biti brzo pomoću ovog podatkovnog modela.

Modelirajte svoje podatke Cassandra

Sljedeće stvari treba imati na umu tijekom modeliranja vaših upita:

Odredite koje upite želite podržati

Prije svega odredite koje upite želite.

Na primjer, trebate li?

• Pridružuje
• Grupa po
• Filtriranje po kojem stupcu itd.

Napravite tablicu prema svojim upitima

Napravite tablicu prema svojim upitima. Napravite tablicu koja će zadovoljiti vaše upite. Pokušajte kreirati tablicu na takav način da je potrebno pročitati minimalan broj particija.

Tri odjeljka koja slijede primjenjuju taj princip na tri tipa odnosa koje se nalaze u gotovo svakoj shemi.

Rukovanje odnosom jedan na jedan Cassandra

Odnos jedan prema jedan znači da dvije tablice imaju korespondenciju jedan prema jedan. Na primjer, student može prijaviti samo jedan kolegij, a ja želim na studentu pretražiti na kojem kolegiju je određeni student upisan.

Dakle, u ovom slučaju, vaša shema tablice trebala bi uključivati ​​sve pojedinosti o studentu koji odgovaraju tom određenom kolegiju kao što je naziv kolegija, broj studenta, ime studenta itd.

Gornji dijagram prikazuje jednu tablicu koja poslužuje upit, jer se jedan student preslikava na točno jedan kolegij.

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

Budući da je Student_rollno ključ particije, pretraživanje po broju role čita točno jednu particiju.

Rukovanje odnosom jedan prema više Cassandra

Odnosi jedan prema više znače korespondenciju jedan prema više između dvije tablice.

Na primjer, tečaj može proučavati mnogo studenata. Želim pretražiti sve studente koji studiraju određeni predmet.

Dakle, upitom o nazivu kolegija, imat ću mnogo imena studenata koji će učiti određeni kolegij.

Ovdje naziv kolegija postaje ključ particije tako da svaki student na kolegiju završava u istoj particiji, a broj role postaje stupac klasteriranja tako da svaki student ostaje zaseban redak.

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

Mogu dohvatiti sve studente za određeni kolegij pomoću sljedećeg upita.

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

Rukovanje odnosom više prema mnogima Cassandra

Odnosi mnogo prema mnogima znače korespondenciju između dvije tablice mnogo prema mnogima.

Na primjer, kolegij može studirati mnogo studenata, a student također može studirati mnogo kolegija.

Želim pretražiti sve studente koji studiraju određeni predmet. Također, želim pretražiti sve kolegije koje određeni student studira.

Dakle, u ovom slučaju, imat ću dvije tablice, tj. problem podijeliti na dva slučaja. Ovo je najjasnija ilustracija pravila dupliciranja: iste činjenice se zapisuju dva puta tako da svaki upit čita jednu particiju.

Prvo ću napraviti tablicu po kojoj možete pronaći tečajeve po određenom studentu.

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

Sljedećim upitom mogu pronaći sve tečajeve određenog studenta.

SELECT * FROM Student_Course WHERE Student_rollno = 101;

Drugo, napravit ću tablicu po kojoj možete saznati koliko studenata studira određeni kolegij.

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

Mogu pronaći studenta na određenom kolegiju pomoću sljedećeg upita.

SELECT * FROM Course_Student WHERE Course_name = 'Cassandra';

U obje tablice mora se pisati svaki put kada se student pridruži kolegiju, obično unutar jedne zabilježene serije kako bi dvije kopije ostale usklađene.

Zajednički Cassandra Pogreške u modeliranju podataka

Većina loših shema ponavlja istu šačicu pogrešaka, i svaka tracvraća se navici prenesenoj iz relacijskog dizajna.

• Neograničene particije: Odabirom ključa particije, kao što je naziv države, milijuni redaka se stavljaju u jednu particiju. Dodajte vremenski okvir, na primjer (država, mjesec), kako biste particije održali unutar razumne veličine.
• Ključevi s vrlo niskom kardinalnošću: Particijski ključ sa samo nekoliko mogućih vrijednosti, kao što je statusna zastavica, koncentrira sav promet na nekoliko čvorova, a ostale ostavlja neaktivnima.
• Korištenje DOPUSTI FILTRIRANJE za izvršavanje upita: Skenira svaku particiju i skriva problem modeliranja. Ako upit to treba, shemi je potrebna druga tablica.
• Modeliranje entiteta umjesto upita: Izrada tablice za studente i tablice za tečajeve, a zatim pokušaj njihovog spajanja u aplikaciji, poništava svrhu dizajna.
• Često brisanje i prepisivanje: Svako brisanje zapisuje tajni spomenik koji se mora pročitati i preskočiti dok se ne ukloni sažimanjem, što usporava čitanje na vrućim particijama.

Izbjegavanjem ovih pravila shema ostaje usklađena s pravilima navedenim na vrhu ove stranice i s relacijskim kontrastima sažetim u nastavku.

Razlika između RDBMS i Cassandra Modeliranje podataka

Ove odluke o shemama primjenjuju se u praksi u Cassandra stol i razmak tipki tutorijali.

Pitanja i odgovori