Cassandra Adatmodell egyszerű adatbázis-példával

Bár Cassandra lekérdezőnyelv hasonlít SQL nyelven, adatmodellezési módszereik teljesen mások.

In Cassandra, egy rossz adatmodell ronthatja a teljesítményt, különösen akkor, ha a felhasználók megpróbálják megvalósítani az RDBMS koncepciókat Cassandra. A legjobb, ha szem előtt tart néhány, alább részletezett szabályt.

Cassandra Adatmodell szabályok

In Cassandra, az írások nem drágák. Cassandra nem támogatja a csatlakozást, a csoportosítást, a VAGY záradékot, az aggregációkat stb. Tehát úgy kell tárolnia az adatait, hogy azok teljesen visszakereshetők legyenek. Tehát ezeket a szabályokat szem előtt kell tartani az adatok modellezésekor Cassandra.

Maximalizálja az írások számát

In Cassandra, írja nagyon olcsó. Cassandra nagy írási teljesítményre van optimalizálva. Ezért próbálja meg maximalizálni az írásokat a jobb olvasási teljesítmény és az adatok elérhetőségének érdekében. Kompromisszum van az adatírás és az adatolvasás között. Tehát optimalizálja az adatolvasási teljesítményt az adatírások számának maximalizálásával.

Maximalizálja az adatmásolatot

Az adatok denormalizálása és az adatok sokszorosítása defacto Cassandra. A lemezterület nem drágább, mint a memória, a CPU-feldolgozás és az IO-k működése. Mint Cassandra egy elosztott adatbázis, így az adatmásolás azonnali adatelérhetőséget biztosít, és nincs egyetlen hibapont sem.

Cassandra Adatmodellezési célok

Az adatok modellezése során a következő célokat kell kitűznie Cassandra:

Az adatok egyenletes elosztása a Cluster

Minden csomóponton azonos mennyiségű adatot szeretne Cassandra ClusterAz adatok a különböző csomópontok között a partíciós kulcsok alapján kerülnek elosztásra, amelyek az elsődleges kulcs első részét képezik. Ezért próbáljon meg egy nagy kardinalitású oszlopot választani partíciós kulcsként az adatok egyenletes elosztása érdekében a fürtben.

Az adatok lekérdezése közben beolvasott partíciók számának minimalizálása

A partíció ugyanazzal a partíciókulccsal rendelkező rekordok csoportja. Az olvasási lekérdezés kiadásakor adatokat gyűjt a különböző partíciók különböző csomópontjairól.

Ha sok partíció lesz, akkor ezeket a partíciókat meg kell látogatni a lekérdezési adatok gyűjtéséhez.

Ez nem jelenti azt, hogy nem szabad partíciókat létrehozni. Ha az adatmennyiség nagyon nagy, akkor ezt a hatalmas mennyiségű adatot nem lehet egyetlen partíción tárolni. Az egyetlen partíció lelassul.

Tehát próbáljon kiegyensúlyozott számú partíciót választani.

Jó elsődleges kulcs be Cassandra

Mindkét fenti cél egyetlen döntésen múlik, így az alábbi két séma ugyanazt a táblázatot mutatja egy rossz, majd egy helyes kulccsal.

Vegyünk egy példát, és nézzük meg, melyik elsődleges kulcs a jó.

Itt van a MusicPlaylist táblázat.

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

A fenti példában a MusicPlaylist táblázatban,

• A SongId a partíciós kulcs, és
• A SongName a klaszterező oszlop
• Az adatok a SongName alapján lesznek klaszterezve. SongId-ként csak egy partíció jön létre, és mivel minden dalhoz külön azonosító tartozik, minden partíció egyetlen sort tartalmaz.

Ez az adatmodell lassítja az adatok visszakeresését a rossz elsődleges kulcs miatt.

Itt egy másik MusicPlaylist táblázat.

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

A fenti példában a MusicPlaylist táblázatban,

• A SongId és az Year a partíciós kulcs, és
• A SongName a klaszterező oszlop.
• Az adatok a SongName alapján lesznek csoportosítva. Ebben a táblázatban minden évben új partíció jön létre. Az év összes dala ugyanazon a csomóponton lesz. Ez az elsődleges kulcs nagyon hasznos lesz az adatokhoz.

Ezzel az adatmodellel az adatok visszakeresése gyors lesz.

Modellezze adatait Cassandra

A következő dolgokat érdemes szem előtt tartani a lekérdezések modellezésekor:

Határozza meg, milyen lekérdezéseket szeretne támogatni

Először is határozza meg, milyen lekérdezéseket szeretne.

Például kell?

• csatlakozik
• Csoportosít
• Szűrés melyik oszlopra stb.

Hozzon létre táblázatot a lekérdezések szerint

Hozzon létre táblázatot a lekérdezések szerint. Hozzon létre egy táblázatot, amely kielégíti a lekérdezéseket. Próbáljon meg úgy létrehozni egy táblát, hogy minimális számú partíciót be kelljen olvasni.

