Datamodellering i Cassandra
1. Oversikt
Cassandra er en NoSQL-database som gir høy tilgjengelighet og horisontal skalerbarhet uten å kompromittere ytelsen.
For å få best mulig ytelse ut av Cassandra, må vi nøye utforme skjemaet rundt spørringsmønstre som er spesifikke for forretningsproblemet.
I denne artikkelen vil vi gjennomgå noen av nøkkelbegrepene rundt hvordan man nærmer seg datamodellering i Cassandra.
Før du fortsetter, kan du gå gjennom Cassandra med Java-artikkelen for å forstå det grunnleggende og hvordan du kobler til Cassandra ved hjelp av Java.
2. Partisjonsnøkkel
Cassandra er en distribuert database der data er partisjonert og lagret på tvers av flere noder i en klynge.
Partisjonsnøkkelen består av ett eller flere datafelt og er brukes av partisjoneren til å generere et token via hashing for å distribuere dataene jevnt over en klynge.
3. Clustering Key
En klyngenøkkel består av ett eller flere felt og hjelper til med å klyngre eller gruppere rader med samme partisjonsnøkkel og lagre dem i sortert rekkefølge.
La oss si at vi lagrer tidsseriedata i Cassandra, og vi vil hente dataene i kronologisk rekkefølge. En klyngenøkkel som inkluderer tidsseriedatafelt vil være svært nyttig for effektiv henting av data for denne brukssaken.
Merk: Kombinasjonen av partisjonsnøkkel og klyngenøkkel utgjør den primære nøkkelen og identifiserer alle poster i Cassandra-klyngen unikt.
4. Retningslinjer rundt spørringsmønstre
Før vi begynner med datamodellering i Cassandra, bør vi identifisere spørringsmønstrene og sørge for at de følger følgende retningslinjer:
- Hvert søk skal hente data fra en enkelt partisjon
- Vi bør holde oversikt over hvor mye data som blir lagret i en partisjon, ettersom Cassandra har grenser rundt antall kolonner som kan lagres i en enkelt partisjon
- Det er OK å denormalisere og duplisere dataene for å støtte forskjellige typer spørringsmønstre over de samme dataene
Basert på retningslinjene ovenfor, la oss se på noen virkelige brukssaker og hvordan vi vil modellere Cassandra-datamodellene for dem.
5. Eksempler på virkelige datamodellmodeller
5.1. Facebook Innlegg
Anta at vi lagrer Facebook-innlegg fra forskjellige brukere i Cassandra. Et av de vanlige søkemønstrene henter toppen 'N‘Innlegg laget av en gitt bruker.
Og dermed, vi målagre all data for en bestemt bruker på en enkelt partisjon i henhold til de ovennevnte retningslinjene.
Å bruke poststempelet som klyngenøkkel vil også være nyttig for å hente toppen 'N‘Poster mer effektivt.
La oss definere Cassandra-tabellskjemaet for denne brukssaken:
OPPRETT TABELL posts_facebook (user_id uuid, post_id timeuuid, content text, PRIMARY KEY (user_id, post_id)) WITH CLUSTERING ORDER BY (post_id DESC);La oss nå skrive et spørsmål for å finne de 20 beste innleggene for brukeren Anna:
VELG innhold FRA posts_facebook WHERE user_id = "Anna_id" LIMIT 205.2. Treningssentre over hele landet
Anta at vi lagrer detaljene til forskjellige partner-treningssentre i forskjellige byer og stater i mange land, og vi vil gjerne hente treningssentre for en gitt by.
La oss også si at vi må returnere resultatene med treningssentre sortert etter åpningsdatoen.
Basert på retningslinjene ovenfor, bør vi lagre treningssentrene i en gitt by i en bestemt stat og et land på en enkelt partisjon og bruke åpningsdatoen og treningsnavnet som en klyngenøkkel.
La oss definere Cassandra-tabellskjemaet for dette eksemplet:
OPPRETT TABELL gyms_by_city (landskodetekst, tilstandstekst, bytekst, gym_name-tekst, åpningsdato tidsstempel, PRIMÆR NØKKEL ((landskode, stat_provins, by), (åpningsdato, treningsnavn)) MED KLUSTERORDNING AV (åpningsdato ASC, gym_name ASC);La oss nå se på et spørsmål som henter de ti første treningsstudioene innen åpningsdatoen for byen Phoenix i den amerikanske delstaten Arizona:
VELG * FRA gyms_by_city WHERE country_code = "us" AND state = "Arizona" AND city = "Phoenix" LIMIT 10La oss deretter se et spørsmål som henter de ti sist åpnede treningsstudioene i byen Phoenix i den amerikanske delstaten Arizona:
VELG * FRA gyms_by_city WHERE country_code = "us" og state = "Arizona" og city = "Phoenix" BESTIL MED Åpningsdato DESC LIMIT 10Merk: Siden den siste spørringens sorteringsrekkefølge er motsatt av den sorteringsrekkefølgen som ble definert under opprettelsen av tabellen, vil spørringen kjøre tregere ettersom Cassandra først henter dataene og deretter sorterer dem i minnet.
5.3. E-handel Kunder og produkter
La oss si at vi driver en e-handelsbutikk og at vi lagrer Kunde og Produkt informasjon innen Cassandra. La oss se på noen av de vanlige spørringsmønstrene rundt denne brukssaken:
- Få Kunde info
- Få Produkt info
- Få alt Kunder som liker en gitt Produkt
- Få alt Produkter en gitt Kunde liker
Vi starter med å bruke separate tabeller for lagring av Kunde og Produkt informasjon. Vi må imidlertid innføre en god del denormalisering for å støtte de tredje og fjerde spørsmålene vist ovenfor.
Vi vil lage to tabeller til for å oppnå dette - “Kunde_av_Produkt”Og”Produkt_av_Kunde“.
La oss se på Cassandra-tabellskjemaet for dette eksemplet:
OPPRETT TABELL Kunde (cust_id-tekst, fornavn-tekst, etternavn-tekst, registrert_ på tidsstempel, PRIMÆR NØKKEL (cust_id)); OPPRETT TABELL Produkt (prdt_id tekst, titteltekst, PRIMÆR NØKKEL (prdt_id)); CREATE TABLE Customer_By_Liked_Product (liked_prdt_id text, liked_on timestempel, title text, cust_id text, first_name text, last_name text, PRIMARY KEY (prdt_id, liked_on)) OPPRETT TABELL Product_Liked_By_Customer (cust_id text, first_name text, last_name text, liked_prdt_id text, liked_on timestamp, title text, PRIMARY KEY (cust_id, liked_on));Merk: For å støtte både spørsmålene, nylig likte produkter fra en gitt kunde og kunder som nylig likte et gitt produkt, har vi bruktlikte_på”-Kolonnen som en klyngenøkkel.
La oss se på spørringen for å finne de ti kundene som sist likte produktet “Pepsi“:
VELG * FRA Customer_By_Liked_Product WHERE title = "Pepsi" LIMIT 10Og la oss se spørringen som finner de nylig likte produktene (opptil ti) av en kunde som heter “Anna“:
VELG * FRA Product_Liked_By_Customer WHERE first_name = "Anna" LIMIT 106. Ineffektive spørringsmønstre
På grunn av måten Cassandra lagrer data på, er noen spørringsmønstre ikke effektive, inkludert følgende:
- Henter data fra flere partisjoner - dette vil kreve en koordinator for å hente dataene fra flere noder, lagre dem midlertidig i dyngen, og deretter samle dataene før de returnerer resultatene til brukeren
- Delta-baserte spørsmål - på grunn av sin distribuerte natur støtter ikke Cassandra tabellkommentarer i spørsmål på samme måte som en relasjonsdatabase gjør, og som et resultat, spørsmål medsammenkoblinger vil være tregere og kan også føre til inkonsekvenser og tilgjengelighetsproblemer
7. Konklusjon
I denne veiledningen har vi dekket flere gode fremgangsmåter for hvordan du nærmer deg datamodellering i Cassandra.
Å forstå kjernekonseptene og identifisere spørringsmønstrene på forhånd er nødvendig for å designe en korrekt datamodell som får best ytelse fra en Cassandra-klynge.
