streamalism.org

1. Oversigt

Cassandra er en NoSQL-database, der giver høj tilgængelighed og vandret skalerbarhed uden at gå på kompromis med ydeevnen.

For at få den bedste ydelse ud af Cassandra er vi nødt til omhyggeligt at designe skemaet omkring forespørgselsmønstre, der er specifikke for det aktuelle forretningsproblem.

I denne artikel vil vi gennemgå nogle af de centrale begreber omkring hvordan man nærmer sig datamodellering i Cassandra.

Før du fortsætter, kan du gå gennem vores Cassandra med Java-artikel for at forstå det grundlæggende og hvordan du opretter forbindelse til Cassandra ved hjælp af Java.

2. Partitionsnøgle

Cassandra er en distribueret database, hvor data er partitioneret og lagret på tværs af flere noder i en klynge.

Partitionsnøglen består af et eller flere datafelter og er bruges af partitioneren til at generere et token via hashing for at distribuere data ensartet over en klynge.

3. Clustering Key

En klyngenøgle består af et eller flere felter og hjælper med at klynge eller gruppere rækker med samme partitionsnøgle og gemme dem i sorteret rækkefølge.

Lad os sige, at vi lagrer tidsseriedata i Cassandra, og vi vil hente dataene i kronologisk rækkefølge. En klyngenøgle, der inkluderer dataserier i tidsserier, vil være meget nyttigt til effektiv hentning af data til denne brugssag.

Bemærk: Kombinationen af ​​partitionsnøgle og klyngenøgle udgør den primære nøgle og identificerer entydigt enhver post i Cassandra-klyngen.

4. Retningslinjer omkring forespørgselsmønstre

Før vi starter med datamodellering i Cassandra, skal vi identificere forespørgselsmønstre og sikre, at de overholder følgende retningslinjer:

1. Hver forespørgsel skal hente data fra en enkelt partition
2. Vi skal holde styr på, hvor meget data der gemmes i en partition, da Cassandra har grænser for antallet af kolonner, der kan lagres i en enkelt partition
3. Det er OK at denormalisere og duplikere dataene for at understøtte forskellige slags forespørgselsmønstre over de samme data

Baseret på ovenstående retningslinjer, lad os se på nogle brugssager i den virkelige verden, og hvordan vi modellerer Cassandra-datamodellerne for dem.

5. Eksempler på virkelige datamodelleringsmodeller

5.1. Facebook-indlæg

Antag, at vi gemmer Facebook-indlæg fra forskellige brugere i Cassandra. Et af de almindelige forespørgselsmønstre henter toppen 'N‘Indlæg lavet af en given bruger.

Dermed, vi er nødt tilgemme alle data for en bestemt bruger på en enkelt partition i henhold til ovenstående retningslinjer.

Brug af poststempelet som klyngetasten vil også være nyttigt for at hente toppen 'N'Indlæg mere effektivt.

Lad os definere Cassandra-tabelskemaet til denne brugssag:

OPRET TABEL posts_facebook (user_id uuid, post_id timeuuid, content text, PRIMARY KEY (user_id, post_id)) WITH CLUSTERING ORDER BY (post_id DESC);

Lad os nu skrive en forespørgsel for at finde de 20 bedste indlæg til brugeren Anna:

VÆLG indhold FRA posts_facebook WHERE user_id = "Anna_id" LIMIT 20

5.2. Fitnesscentre over hele landet

Antag, at vi gemmer detaljerne i forskellige partner-motionscentre i forskellige byer og stater i mange lande, og vi vil gerne hente motionscentre til en given by.

Lad os også sige, at vi skal returnere resultaterne med fitnesscentre sorteret efter deres åbningsdato.

Baseret på ovenstående retningslinjer skal vi gemme motionsrumene i en given by i en bestemt stat og et bestemt land på en enkelt partition og bruge åbningsdatoen og gymnastiksalen som en klyngenøgle.

Lad os definere Cassandra-tabelskemaet til dette eksempel:

