Cassandra Tietomalli yksinkertaisella tietokantaesimerkillä

Vaikka Cassandra kyselykieli muistuttaa SQL kielellä, niiden datamallinnusmenetelmät ovat täysin erilaisia.

In Cassandra, huono tietomalli voi heikentää suorituskykyä, varsinkin kun käyttäjät yrittävät toteuttaa RDBMS-konsepteja Cassandra. On parasta pitää mielessä muutama alla kuvattu sääntö.

Cassandra Tietomallin säännöt

In Cassandra, kirjoitukset eivät ole kalliita. Cassandra ei tue liittymiä, ryhmittelyä, OR-lausetta, aggregaatioita jne. Joten sinun on tallennettava tietosi siten, että ne ovat täysin noudettavissa. Nämä säännöt on siis pidettävä mielessä, kun tietoja mallinnetaan Cassandra.

Maksimoi kirjoitusten määrä

In Cassandra, kirjoitukset ovat erittäin halpoja. Cassandra on optimoitu korkeaa kirjoitustehoa varten. Pyri siis maksimoimaan kirjoitustesi tehokkuus paremman lukutehon ja datan saatavuuden saavuttamiseksi. Datan kirjoittamisen ja lukemisen välillä on kompromissi. Optimoi siis datan lukutehokkuus maksimoimalla datan kirjoituskertojen määrä.

Maksimoi tietojen päällekkäisyys

Tietojen denormalisointi ja tietojen kopiointi ovat tosiasiassa Cassandra. Levytila ​​ei ole kalliimpaa kuin muisti, prosessorikäsittely ja IO:iden toiminta. Kuten Cassandra on hajautettu tietokanta, joten tietojen päällekkäisyys tarjoaa välittömän tiedon saatavuuden eikä yhtä vikakohtaa.

Cassandra Tiedon mallinnuksen tavoitteet

Sinulla pitäisi olla seuraavat tavoitteet mallintaessasi tietoja Cassandra:

Levitä tiedot tasaisesti ympäri Cluster

Haluat yhtä paljon dataa jokaisessa solmussa Cassandra ClusterData levitetään eri solmuille osioavainten perusteella, jotka ovat ensisijaisen avaimen ensimmäinen osa. Joten yritä valita osioavaimeksi korkean kardinaliteetin sarake, jotta data leviää tasaisesti klusterin ympärille.

Minimoi luettavien osioiden määrä tietoja kyselyn aikana

Osio ovat ryhmä tietueita, joilla on sama osioavain. Kun lukukysely annetaan, se kerää tietoja eri solmuista eri osioista.

Jos osioita on useita, kaikissa näissä osioissa tulee käydä kyselytietojen keräämiseksi.

Se ei tarkoita, etteikö osioita pitäisi luoda. Jos datasi on erittäin suurta, et voi säilyttää sitä valtavaa tietomäärää yhdessä osiossa. Yksittäinen osio hidastuu.

Joten yritä valita tasapainoinen määrä osioita.

Hyvä ensisijainen avain Cassandra

Molemmat yllä olevat tavoitteet riippuvat yhdestä päätöksestä, joten alla olevat kaksi kaaviota näyttävät saman taulukon, jossa on sekä huono että hyvä avain.

Otetaan esimerkki ja selvitetään, mikä ensisijainen avain on hyvä.

Tässä on MusicPlaylist-taulukko.

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

Yllä olevassa esimerkissä taulukko MusicPlaylist,

• SongId on osioavain ja
• SongName on klusterisarake
• Tiedot ryhmitellään kappaleen nimen (SongName) perusteella. Kappaleen tunnistetta (SongId) kohden luodaan vain yksi osio, ja koska jokaisella kappaleella on oma tunnisteensa, jokaisessa osiossa on yksi rivi.

Tämä tietomalli hidastaa tietojen hakua huonon ensisijaisen avaimen vuoksi.

Tässä on toinen taulukko MusicPlaylist.

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

Yllä olevassa esimerkissä taulukko MusicPlaylist,

• SongId ja Year ovat osioavaimet, ja
• SongName on klusterisarake.
• Tiedot ryhmitellään kappaleen nimen perusteella. Tässä taulukossa luodaan joka vuosi uusi osio. Kaikki vuoden kappaleet ovat samassa solmussa. Tämä ensisijainen avain on erittäin hyödyllinen tiedoille.

Tietojen haku on nopea tällä tietomallilla.

Mallinna tietosi Cassandra

Seuraavat asiat tulee pitää mielessä kyselyjäsi mallintaessa:

Määritä, mitä kyselyitä haluat tukea

Ensinnäkin määritä, mitä kyselyitä haluat.

Tarvitsetko esimerkiksi?

• Liitosten
• Ryhmän mukaan
• Suodatus mihin sarakkeeseen jne.

Luo taulukko kyselyjesi mukaan

Luo taulukko kyselyjesi mukaan. Luo taulukko, joka täyttää kyselysi. Yritä luoda taulukko siten, että vähimmäismäärä osioita on luettava.

Seuraavat kolme osiota soveltavat tätä periaatetta lähes jokaisessa skeemassa esiintyviin kolmeen suhdetyyppiin.