A következő három szakasz ezt az elvet alkalmazza a szinte minden sémában megtalálható három kapcsolattípusra.

Egy-egy kapcsolat kezelése Cassandra

Egy az egyhez kapcsolat azt jelenti, hogy két táblának egy az egyhez megfeleltetése van. Például egy hallgató csak egy kurzust regisztrálhat, és egy hallgatóra szeretnék rákeresni, hogy egy adott hallgató melyik kurzusra van regisztrálva.

Tehát ebben az esetben a táblázatsémának tartalmaznia kell a hallgató minden részletét az adott kurzusnak megfelelően, például a kurzus nevét, a hallgató számát, a hallgató nevét stb.

A fenti ábra egyetlen táblázatot mutat a lekérdezés kiszolgálására, mivel egy hallgató pontosan egy kurzushoz tartozik.

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

Mivel a Student_roll_no a partíciós kulcs, a roll száma szerinti keresés pontosan egy partíciót olvas be.

Egy a többhez való kapcsolat kezelése Cassandra

Az egy a sokhoz kapcsolat azt jelenti, hogy két táblázat között egy-sok megfeleltetés van.

Például egy kurzust sok diák tanulhat. Meg akarom keresni az összes hallgatót, aki egy adott kurzust tanul.

Tehát ha a kurzus nevére kérdezek rá, sok olyan hallgató neve lesz, aki egy adott kurzust tanul.

Itt a kurzus neve lesz a partíciós kulcs, így a kurzuson részt vevő minden hallgató ugyanabba a partícióba kerül, a tekercs száma pedig a klaszterezési oszlop, így minden hallgató külön sor marad.

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

A következő lekérdezéssel lekérhetem egy adott kurzus összes hallgatóját.

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

Sok-sok kapcsolat kezelése Cassandra

Sok-sok kapcsolat azt jelenti, hogy két táblázat között sok-sok kapcsolat van.

Például egy kurzust sok hallgató tanulhat, és egy hallgató is sok kurzust tanulhat.

Meg akarom keresni az összes hallgatót, aki egy adott kurzust tanul. Ezenkívül meg akarom keresni az összes olyan kurzust, amelyet egy adott hallgató tanul.

Tehát ebben az esetben két táblázatom lesz, azaz a problémát két esetre osztom. Ez a duplikációs szabály legtisztább példája: ugyanazokat a tényeket kétszer írjuk ki, így minden lekérdezés egy partíciót olvas be.

Először létrehozok egy táblázatot, amelyben megtalálhatja egy adott hallgató kurzusait.

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

Egy adott hallgató összes kurzusát megtalálom a következő lekérdezéssel.

SELECT * FROM Student_Course WHERE Student_rollno = 101;

Másodszor, létrehozok egy táblázatot, amelyből megtudhatja, hány hallgató tanul egy adott kurzuson.

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

A következő lekérdezéssel találhatok egy hallgatót egy adott kurzusban.

SELECT * FROM Course_Student WHERE Course_name = 'Cassandra';

Mindkét táblába írni kell, valahányszor egy hallgató csatlakozik egy kurzushoz, általában egyetlen naplózott kötegen belül, hogy a két példány lépést tartson.

Közös Cassandra Adatmodellezési hibák

A legtöbb gyenge séma ugyanazokat a hibákat ismétli, és mindegyik tracvisszatér a relációs tervezésből átvett szokáshoz.

• Korlátlan partíciók: Egy partíciós kulcs, például egy országnév kiválasztása több millió sort helyez el egyetlen partícióban. Adjon hozzá egy idősávot, például (ország, hónap), hogy a partíciók mérete ésszerű kereteken belül maradjon.
• Nagyon alacsony kardinalitású kulcsok: Egy csak néhány lehetséges értékkel rendelkező partíciós kulcs, például egy állapotjelző, az összes forgalmat néhány csomópontra koncentrálja, a többit pedig tétlenül hagyja.
• Az ALLOW FILTERING használata a lekérdezés működéséhez: Minden partíciót átvizsgál, és elrejti a modellezési problémákat. Ha egy lekérdezésnek szüksége van rá, a sémának egy másik táblára van szüksége.
• Entitások modellezése lekérdezések helyett: Egy diákok és egy kurzusok táblázatának létrehozása, majd az alkalmazásban való összekapcsolásuk megpróbálása meghiúsítja a tervezés célját.
• Gyakori törlések és felülírások: Minden törlés egy sírkövet ír, amelyet be kell olvasni és ki kell hagyni, amíg a tömörítés el nem távolítja, ami lelassítja az olvasást a forró partíciókon.

Ezek elkerülése biztosítja, hogy a séma összhangban maradjon az oldal tetején megadott szabályokkal és az alábbiakban összefoglalt relációs különbségekkel.

Különbség az RDBMS és Cassandra Adatmodellezés

Ezeket a sémadöntéseket a gyakorlatban alkalmazzák a Cassandra táblázat és a keyspace oktatóanyagok.

GYIK