Johdatus datamalliin Cassandrassa
Apache Cassandrasta on tullut yksi tehokkaimmista NoSQL-tietokannoista. Se on oikea valinta, kun haluat suuren saatavuuden ja skaalautuvuuden vaarantamatta suorituskykyä - etenkin sovelluksissa, joilla ei ole varaa menettää tietoja. Tässä aiheessa aiomme oppia Cassandran datamallista.
Nopea tosiasia, Cassandran insinöörit ovat nykyään eniten maksettuja tekniikan ammattilaisia. Netflix, Instagram ja Apple, kuten Cassandra, tarjoavat erittäin yksilöllisiä asiakaskokemuksia. Oikean suorituskyvyn saamiseksi sinun on suunniteltava huolellisesti liiketoimintaongelmaan liittyvä kaavio. Tässä artikkelissa tarkastellaan Cassandran datamallia, joka eroaa huomattavasti RDBMS: n näkemästä.
Cassandran datamallin säännöt
Yksinkertaisin sanoin, Datamalli on tietokannan looginen rakenne. Se kuvaa, kuinka tietoja tallennetaan ja miten niitä käsitellään, sekä suhdetta erityyppisiin tietoihin.
Oikean tietomallin valitseminen voi olla vaikeinta käyttää NoSQL-tietokantaa, kuten Cassandra. Kuten aiemmin mainitsin, tietojen mallintaminen Cassandrassa on erilainen kuin mitä näemme RDBMS: ssä.
Osioavain ja klusterointiavain ovat termejä, jotka kaikkien Cassandraan liittyvien asioiden tulisi olla tietoisia. Ennen kuin harkitsemme tietojen mallinnuksen perussääntöjä Cassandrassa, katsokaamme nopeasti, mitä nämä termit tarkoittavat,
väliseinä
Cassandra on hajautettu tietokanta, jossa tiedot osioidaan ja tallennetaan klusterin eri solmujen yli. Tiedot jaetaan osioavaimella, joka voi olla yksi tai useampi tietokenttä. Tätä osioavainta käytetään luomaan hajautusmekanismi datan jakamiseksi tasaisesti kaikille solmuille.
rykelmä
Klusteri on kokoelma solmuja, jotka edustavat yhtä loogista tietokantaa. Klusterointiavain koostuu yhdestä tai useammasta kentästä, joita käytetään tietojen ryhmittelemiseen osioon.
Tässä taulukossa ravintoloissa tiedot osioidaan käyttämällä maakoodia, osavaltion nimeä ja kaupunkinimeä, ja osion tiedot ryhmitellään ja lajitellaan avaustietojen ja ravintolan_nimien perusteella.
Tarkastellaan nyt kahta tietojen mallintamista koskevaa sääntöä, jotka tulisi pitää mielessä.
- Tiedot jakautuvat tasaisesti klusteriin
- Lue mahdollisimman harvoista osioista
Katsotaanpa mitä nämä säännöt yrittävät välittää
- Tiedämme, mikä klusteri on oikeassa? Ryhmä koostuu useista solmuista. Haluamme jakaa datan näiden solmujen kesken siten, että jokaisella solmulla on suunnilleen sama määrä dataa. Kuten tiedämme, data on jaettu eri solmuihin käyttämällä osioavaimen hajautusta (joka on ensisijaisen avaimen ensimmäinen avain), joten lyhyesti sanottuna - "Sinun tulisi valita hyvä ensisijainen avain".
- Jokainen osio sijaitsee eri solmulla, joten haettaessa tietoja haluat varmistaa, että tiedot noudetaan mahdollisimman harvoista osioista. Jos kyselysi vaatii tietoja eri osioista, komento annetaan erillisille solmuille, jotta saat nämä tiedot, jotka ovat yläpuolella ja johtavat viiveeseen.
Avain tehokkaaseen tietomalliin olisi tasapaino näiden kahden säännön välillä.
Käsittele suhteita Cassandrassa
Yksi asia, joka on pidettävä mielessä, on Cassandrassa tapahtuva tietojen mallintaminen käyttämällä kyselypohjaista lähestymistapaa, toisin kuin RDBMS: ssä, jossa ensin tunnistetaan entiteetit, luodaan taulukot ja muodostetaan kyselyitä käyttämällä JOINS-tietoja tietojen noutamiseksi.
Yksinkertaisesti sanottuna, emme mallinnusta suhteiden tai esineiden ympärille, vaan mallinnamme kyselyiden ympärille.
1. Yksi suhde
Harkitse yliopistossa opiskelija voi ilmoittautua vain yhteen seminaariin. Tämä on yhden suhteen suhde. Pitämällä # 1-sääntöä ajattelemme haluamiamme kyselyjä. Haluan etsiä seminaaria, johon opiskelija osallistuu. Tässä tapauksessa teemme vain yhden pöydän. Taulukon tulisi sisältää opiskelijan tiedot ja seminaaritiedot.
2. Yksi moniin -suhde
Entä jos samassa yhteydessä haluaisin etsiä kaikki seminaariin osallistuvat opiskelijat. Sen sijaan, että käyttäisin samaa taulukkoa ja iteroin jokaisen rivin yli saadaksesi kyseisen seminaarin opiskelijan nimen, voin tehdä toisen taulukon, joka jakaa tiedot seminaarin nimen mukaan. Joten kun annan kyselyn, se osuu vain yhteen solmuun sen sijaan, että menisi kaikkiin solmuihin saadakseen seminaarin nimen.
3. Monien suhteet
Tarkastellaan nyt, että opiskelija voi osallistua moniin seminaareihin, ja seminaariin voi osallistua monia opiskelijoita. Täällä meillä on monista moniin suhteita. Tässä tapauksessa voit hyödyntää kahta edellä mainittua taulukkoa kyselyjen tekemiseen ilman, että sinun tarvitsee tehdä ylimääräisiä kyselyjä Joinsin avulla, mitä tekisit yleensä RDBMS: ssä.
Cassandran merkitys
Digitaalisen datan nopean laajentumisen myötä on tärkeämpää saada erittäin skaalautuva, vikasietoinen tietokanta paikallaan. Saanen luetella muutamia kohtia siitä, miksi sinun pitäisi käyttää Cassandraa
- Nopeiden lukutoimintojen valaistus: Keskustelemme siitä, kuinka tietosi oikealla mallinnuksella voidaan optimoida lukutoiminnot massiivisella mittakaavalla.
- Vikasietoiset: Tiedot kopioidaan solmujen välillä, joten vaikka tietyn solmun arvo menee alas, tietosi ovat turvassa.
- Mukautettu viritys: Voit määrittää Cassandran toimimaan työmääränne mukaan. Jos kirjoitat paljon tietoa, kuten lokitietoja, voit säätää sen käsittelemään raskaiden kirjoitusjärjestelmien. On olemassa useita muita viritysvaihtoehtoja.
- Suurten tietomäärien käsittely: klusterin koon perusteella Cassandra pystyy käsittelemään valtavia tietomääriä.
Kuinka mallintaa tietoja Cassandrassa?
Hyvä tietojen mallintaminen seuraa näitä vaiheita
- Käsittele hakemuksesi edellyttämät kyselyt
- Taulukoiden luominen näiden kyselyjen tyydyttämiseksi
Ennen näiden sääntöjen soveltamista on pidettävä mielessä yksi asia: ”Keskitymme lukemamme optimointiin, vaikka se vaatii tietojen päällekkäisyyttä”. Meillä voi olla monia taulukoita, jotka saattavat sisältää lähes samanlaista tietoa.
Ajattele nyt, että haluamme tietokannan, joka tallentaa tietoja ravintoloista. Asetetaan rajoitus, jonka mukaan ravintolanimien on oltava ainutlaatuisia.
Seuraavaa taulukkoa voidaan käyttää, kun haluamme etsiä ravintolan nimen perusteella:
Nyt jos haluamme etsiä ravintoloita tietystä sijainnista, kirjoittaisimme kyselyn, joka toistuu kaikkien rivien läpi ja noutaa ravintolanimet.
Sen sijaan, pitäen mielessä # 2 -sääntö, voimme helposti luoda uuden taulukon, joka palvelee tarpeitamme.
Nyt tietomme osioidaan siten, että klusterin solmulla on ravintoloita tietylle sijainnille. Tämä optimoi lukemat kyselyt, koska kyselyhaku tapahtuu vain yhdellä solmulla, jossa on paljon vähemmän rivejä kuin ensimmäisessä luomassamme taulukossa.
Entä jos halusimme etsiä tietyssä kaupungissa sijaitsevia ravintoloita, voimme tehdä uuden taulukon sen sijaan, että iteroisimme kaikkien rivien läpi yhdellä yllä olevan taulukon osiolla.
johtopäätös
Tässä artikkelissa olen käsitellyt muutamia parhaita käytäntöjä, joita voit seurata, kuinka lähestyä tiedon mallintamista Cassandrassa. Jos ymmärrät nämä käsitteet ja pystyt tunnistamaan tehokkaasti sovelluksesi tarvitsemat kyselyt, voit suunnitella loistavan tietomallin saadaksesi suuren suorituskyvyn tietokannastasi.
Suositellut artikkelit
Tämä on opas Data malliin Cassandrassa. Tässä keskustellaan siitä, miten mallinntaa tietojamme Cassandrassa Cassandran datamallien sääntöjen ja merkityksen kanssa. Voit myös käydä läpi muiden ehdotettujen artikkeleidemme saadaksesi lisätietoja -
- Mikä on tietojen mallintaminen?
- Tietomallit DBMS: ssä
- Tietojen mallinnushaastattelukysymykset
- Cassandran datan mallintaminen