Introduktion till datamodell i Cassandra
Apache Cassandra har blivit en av de kraftfullaste NoSQL-databaserna. Det är rätt val när du vill ha hög tillgänglighet och skalbarhet utan att kompromissa med prestanda - särskilt för applikationer som inte har råd att förlora data. I det här ämnet kommer vi att lära oss om datamodellen i Cassandra.
Ett snabbt faktum är att Cassandra-ingenjörer är bland de högst betalda teknikerna idag. Företag som Netflix, Instagram och Apple använder Cassandra för att ge en mycket individuell kundupplevelse. För att få rätt prestanda måste du noggrant utforma schemat specifikt för affärsproblemet. I den här artikeln tittar vi på Cassandra Data Model som skiljer sig väsentligt från vad vi ser i RDBMS.
Cassandra Datamodellregler
I enkla ord är datamodell en databas logiska struktur. Den beskriver hur data lagras och nås och förhållandena mellan olika typer av data.
Att välja rätt datamodell kan vara den svåraste delen av att använda en NoSQL-databas som Cassandra. Som jag nämnde tidigare är datamodellering i Cassandra annorlunda än vad vi ser i en RDBMS.
Partitionsnyckel och Clustering-nyckel är de termer som alla som hanterar Cassandra bör vara medvetna om. Innan vi dyker in i de grundläggande reglerna för datamodellering i Cassandra, låt oss snabbt titta på vad dessa termer betyder,
Dela
Cassandra är en distribuerad databas där data delas upp och lagras över olika noder i ett kluster. Data delas upp med en partitionnyckel - som kan vara ett eller flera datafält. Denna partitionsnyckel används för att skapa en hasningsmekanism för att sprida data enhetligt över alla noderna.
Klunga
Ett kluster är en samling noder som representerar en enda logisk databas. En klusternyckel består av ett eller flera fält som används för att gruppera data i en partition.
I denna tabellrestauranger kommer data att partitioneras med country_code, state_name och city_name, och inom den partitionen kommer data att grupperas och sorteras baserat på opening_data och restaurant_name.
Låt oss nu titta på de två reglerna för datamodellering som bör hållas i åtanke.
- Data distribueras jämnt över hela klustret
- Läs från så färre partitioner som möjligt
Låt oss titta på vad dessa regler försöker förmedla
- Vi vet vad ett kluster är rätt? Ett kluster består av flera noder. Vi vill dela upp data mellan dessa noder så att varje nod har ungefär samma mängd data. Som vi vet data är uppdelade i olika noder med hjälp av en hash för partitionsnyckeln (som är den första nyckeln till primärnyckeln), så kort sagt - "Du bör välja en bra primärnyckel".
- Varje partition ligger på en annan nod, så när du hämtar data vill du se till att data hämtas från så färre partitioner som möjligt. Om din fråga kräver data från olika partitioner, kommer ett kommando att utfärdas för att separera noder för att ge dig den informationen, som kommer att vara överhead och leda till latens.
Nyckeln till en effektiv datamodell skulle vara en balans mellan dessa två regler.
Hantera relationer i Cassandra
En sak att tänka på är datamodellering i Cassandra med hjälp av Query driven tillvägagångssätt till skillnad från i RDBMS där du först identifierar enheter, skapar tabeller och sedan formulerar frågor med JOINS för att hämta data.
För att uttrycka det i enkla ord, modellerar vi inte runt relationer eller objekt, vi modellerar runt frågor.
1. En-till-relation
Tänk på ett universitet att en student kan registrera sig för endast ett seminarium. Detta är en en-till-relation. Genom att hålla regel nr 1 tänker vi på de frågor vi vill ha. Jag vill söka efter seminariet som en student deltar på. I det här fallet kommer vi att göra bara ett bord. Tabellen ska innehålla studentinformation och seminariedetaljer.
2. Ett till många förhållande
I samma sammanhang, tänk om jag ville söka efter alla studenter som deltog i ett seminarium. Istället för att använda samma tabell och upprepa över varje rad för att få studentnamnet för det specifika seminariet, kan jag skapa en annan tabell som partitionerar data med namnet på seminariet. Så när jag lämnar frågan träffar den bara en nod istället för att gå till alla noder för att få namnet på seminariet.
3. Många till många förhållanden
Låt oss nu överväga att en student kan delta i många seminarier och ett seminarium kan delta i många studenter. Här har vi många till många relationer. I det här fallet kan du utnyttja ovanstående två tabeller för att göra frågor utan att ha en överhead för att göra komplexa frågor med hjälp av Joins som du vanligtvis skulle göra i RDBMS.
Betydelsen av Cassandra
Med den snabba utvidgningen av digitala data blir det viktigare att ha en mycket skalbar, feltolerant databas på plats. Låt mig lista några punkter på varför du ska använda Cassandra
- Tända snabblästa operationer: Vi diskuterade hur modellering av dina data på rätt sätt kan optimera läsoperationer med massiv skala.
- Feltolerant: Data replikeras över noder så även om en nod går ner är dina data säkra.
- Anpassad inställning: Du kan ställa in Cassandra så att den arbetar enligt din arbetsbelastning. Om du skriver mycket data, som loggning, kan du justera den för att hantera skrivtunga system. Det finns flera andra inställningsalternativ tillgängliga.
- Hantera höga datamängder: Baserat på klusterstorleken kan Cassandra hantera de enorma datamängderna.
Hur modellerar jag data i Cassandra?
En bra datamodellering följer dessa steg
- Konceptualisera de frågor som krävs av din ansökan
- Skapa tabeller för att tillfredsställa dessa frågor
Innan vi tillämpar dessa regler är en sak att tänka på: ”Vi fokuserar på att optimera våra läsoperationer även om det kräver dataduplicering”. Vi kan ha många tabeller som kan innehålla nästan liknande data.
Tänk nu på att vi vill ha en databas som lagrar information om restauranger. Låt oss sätta en begränsning att restaurangnamnen måste vara unika.
Tabellen nedan kan användas när vi vill söka efter restaurangnamnet:
Om vi nu vill leta upp restaurangerna efter en viss plats, skulle vi skriva en fråga som upprepas genom alla rader och hämtar restaurangnamn.
Istället, med tanke på regel nr 2, kan vi enkelt skapa en annan tabell som kommer att tjäna vårt behov.
Nu kommer våra data att delas upp på ett sätt som en nod i klustret har restauranger för en viss plats. Detta kommer att optimera våra läsfrågor, eftersom sökfrågan bara kommer att ske på en nod med mycket mindre rader än den första tabellen vi skapade.
Tänk om vi ville söka restauranger i en viss stad vi kan göra ett annat bord snarare än att iterera genom alla raderna i en enda partition av tabellen ovan.
Slutsats
I den här artikeln har jag täckt några bästa metoder som du kan följa en för att närma dig datamodellering i Cassandra. Om du förstår dessa koncept och effektivt kan känna igen vilken typ av frågor din applikation behöver, kan du designa en bra datamodell för att få hög prestanda från din databas.
Rekommenderade artiklar
Detta är en guide till datamodell i Cassandra. Här diskuterar vi hur vi modellerar våra data i Cassandra tillsammans med reglerna och vikten av Cassandra-datamodeller. Du kan också gå igenom våra andra föreslagna artiklar för att lära dig mer -
- Vad är datamodellering?
- Datamodeller i DBMS
- Datamodelleringsintervju
- Cassandra Data Modeling