Yksittäisen suhteen käsitteleminen Cassandra

Yksi yhteen -suhde tarkoittaa, että kahdella taulukolla on yksi vastaavuus. Esimerkiksi opiskelija voi ilmoittautua vain yhdelle kurssille, ja haluan etsiä opiskelijasta, mille kurssille tietty opiskelija on ilmoittautunut.

Joten tässä tapauksessa taulukkokaavion tulisi sisältää kaikki kyseistä kurssia vastaavan opiskelijan tiedot, kuten kurssin nimi, opiskelijan numero, opiskelijan nimi jne.

Yllä olevassa kaaviossa kyselyä palvelee yksi taulukko, koska yksi opiskelija liittyy täsmälleen yhteen kurssiin.

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

Koska Student_rollno on osioavain, opiskelijan rullausnumeron mukainen haku lukee täsmälleen yhden osion.

Yhdestä moneen -suhteen käsittely Cassandra

Yksi moniin -suhteet tarkoittaa, että kahden taulukon välillä on yhdestä useaan vastaavuus.

Esimerkiksi kurssia voivat opiskella monet opiskelijat. Haluan etsiä kaikki opiskelijat, jotka opiskelevat tiettyä kurssia.

Joten kysymällä kurssin nimeä, minulla on monia opiskelijoiden nimiä, jotka opiskelevat tiettyä kurssia.

Tässä kurssin nimestä tulee osioavain, jotta jokainen kurssin opiskelija päätyy samaan osioon, ja osallistujanumerosta tulee klusterointisarake, jotta jokainen opiskelija pysyy erillisenä rivinä.

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

Voin hakea kaikki tietyn kurssin opiskelijat seuraavalla kyselyllä.

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

Monen toiselle -suhteen käsitteleminen Cassandra

Monesta moneen -suhteet tarkoittaa sitä, että kahden taulukon välillä on monta useampaa vastaavuutta.

Esimerkiksi yhtä kurssia voi opiskella moni opiskelija, ja opiskelija voi myös opiskella monia kursseja.

Haluan etsiä kaikki opiskelijat, jotka opiskelevat tiettyä kurssia. Haluan myös etsiä kaikki kurssit, joita tietty opiskelija opiskelee.

Tässä tapauksessa minulla on siis kaksi taulukkoa eli jaan ongelman kahteen tapaukseen. Tämä on selkein esimerkki kopiointisäännöstä: samat tiedot kirjoitetaan kahdesti, joten jokainen kysely lukee yhden osion.

Ensin luon taulukon, josta löydät tietyn opiskelijan kurssit.

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

Löydän kaikki tietyn opiskelijan kurssit seuraavalla kyselyllä.

SELECT * FROM Student_Course WHERE Student_rollno = 101;

Toiseksi luon taulukon, josta näet kuinka monta opiskelijaa opiskelee tiettyä kurssia.

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

Löydän opiskelijan tietyltä kurssilta seuraavalla kyselyllä.

SELECT * FROM Course_Student WHERE Course_name = 'Cassandra';

Molempiin taulukoihin on kirjoitettava tiedot aina, kun opiskelija liittyy kurssille, yleensä yhden kirjatun erän sisällä, jotta kaksi kopiota pysyvät tahdissa.

Yhteinen Cassandra Tietojen mallinnusvirheet

Useimmat huonot skeemat toistavat samoja virheitä, ja jokainen tracpalaa relaatiosuunnittelusta periytyneeseen tapaan.

• Rajattomat osiot: Osiointiavaimen, kuten maan nimen, valitseminen sijoittaa miljoonia rivejä yhteen osioon. Lisää aikaväli, esimerkiksi (maa, kuukausi), pitääksesi osiot järkevässä koossa.
• Hyvin matalan kardinaliteettiavaimet: Osiointiavain, jolla on vain muutama mahdollinen arvo, kuten tilalippu, keskittää kaiken liikenteen muutamaan solmuun ja jättää loput käyttämättömiksi.
• ALLOW FILTERING -ominaisuuden käyttäminen kyselyn toimivuuden varmistamiseksi: Se skannaa jokaisen osion ja piilottaa mallinnusongelman. Jos kysely sitä tarvitsee, skeema tarvitsee toisen taulukon.
• Entiteettien mallintaminen kyselyiden sijaan: Opiskelijataulukon ja kurssitaulukon rakentaminen ja niiden yhdistäminen sovellukseen tekee suunnittelusta tarkoituksen tyhjäksi.
• Usein tehdyt poistot ja päällekirjoitukset: Jokainen poisto luo hautakiven, joka on luettava ja ohitettava, kunnes pakkaaminen poistaa sen. Tämä hidastaa lukemista kuumilla osioilla.

Näiden välttäminen pitää skeeman linjassa tämän sivun yläosassa mainittujen sääntöjen ja alla esitettyjen relaatioerojen kanssa.

Ero RDBMS:n ja Cassandra Tietomallinnus

Näitä skeemapäätöksiä sovelletaan käytännössä Cassandra taulukko ja näppäimistötila opetusohjelmia.

UKK