OPRET TABEL gyms_by_city (landekodetekst, tilstandstekst, bytekst, gymnastiknavnstekst, åbningsdato tidsstempel, PRIMÆRT NØGLE ((landekode, stat_provins, by), (åbningsdato, gymnastiknavn)) MED KLUSTERINGSORDEN BY (åbningsdato ASC, gym_name ASC);

Lad os nu se på en forespørgsel, der henter de første ti fitnesscentre inden deres åbningsdato for byen Phoenix i den amerikanske delstat Arizona:

VÆLG * FRA gyms_by_city WHERE country_code = "os" OG state = "Arizona" OG city = "Phoenix" LIMIT 10

Lad os derefter se en forespørgsel, der henter de ti senest åbnede fitnesscentre i byen Phoenix i den amerikanske delstat Arizona:

VÆLG * FRA gyms_by_city WHERE country_code = "os" og state = "Arizona" og city = "Phoenix" BESTIL VED åbningsdato DESC LIMIT 10

Bemærk: Da den sidste forespørgsels sorteringsrækkefølge er modsat af den sorteringsrækkefølge, der er defineret under oprettelsen af ​​tabellen, kører forespørgslen langsommere, da Cassandra først henter dataene og derefter sorterer dem i hukommelsen.

5.3. E-handel kunder og produkter

Lad os sige, at vi kører en e-handelsbutik, og at vi opbevarer Kunde og Produkt information inden for Cassandra. Lad os se på nogle af de almindelige forespørgselsmønstre omkring denne brugssag:

1. Få Kunde info
2. Få Produkt info
3. Få alle Kunder der kan lide en given Produkt
4. Få alle Produkter en given Kunde kan lide

Vi starter med at bruge separate tabeller til opbevaring af Kunde og Produkt Information. Vi er dog nødt til at indføre en hel del denormalisering for at understøtte de 3. og 4. forespørgsler vist ovenfor.

Vi opretter yderligere to tabeller for at opnå dette - “Kunde_af_Produkt”Og“Produkt_af_Kunde“.

Lad os se på Cassandra-tabelskemaet til dette eksempel:

OPRET TABEL Kunde (cust_id tekst, fornavn tekst, efternavn tekst, registreret_on tidsstempel, PRIMÆR NØGLE (cust_id)); Opret TABEL Produkt (prdt_id tekst, titeltekst, PRIMÆR NØGLE (prdt_id)); OPRET TABEL Customer_By_Liked_Product (liked_prdt_id tekst, liked_on tidsstempel, titeltekst, cust_id tekst, fornavn tekst, efternavn tekst, PRIMÆR NØGLE (prdt_id, likes_on)); OPRET TABEL Produkt_Liked_By_Customer (cust_id tekst, first_name text, last_name text, liked_prdt_id text, liked_on tidsstempel, titeltekst, PRIMÆR NØGLE (cust_id, liked_on));

Bemærk: For at understøtte både forespørgsler, produkter, som nylig er lide af en given kunde og kunder, der for nylig har ønsket et givet produkt, har vi brugt "kunne lide_on”Kolonne som en klyngenøgle.

Lad os se på forespørgslen for at finde de ti kunder, der senest kunne lide produktet “Pepsi“:

VÆLG * FRA Customer_By_Liked_Product WHERE title = "Pepsi" LIMIT 10

Og lad os se forespørgslen, der finder de nyligt lide produkter (op til ti) af en kunde ved navn “Anna“:

VÆLG * FRA Product_Liked_By_Customer WHERE first_name = "Anna" LIMIT 10

6. Ineffektive forespørgselsmønstre

På grund af den måde, Cassandra lagrer data på, er nogle forespørgselsmønstre slet ikke effektive, herunder følgende:

• Henter data fra flere partitioner - dette vil kræve, at en koordinator henter dataene fra flere noder, gemmer dem midlertidigt i bunke og derefter aggregerer dataene, før resultaterne returneres til brugeren
• Deltagelsesbaserede forespørgsler - på grund af sin distribuerede karakter understøtter Cassandra ikke tabeltilslutninger i forespørgsler på samme måde som en relationsdatabase gør, og som et resultat forespørgsler medsammenføjninger vil være langsommere og kan også føre til inkonsistens og problemer med tilgængelighed

7. Konklusion

I denne vejledning har vi dækket adskillige bedste praksis omkring, hvordan man nærmer sig datamodellering i Cassandra.

At forstå kernebegreberne og identificere forespørgselsmønstrene på forhånd er nødvendigt for at designe en korrekt datamodel, der får den bedste ydeevne fra en Cassandra-klynge.