Uvod u model podataka u Cassandri
Apache Cassandra postao je jedna od najmoćnijih NoSQL baza podataka. To je pravi izbor kada želite visoku dostupnost i skalabilnost bez narušavanja performansi, posebno za aplikacije koje ne mogu priuštiti gubitak podataka. U ovoj ćemo temi saznati više o modelu podataka u Cassandri.
Brza činjenica, Cassandrovi inženjeri su među najplaćenijim tehnološkim stručnjacima danas. Tvrtke poput Netflixa, Instagrama i Applea koriste Cassandra za pružanje visoko individualiziranog korisničkog iskustva. Da biste postigli prave performanse, morate pažljivo dizajnirati shemu specifičnu za poslovni problem. U ovom ćemo članku pogledati model podataka Cassandra koji se značajno razlikuje od onoga što vidimo u RDBMS-u.
Pravila modela Cassandra
Jednostavnim riječima, Data model je logična struktura baze podataka. Opisuje kako se podaci pohranjuju i pristupaju te odnose između različitih vrsta podataka.
Odabir pravog modela podataka može biti najteži dio korištenja NoSQL baze podataka poput Cassandra. Kao što sam već spomenula, modeliranje podataka u Cassandri razlikuje se od onoga što vidimo u RDBMS-u.
Pregradni ključ i Cluster tipka su pojmovi kojih bi svatko tko se bavi Cassandrom trebao biti svjestan. Prije nego što uđemo u osnovna pravila modeliranja podataka u Cassandri, pogledajmo što ovi izrazi znače,
pregrada
Cassandra je distribuirana baza podataka u kojoj se podaci dijele i pohranjuju na različite čvorove u klasteru. Podaci se dijele korištenjem particijskog ključa - koji može biti jedno ili više podatkovnih polja. Ovaj se particijski ključ koristi za stvaranje mehanizma za raspršivanje za ravnomjerno širenje podataka po svim čvorovima.
Klastera
Klaster je skup čvorova koji predstavljaju jedinstvenu logičku bazu podataka. Klasterski ključ sastoji se od jednog ili više polja koja se upotrebljavaju za grupiranje podataka u particiji.
U ovom restoranu tablice podaci će se podijeliti pomoću koda države, imena države i grada, a unutar te particije podaci će se grupirati i sortirati na temelju otvorenih podataka i imena restorana.
Pogledajmo sada dva pravila za modeliranje podataka koja bi trebalo imati na umu.
- Podaci su ravnomjerno raspoređeni u cijelom klasteru
- Čitajte s što manje particija
Pogledajmo što ta pravila pokušavaju prenijeti
- Znamo što je klaster ispravno? Klaster se sastoji od više čvorova. Podatke želimo podijeliti među ove čvorove tako da svaki čvor ima približno jednaku količinu podataka. Kao što znamo, podaci se dijele na različite čvorove pomoću hash-a particijskog ključa (koji je prvi ključ primarnog ključa), tako ukratko - "Trebali biste odabrati dobar primarni ključ".
- Svaka particija nalazi se na drugom čvoru, pa kada dohvatite podatke, želite biti sigurni da su podaci prebačeni s što manje particija. Ako vaš upit zahtijeva podatke s različitih particija, izdaje se naredba za odvojene čvorove da biste dobili te podatke, koji će biti nadzemni i dovesti do kašnjenja.
Ključ učinkovitog modela podataka bila bi ravnoteža između ta dva pravila.
Riješite odnose u Cassandri
Jedna stvar koju treba imati na umu je modeliranje podataka u Cassandri, a to se primjenjuje na Query pogon pristupu za razliku od RDBMS-a gdje prvo identificirate entitete, kreirate tablice, a zatim oblikujete upite pomoću JOINS za dohvaćanje podataka.
Jednostavno rečeno, ne modeliramo odnose i objekte, modeliramo upite.
1. Odnos jedan na jedan
Smatramo da se na sveučilištu student može prijaviti samo na jedan seminar. To je odnos jedan na jedan. Pridržavajući se pravila # 1, mislimo na upite koje želimo. Želim potražiti seminar na kojem student pohađa. U ovom slučaju napravit ćemo samo jednu tablicu. Tablica treba sadržavati pojedinosti o studentu i detalje o seminaru.
2. Odnos jedan prema mnogima
U istom kontekstu, što ako bih htjela potražiti sve studente koji pohađaju seminar. Umjesto da koristim istu tablicu i ponavljam svaki redak za dobivanje imena studenta za taj seminar, mogu napraviti drugu tablicu koja podatke dijeli prema nazivu seminara. Kada izdajem upit, on pogađa samo jedan čvor, a ne ide prema svim čvorovima da dobije naziv seminara.
3. Odnos mnogih do mnogih
Sada, razmotrimo, student može pohađati mnogo seminara, a seminaru mogu prisustvovati mnogi studenti. Ovdje imamo mnogo odnosa do mnogih. U ovom slučaju, možete koristiti gore navedene dvije tablice za postavljanje upita, a da pritom nemate problema s postavljanjem složenih upita koristeći Joins što biste obično radili u RDBMS.
Važnost Cassandra
S brzim širenjem digitalnih podataka, sve je važnije uspostaviti visoko skalabilnu bazu podataka otpornu na greške. Dopustite mi da vam napišem nekoliko točaka o tome zašto biste trebali koristiti Cassandra
- Rasvjeta brzim postupcima čitanja: Razgovarali smo o tome kako modeliranje podataka na ispravan način može optimizirati operacije čitanja u ogromnim razmjerama.
- Fault tolerant: Podaci se repliciraju kroz čvorove, pa čak i ako jedan čvor ide prema dolje, podaci su sigurni.
- Prilagođeno podešavanje: Možete postaviti Cassandra da radi u skladu s vašim radnim opterećenjem. Ako pišete puno podataka, poput zapisnika, možete je prilagoditi kako bi se rukovali teškim sustavima. Dostupno je nekoliko drugih opcija podešavanja.
- Suočavanje s velikim količinama podataka: Na temelju veličine klastera, Cassandra se može nositi s velikim količinama podataka.
Kako modelirati podatke u Cassandri?
Dobro modeliranje podataka slijedi ove korake
- Konceptualizirajte upite koje zahtjeva vaša prijava
- Izrada tablica za zadovoljenje tih upita
Prije primjene ovih pravila, jedna stvar koju treba imati na umu je: "Usredotočimo se na optimizaciju naših operacija čitanja, čak i ako zahtijeva dupliciranje podataka". Možemo imati mnogo tablica koje mogu sadržavati gotovo slične podatke.
Sad, razmislite da želimo bazu podataka koja pohranjuje informacije o restoranima. Stavimo ograničenje da nazivi restorana moraju biti jedinstveni.
Tablica u nastavku može se koristiti kada želimo pretraživati na temelju naziva restorana:
Sad ako želimo potražiti restorane za određenu lokaciju, napisali bismo upit koji se ponavlja kroz sve redove i dohvaća nazive restorana.
Umjesto toga, imajući na umu # 2 pravilo, lako možemo izraditi drugu tablicu koja će poslužiti našoj potrebi.
Sada će se naši podaci podijeliti na način da će čvor u klasteru imati restorane za određenu lokaciju. To će optimizirati naše upite za čitanje, jer će se pretraživanje upita odvijati samo na jednom čvoru s mnogo manje redaka od prve tablice koju smo stvorili.
Što ako želimo pretražiti restorane u određenom gradu, možemo napraviti drugu tablicu, a ne ponavljati se kroz sve redove u jednoj particiji gornje tablice.
Zaključak
U ovom sam članku opisao nekoliko najboljih praksi kojih možete slijediti kako pristupiti modeliranju podataka u Cassandri. Ako razumijete ove koncepte i možete učinkovito prepoznati vrstu upita koje vaša aplikacija treba, možete dizajnirati odličan model podataka kako biste postigli visoke performanse iz svoje baze podataka.
Preporučeni članci
Ovo je vodič za Data Model u Cassandri. Ovdje smo raspravljali o načinu modeliranja naših podataka u Cassandri, zajedno s pravilima i važnosti Cassandra Modeli podataka. Možete i proći naše druge predložene članke da biste saznali više -
- Što je modeliranje podataka?
- Modeli podataka u DBMS-u
- Pitanja o intervjuu za modeliranje podataka
- Modeliranje podataka Cassandra