Introduksjon til datamodell i Cassandra
Apache Cassandra har blitt en av de kraftigste NoSQL-databasene. Det er det riktige valget når du vil ha høy tilgjengelighet og skalerbarhet uten å gå på akkord med ytelsen - spesielt for applikasjoner som ikke har råd til å miste data. I dette emnet skal vi lære om datamodellen i Cassandra.
Et raskt faktum, ingeniører fra Cassandra er blant de mest betalte teknikere i dag. Selskaper som Netflix, Instagram og Apple bruker Cassandra for å gi svært individualisert kundeopplevelse. For å oppnå riktig ytelse, må du nøye utforme skjemaet som er spesifikt for forretningsproblemet. I denne artikkelen skal vi se på Cassandra Data Model som er vesentlig forskjellig fra det vi ser i RDBMS.
Cassandra datamodellregler
Datamodell er med enkle ord den logiske strukturen i en database. Den beskriver hvordan data lagres og åpnes, og forholdet mellom forskjellige typer data.
Å velge riktig datamodell kan være den vanskeligste delen av å bruke en NoSQL-database som Cassandra. Som jeg nevnte tidligere, er datamodellering i Cassandra forskjellig fra det vi ser i en RDBMS.
Partisjonstast og Clustering-nøkkel er begrepene alle som arbeider med Cassandra bør være klar over. Før vi dykker inn de grunnleggende reglene for datamodellering i Cassandra, la oss raskt se på hva disse begrepene betyr,
Skillevegg
Cassandra er en distribuert database der data blir delt opp og lagret på tvers av forskjellige noder i en klynge. Dataene blir delt ved å bruke en partisjonstast, som kan være ett eller flere datafelt. Denne partisjonstasten brukes til å lage en hashing-mekanisme for å spre data jevnt over alle nodene.
Cluster
En klynge er en samling noder som representerer en enkelt logisk database. En grupperingstast består av ett eller flere felt som brukes til å gruppere data sammen i en partisjon.
I denne tabellrestaurantene blir data partisjonert ved å bruke country_code, state_name og city_name, og innenfor den partisjonen vil dataene bli gruppert og sortert basert på opening_data og restaurant_name.
La oss nå se på de to reglene for datamodellering som bør huskes.
- Data distribueres jevnt over hele klyngen
- Les fra så færre partisjoner som mulig
La oss se på hva disse reglene prøver å formidle
- Vi vet hva en klynge er riktig? En klynge består av flere noder. Vi vil dele dataene mellom disse nodene slik at hver node har omtrent samme datamengde. Som vi vet, blir data partisjonert i forskjellige noder ved hjelp av en hasj for partisjonstasten (som er den første nøkkelen til Primærnøkkelen), så kort sagt - "Du bør velge en god Primærnøkkel".
- Hver partisjon ligger på en annen node, så når du henter data, vil du sørge for at dataene blir hentet fra så færre partisjoner som mulig. Hvis spørsmålet ditt krever data fra forskjellige partisjoner, vil det bli gitt en kommando for å skille noder for å gi deg disse dataene, som vil være overhead og føre til forsinkelse.
Nøkkelen til en effektiv datamodell ville være en balanse mellom disse to reglene.
Håndter forhold i Cassandra
En ting å huske på er datamodellering i Cassandra ved å bruke spørringsdrevet tilnærming i motsetning til i RDBMS der du først identifiserer enheter, oppretter tabeller og deretter danner spørsmål ved å bruke JOINS for å hente data.
For å si det i enkle ord, modellerer vi ikke rundt forhold eller gjenstander, modellerer vi rundt spørsmål.
1. Forhold mellom ett og ett
Tenk på et universitet en student kan registrere seg på bare ett seminar. Dette er et forhold til én. Ved å holde nr. 1-regelen tenker vi på spørsmålene vi ønsker. Jeg vil søke på seminaret en student deltar på. I dette tilfellet lager vi bare ett bord. Tabellen skal inneholde studentdetaljer og seminardetaljer.
2. En til mange forhold
I samme sammenheng, hva om jeg ville søke etter alle studentene som deltok på et seminar. I stedet for å bruke den samme tabellen og iterere over hver rad for å få studentnavnet til det aktuelle seminaret, kan jeg lage en annen tabell som partisjonerer dataene etter seminarnavn. Så når jeg gir spørsmålet, treffer den bare en node i stedet for å gå til alle nodene for å få seminarnavnet.
3. Mange til mange forhold
La oss vurdere, en student kan delta på mange seminarer, og et seminar kan delta på mange studenter. Her har vi mange til mange forhold. I dette tilfellet kan du utnytte de to tabellene ovenfor for å lage spørsmål uten å ha en overhead av å lage komplekse spørsmål ved å bruke Joins som du vanligvis vil gjøre i RDBMS.
Betydningen av Cassandra
Med den raske utvidelsen av digitale data blir det viktigere å ha en svært skalerbar, feiltolerant database. La meg liste opp noen få punkter på hvorfor du bør bruke Cassandra
- Belysning av hurtiglesningsoperasjoner: Vi diskuterte hvordan modellering av data på riktig måte kan optimalisere leseoperasjoner med stor skala.
- Feiltolerant: Data kopieres på tvers av noder, så selv om en node går ned, er dataene dine trygge.
- Tilpasset innstilling: Du kan stille inn Cassandra til å fungere i henhold til arbeidsmengden din. Hvis du skriver mye data, for eksempel logging, kan du finjustere den for å håndtere skrivetunge systemer. Det er flere andre innstillingsmuligheter tilgjengelig.
- Håndtere høye datamengder: Basert på klyngestørrelsen kan Cassandra takle de enorme datamengdene.
Hvordan modellere dataene i Cassandra?
En god datamodellering følger disse trinnene
- Konseptualiser spørsmålene som kreves av søknaden din
- Opprette tabeller for å tilfredsstille disse spørsmålene
Før vi bruker disse reglene, er en ting å huske på: "Vi fokuserer på å optimalisere leseoperasjonene våre, selv om det krever duplisering av data". Vi kan ha mange tabeller som kan inneholde nesten lignende data.
Vurder nå at vi vil ha en database som lagrer informasjon om restauranter. La oss sette en begrensning i at restaurantnavn må være unike.
Tabellen nedenfor kan brukes når vi ønsker å søke opp basert på restaurantnavnet:
Hvis vi nå vil slå opp restaurantene etter et bestemt sted, vil vi skrive en spørring som gjentas gjennom alle radene og henter restaurantnavn.
I stedet for å huske på regel 2, kan vi enkelt lage en annen tabell som vil tjene vårt behov.
Nå blir dataene våre delt opp på en måte som en nod i klyngen vil ha restauranter for et bestemt sted. Dette vil optimalisere lesespørsmålene våre, ettersom søkeoppslag bare vil skje på en node med mye mindre rader enn den første tabellen vi opprettet.
Hva om vi ville søke restauranter i en bestemt by, kan vi lage et annet bord i stedet for å itere gjennom alle radene i en enkelt partisjon av tabellen ovenfor.
Konklusjon
I denne artikkelen har jeg dekket noen få gode fremgangsmåter du kan følge en hvordan du nærmer meg datamodellering i Cassandra. Hvis du forstår disse konseptene og effektivt kan gjenkjenne den type spørsmål applikasjonen trenger, kan du designe en flott datamodell for å få høy ytelse ut av databasen.
Anbefalte artikler
Dette er en guide til Datamodell i Cassandra. Her diskuterer vi hvordan vi modellerer dataene våre i Cassandra sammen med reglene og viktigheten av Cassandra-datamodeller. Du kan også gå gjennom andre foreslåtte artikler for å lære mer -
- Hva er datamodellering?
- Datamodeller i DBMS
- Datamodelleringsintervju
- Cassandra datamodellering