Introduktion til datamodel i Cassandra
Apache Cassandra er blevet en af de mest kraftfulde NoSQL-databaser. Det er det rigtige valg, når du ønsker høj tilgængelighed og skalerbarhed uden at gå på kompromis med ydelsen - især for applikationer, der ikke har råd til at miste data. I dette emne skal vi lære om datamodellen i Cassandra.
En hurtig kendsgerning er Cassandra-ingeniører blandt de mest betalte teknologier i dag. Virksomheder som Netflix, Instagram og Apple bruger Cassandra til at give meget individualiseret kundeoplevelse. For at få den rigtige ydelse skal du nøje designe det skema, der er specifikt for forretningsproblemet. I denne artikel skal vi se på Cassandra-datamodellen, der adskiller sig væsentligt fra det, vi ser i RDBMS.
Cassandra Datamodelregler
I enkle ord er datamodellen den logiske struktur i en database. Den beskriver, hvordan data gemmes og åbnes, og forholdet mellem forskellige typer data.
At vælge den rigtige datamodel kan være den sværeste del af at bruge en NoSQL-database som Cassandra. Som jeg nævnte tidligere er datamodellering i Cassandra forskellig fra hvad vi ser i en RDBMS.
Partitionsnøgle og Clustering-nøgle er de udtryk, som enhver, der beskæftiger sig med Cassandra, skal være opmærksom på. Før vi dykker ned i de grundlæggende regler for datamodellering i Cassandra, lad os hurtigt se på, hvad disse udtryk betyder,
Skillevæg
Cassandra er en distribueret database, hvor data er opdelt og gemt på tværs af forskellige noder i en klynge. Dataene deles ved hjælp af en partitionstast, der kan være et eller flere datafelter. Denne partitionstast bruges til at oprette en hashmekanisme til at sprede data ensartet over alle noder.
Cluster
En klynge er en samling af noder, der repræsenterer en enkelt logisk database. En klynge nøgle består af et eller flere felter, der bruges til at gruppere data sammen i en partition.
I denne tabel restauranter bliver data opdelt ved hjælp af country_code, state_name og city_name, og inden for denne partitionering vil data blive samlet og sorteret baseret på åbningsdata og restaurantnavn.
Lad os nu se på de to regler for datamodellering, der skal huskes.
- Data distribueres jævnt i hele klyngen
- Læs fra så færre partitioner som muligt
Lad os se på, hvad disse regler forsøger at formidle
- Vi ved, hvad en klynge er rigtig? En klynge består af flere noder. Vi vil opdele dataene mellem disse noder, så hver node har nogenlunde den samme mængde data. Som vi ved, er data opdelt i forskellige noder ved hjælp af en hash for partitionstasten (som er den første nøgle til den primære nøgle), så kort sagt ”Du skal vælge en god primær nøgle”.
- Hver partition ligger på en anden knude, så når du henter data, vil du sikre dig, at dataene hentes fra så færre partitioner som muligt. Hvis din forespørgsel kræver data fra forskellige partitioner, udstedes en kommando til at adskille noder for at få dig disse data, som vil være overhead og føre til forsinkelse.
Nøglen til en effektiv datamodel ville være en balance mellem disse to regler.
Håndter forhold i Cassandra
Én ting at huske er datamodellering i Cassandra udføres ved hjælp af forespørgselsdrevet tilgang i modsætning til i RDBMS, hvor du først identificerer enheder, oprette tabeller og derefter danne forespørgsler ved hjælp af JOINS for at hente data.
For at sige det i enkle ord, modellerer vi ikke omkring relationer eller genstande, modellerer vi omkring forespørgsler.
1. Et til et forhold
Overvej på et universitet, at en studerende kun kan tilmelde sig et seminar. Dette er et forhold til én. Ved at holde nr. 1-regel tænker vi på de forespørgsler, vi ønsker. Jeg vil gerne søge på seminaret, som en studerende deltager i. I dette tilfælde laver vi kun en tabel. Tabellen skal indeholde studerendes detaljer og seminaroplysninger.
2. Et til mange forhold
I samme sammenhæng, hvad nu hvis jeg ville søge efter alle de studerende, der deltog i et seminar. I stedet for at bruge den samme tabel og iterere over hver række for at få den studerendes navn til det bestemte seminar, kan jeg lave en anden tabel, der inddeler dataene efter seminarnavnet. Så når jeg udsender forespørgslen, rammer den kun en knude i stedet for at gå til alle knudepunkter for at få seminarnavnet.
3. Mange til mange forhold
Lad os overveje, at en studerende kan deltage i mange seminarer, og et seminar kan deltage i mange studerende. Her har vi mange til mange forhold. I dette tilfælde kan du udnytte de ovenstående to tabeller til at stille forespørgsler uden at have en overhead af at lave komplekse forespørgsler ved hjælp af Joins, som du typisk ville gøre i RDBMS.
Betydningen af Cassandra
Med den hurtige udvidelse af digitale data bliver det vigtigere at have en meget skalerbar, fejltolerant database. Lad mig nævne et par punkter, hvorfor du skal bruge Cassandra
- Belysning af hurtigt læste operationer: Vi diskuterede, hvordan modellering af dine data på den rigtige måde kan optimere læseoperationer i massiv skala.
- Fejltolerant: Data replikeres på tværs af noder, så selv hvis en node går ned, er dine data sikre.
- Tilpasset tuning: Du kan indstille Cassandra til at arbejde i henhold til din arbejdsbyrde. Hvis du skriver en masse data, f.eks. Logging, kan du justere dem for at håndtere skrivetunge systemer. Der er flere andre indstillingsmuligheder tilgængelige.
- Håndtering af høje datamængder: Baseret på klyngestørrelsen kan Cassandra håndtere de enorme datamængder.
Hvordan modelleres dataene i Cassandra?
En god datamodellering følger disse trin
- Konceptualiser de forespørgsler, der kræves af din ansøgning
- Oprettelse af tabeller for at tilfredsstille disse forespørgsler
Inden vi anvender disse regler, er en ting at huske på: ”Vi fokuserer på at optimere vores læseoperationer, selvom det kræver datatuplikation”. Vi kan have mange tabeller, der kan indeholde næsten lignende data.
Overvej nu, at vi ønsker en database, der gemmer information om restauranter. Lad os sætte en begrænsning for, at restaurantnavne skal være unikke.
Tabellen nedenfor kan bruges, når vi ønsker at slå op baseret på restaurantens navn:
Hvis vi nu vil søge restauranterne op efter et bestemt sted, skriver vi en forespørgsel, der gentages gennem alle rækker og henter restaurantnavne.
I stedet for at huske nr. 2-reglen kan vi nemt oprette en anden tabel, der tjener vores behov.
Nu bliver vores data opdelt på en måde, hvor en knude i klyngen har restauranter til et bestemt sted. Dette optimerer vores læste forespørgsler, da opslag af forespørgsler kun vil ske på en knude med meget mindre rækker end den første tabel, vi oprettede.
Hvad hvis vi ville søge restauranter i en bestemt by, kan vi lave en anden tabel snarere end at gentage gennem alle rækker i en enkelt partition af ovenstående tabel.
Konklusion
I denne artikel har jeg dækket et par gode fremgangsmåder, som du kan følge en, hvordan man nærmer sig datamodellering i Cassandra. Hvis du forstår disse koncepter og effektivt kan genkende den slags spørgsmål, som din applikation har brug for, kan du designe en fantastisk datamodel for at få høj ydeevne ud af din database.
Anbefalede artikler
Dette er en guide til datamodel i Cassandra. Her diskuterer vi, hvordan vi modellerer vores data i Cassandra sammen med reglerne og vigtigheden af Cassandra-datamodeller. Du kan også gennemgå vores andre foreslåede artikler for at lære mere -
- Hvad er datamodellering?
- Datamodeller i DBMS
- Spørgsmål om datamodelleringssamtale
- Cassandra Datamodellering