Uvod v podatkovni model v Cassandri
Apache Cassandra je postala ena najmočnejših baz podatkov NoSQL. To je prava izbira, če želite visoko razpoložljivost in razširljivost, ne da bi pri tem ogrožali zmogljivost, zlasti za aplikacije, ki si ne morejo privoščiti izgube podatkov. V tej temi bomo spoznali podatkovni model v Cassandri.
Hitro dejstvo, da so Cassandrovi inženirji danes med najbolje plačanimi tehnološkimi strokovnjaki. Podjetja, kot so Netflix, Instagram in Apple, uporabljajo Cassandra za zagotavljanje zelo individualizirane uporabniške izkušnje. Če želite doseči pravo uspešnost, morate skrbno oblikovati shemo, ki je značilna za poslovni problem. V tem članku si bomo ogledali podatkovni model Cassandra, ki se bistveno razlikuje od tistega, ki ga vidimo v RDBMS.
Pravila modela Cassandra
Z enostavnimi besedami, podatkovni model je logična struktura baze podatkov. Opisuje način shranjevanja in dostopa do podatkov ter razmerja med različnimi vrstami podatkov.
Izbira pravega podatkovnega modela je lahko najtežji del uporabe baze podatkov NoSQL, kot je Cassandra. Kot sem že omenil, se modeliranje podatkov v Cassandri razlikuje od tistega, ki ga vidimo v RDBMS.
Predelni ključ in Clustering key sta izraza, ki bi se ga moral zavedati vsakdo, ki se ukvarja s Cassandro. Preden se poglobimo v osnovna pravila modeliranja podatkov v Cassandri, si na hitro poglejmo, kaj ti izrazi pomenijo,
Predelna stena
Cassandra je porazdeljena baza podatkov, v kateri so podatki razdeljeni in shranjeni v različnih vozliščih v grozdu. Podatki so razdeljeni s pomočjo particijskega ključa, ki je lahko eno ali več podatkovnih polj. Ta razdelitveni ključ se uporablja za ustvarjanje mehanizma za razprševanje, ki podatke enakomerno širi po vseh vozliščih.
Grozd
Grozd je zbirka vozlišč, ki predstavljajo eno samo logično bazo podatkov. Grozdni ključ je sestavljen iz enega ali več polj, ki se uporabljajo za združevanje podatkov v particiji.
V tej tabeli restavracije bodo podatki razdeljeni z uporabo kode države, imena države in mesta, v okviru te particije pa bodo razvrščeni in razvrščeni glede na podatke o odpiranju_podatkov in imena restavracije.
Zdaj pa si oglejmo dva pravila za modeliranje podatkov, ki jih je treba upoštevati.
- Podatki so enakomerno razporejeni po celotni grozdu
- Preberite iz čim manj particij
Poglejmo, kaj ta pravila poskušajo prenesti
- Vemo, kaj je grozd prav? Grozd je sestavljen iz več vozlišč. Podatke želimo razdeliti med ta vozlišča tako, da ima vsako vozlišče približno enako količino podatkov. Kot vemo, so podatki razdeljeni na različna vozlišča s pomočjo hash-ja particijskega ključa (ki je prvi ključ primarnega ključa), torej na kratko - "Izberite dober primarni ključ".
- Vsaka particija je na drugem vozlišču, zato želite, ko pridobite podatke, zagotoviti, da so podatki naloženi iz čim manj particij. Če vaša poizvedba zahteva podatke z različnih particij, bo izdan ukaz za ločena vozlišča, ki vam bodo priskrbeli te podatke, ki bodo nadpovprečni in bodo privedli do zamud.
Ključ do učinkovitega podatkovnega modela bi bilo ravnovesje med tema dvema praviloma.
Obravnavajte razmerja v Cassandri
Ne pozabite, da je modeliranje podatkov v Cassandri narejeno s pristopno usmerjenim pristopom, za razliko od RDBMS, kjer najprej identificirate entitete, ustvarite tabele in nato oblikujete poizvedbe z uporabo JOINS za pridobivanje podatkov.
Preprosto povedano, ne modeliramo okoli odnosov ali predmetov, modeliramo okoli poizvedb.
1. Odnos ena do ene
Menite, da se lahko študent na univerzi prijavi samo na en seminar. To je odnos ena na ena. Ob vodenju pravila 1 pomislimo na želene poizvedbe. Želim poiskati seminar, ki se ga udeleži študent. V tem primeru bomo naredili samo eno tabelo. Tabela mora vsebovati podrobnosti študenta in podatke o seminarju.
2. Odnos eden do mnogih
V istem kontekstu, kaj če bi želel poiskati vse študente, ki obiskujejo seminar. Namesto da bi uporabil isto tabelo in iteriral nad vsako vrstico, da bi pridobil ime študenta za določen seminar, lahko naredim drugo tabelo, ki podatke razdeli po imenu seminarja. Ko izdajem poizvedbo, zadene samo eno vozlišče, namesto da gre na vsa vozlišča, da dobi ime seminarja.
3. odnos do mnogih
Zdaj, pomislimo, se lahko študent udeleži številnih seminarjev, seminarja pa se lahko udeleži veliko študentov. Tukaj imamo veliko do veliko odnosov. V tem primeru lahko zgornji dve tabeli izkoristite za izvedbo poizvedb, ne da bi pri tem potrebovali zapletene poizvedbe z uporabo Joins, ki jo običajno izvajate v RDBMS.
Pomen Cassandra
S hitro razširitvijo digitalnih podatkov postaja pomembneje imeti visoko razširljivo bazo podatkov, ki je odporna na napake. Naj navedem nekaj točk o tem, zakaj morate uporabljati zdravilo Cassandra
- Osvetlitev hitro bralnih operacij: Razpravljali smo o tem, kako pravilno modeliranje podatkov lahko optimizira bralne operacije v velikem obsegu.
- Napačno odporen: Podatki se kopirajo v vseh vozliščih, tako da so tudi vaši podatki varni, tudi če eno vozlišče pade navzdol.
- Prilagoditev po meri: Cassandra lahko nastavite tako, da deluje v skladu s svojo delovno obremenitvijo. Če napišete veliko podatkov, na primer beleženje, ga lahko prilagodite tako, da bo obdeloval težke sisteme. Na voljo je več drugih možnosti uglaševanja.
- Obravnavanje velikih količin podatkov: Cassandra lahko na podlagi velikosti grozda obravnava ogromno količino podatkov.
Kako modelirati podatke v Cassandri?
Temu korakom sledi dobro modeliranje podatkov
- Konceptualizirajte poizvedbe, ki jih zahteva vaša aplikacija
- Ustvarjanje tabel za zadovoljevanje teh poizvedb
Preden uporabimo ta pravila, je treba upoštevati eno: "Osredotočimo se na optimizacijo svojih bralnih operacij, tudi če zahteva podvajanje podatkov". Lahko imamo veliko tabel, ki lahko vsebujejo skoraj podobne podatke.
Zdaj pa razmislite, da želimo bazo podatkov, ki shranjuje informacije o restavracijah. Omejimo, da morajo biti imena restavracij unikatna.
Spodnjo tabelo lahko uporabimo, kadar želimo iskati glede na ime restavracije:
Zdaj, če želimo poiskati restavracije za določeno lokacijo, bi napisali poizvedbo, ki ponovi skozi vse vrstice in prikliče imena restavracij.
Namesto tega, če upoštevamo pravilo # 2, lahko preprosto sestavimo drugo tabelo, ki bo zadovoljila naše potrebe.
Zdaj bodo naši podatki razdeljeni tako, da bo vozlišče v grozdu imelo restavracije za določeno lokacijo. To bo optimiziralo naše bralne poizvedbe, saj se bo iskanje poizvedb zgodilo samo na enem vozlišču z veliko manj vrsticami kot prva tabela, ki smo jo ustvarili.
Kaj pa, če bi želeli iskati restavracije v določenem mestu, lahko naredimo še eno tabelo, ne pa da ponavljamo skozi vse vrstice v eni particiji zgornje tabele.
Zaključek
V tem članku sem opisal nekaj najboljših praks, ki jim lahko sledite, kako pristopiti k modeliranju podatkov v Cassandri. Če razumete te koncepte in lahko učinkovito prepoznate vrsto poizvedb, ki jih vaša aplikacija potrebuje, lahko oblikujete odličen podatkovni model, s katerim boste iz baze podatkov dosegli visoko zmogljivost.
Priporočeni članki
To je vodnik za podatkovni model v Cassandri. Tukaj razpravljamo o tem, kako modelirati naše podatke v Cassandri skupaj s pravili in pomembnostjo Cassandra Data Modelov. Če želite izvedeti več, lahko preberete tudi druge naše predlagane članke -
- Kaj je modeliranje podatkov?
- Podatkovni modeli v DBMS
- Vprašanja o intervjuju za modeliranje podatkov
- Cassandra Podatkovno modeliranje