streamalism.org

1. Overzicht

Cassandra is een NoSQL-database die hoge beschikbaarheid en horizontale schaalbaarheid biedt zonder afbreuk te doen aan de prestaties.

Om de beste prestaties uit Cassandra te halen, moeten we het schema zorgvuldig ontwerpen rond querypatronen die specifiek zijn voor het zakelijke probleem.

In dit artikel bespreken we enkele van de belangrijkste concepten die er zijn hoe je datamodellering benadert in Cassandra.

Voordat u verder gaat, kunt u ons Cassandra met Java-artikel doornemen om de basisprincipes te begrijpen en om via Java verbinding te maken met Cassandra.

2. Partitiesleutel

Cassandra is een gedistribueerde database waarin gegevens zijn gepartitioneerd en opgeslagen over meerdere knooppunten binnen een cluster.

De partitiesleutel bestaat uit een of meer gegevensvelden en is gebruikt door de partitioner om een ​​token te genereren via hashing om de gegevens uniform over een cluster te verdelen.

3. Clustersleutel

Een clustersleutel bestaat uit een of meer velden en helpt bij het clusteren of groeperen van rijen met dezelfde partitiesleutel en ze in gesorteerde volgorde op te slaan.

Laten we zeggen dat we tijdreeksgegevens opslaan in Cassandra en dat we de gegevens in chronologische volgorde willen ophalen. Een clustersleutel die tijdreeksgegevensvelden bevat, zal zeer nuttig zijn voor het efficiënt ophalen van gegevens voor deze use case.

Opmerking: De combinatie van partitiesleutel en clustersleutel vormt de primaire sleutel en identificeert op unieke wijze elk record in het Cassandra-cluster.

4. Richtlijnen rond querypatronen

Voordat we beginnen met gegevensmodellering in Cassandra, moeten we de querypatronen identificeren en ervoor zorgen dat ze voldoen aan de volgende richtlijnen:

1. Elke query moet gegevens van een enkele partitie ophalen
2. We moeten bijhouden hoeveel gegevens er op een partitie worden opgeslagen, aangezien Cassandra limieten heeft voor het aantal kolommen dat in een enkele partitie kan worden opgeslagen
3. Het is OK om de gegevens te denormaliseren en dupliceren om verschillende soorten querypatronen voor dezelfde gegevens te ondersteunen

Laten we op basis van de bovenstaande richtlijnen eens kijken naar enkele praktijkgevallen en hoe we de Cassandra-datamodellen voor hen zouden modelleren.

5. Voorbeelden van gegevensmodellering uit de praktijk

5.1. Facebook-berichten

Stel dat we Facebook-berichten van verschillende gebruikers in Cassandra opslaan. Een van de meest voorkomende querypatronen is het ophalen van de top ‘N‘Posts gemaakt door een bepaalde gebruiker.

Dus, we moetenbewaar alle gegevens voor een bepaalde gebruiker op een enkele partitie volgens de bovenstaande richtlijnen.

Het gebruik van het tijdstempel van het bericht als de clustersleutel zal ook nuttig zijn voor het ophalen van de top ‘N‘Posts efficiënter.

Laten we het Cassandra-tabelschema definiëren voor deze use case:

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

Laten we nu een zoekopdracht schrijven om de top 20 berichten voor de gebruiker te vinden Anna:

SELECTEER inhoud VAN posts_facebook WHERE user_id = "Anna_id" LIMIET 20

5.2. Sportscholen in het hele land

Stel dat we de gegevens van verschillende partner-sportscholen in de verschillende steden en staten van veel landen opslaan en dat we de sportscholen voor een bepaalde stad willen ophalen.

Laten we ook zeggen dat we de resultaten moeten retourneren met sportscholen gesorteerd op hun openingsdatum.

Op basis van de bovenstaande richtlijnen moeten we de sportscholen in een bepaalde stad van een specifieke staat en land op een enkele partitie opslaan en de openingsdatum en de naam van de sportschool gebruiken als een clustersleutel.

Laten we voor dit voorbeeld het Cassandra-tabelschema definiëren:

CREATE TABLE gyms_by_city (land_code tekst, staatstekst, stadstekst, gym_naam tekst, opening_datum tijdstempel, PRIMAIRE SLEUTEL ((land_code, staat_province, stad), (openingsdatum, gym_naam)) MET CLUSTERING VOLGENS (openingsdatum ASC, gym_naam ASC);

Laten we nu eens kijken naar een zoekopdracht die de eerste tien sportscholen ophaalt op hun openingsdatum voor de stad Phoenix in de Amerikaanse staat Arizona:

SELECTEER * VAN gyms_by_city WHERE country_code = "us" AND state = "Arizona" AND city = "Phoenix" LIMIET 10

Laten we vervolgens een zoekopdracht bekijken die de tien meest recent geopende sportscholen in de stad Phoenix in de Amerikaanse staat Arizona ophaalt:

SELECTEER * VAN gyms_by_city WHERE country_code = "us" en state = "Arizona" en city = "Phoenix" ORDER BY opening_date DESC LIMIT 10

Opmerking: aangezien de sorteervolgorde van de laatste query tegengesteld is aan de sorteervolgorde die is gedefinieerd tijdens het maken van de tabel, zal de query langzamer werken omdat Cassandra eerst de gegevens ophaalt en deze vervolgens in het geheugen sorteert.

5.3. E-commerceklanten en -producten

Laten we zeggen dat we een e-commerce winkel runnen en dat we het Klant en Product informatie binnen Cassandra. Laten we eens kijken naar enkele veelvoorkomende querypatronen rond deze use case:

1. Krijgen Klant info
2. Krijgen Product info
3. Alles krijgen Klanten die van een gegeven houden Product
4. Alles krijgen Producten een gegeven Klant houdt van

We beginnen met het gebruik van aparte tabellen voor het opslaan van het Klant en Product informatie. We moeten echter een behoorlijke hoeveelheid denormalisatie introduceren om de 3e en 4e query hierboven te ondersteunen.

We zullen nog twee tabellen maken om dit te bereiken: "Customer_by_Product"En"Product_door_klant“.

Laten we voor dit voorbeeld eens kijken naar het Cassandra-tabelschema:

CREATE TABLE Customer (cust_id text, first_name text, last_name text, registered_on timestamp, PRIMARY KEY (cust_id)); CREATE TABLE Product (prdt_id tekst, titeltekst, PRIMAIRE SLEUTEL (prdt_id)); TABEL MAKEN Customer_By_Liked_Product (like_prdt_id text, like_on timestamp, title text, cust_id text, first_name text, last_name text, PRIMAIRE SLEUTEL (prdt_id, like_on)); CREATE TABLE Product_Liked_By_Customer (cust_id text, first_name text, last_name text, like_prdt_id text, like_on timestamp, title text, PRIMARY KEY (cust_id, like_on));

Opmerking: ter ondersteuning van zowel de vragen, recent gelikete producten van een bepaalde klant als klanten die recentelijk een bepaald product leuk vonden, hebben we de "vond_op”Kolom als een clustersleutel.

Laten we eens kijken naar de zoekopdracht om de tien klanten te vinden die het product het laatst leuk vonden "Pepsi“:

SELECTEER * VAN Customer_By_Liked_Product WAAR title = "Pepsi" LIMIET 10

En laten we eens kijken naar de zoekopdracht die de producten die u onlangs leuk vond (maximaal tien) vindt door een klant met de naam 'Anna“:

SELECT * FROM Product_Liked_By_Customer WHERE first_name = "Anna" LIMIET 10

6. Inefficiënte zoekpatronen

Vanwege de manier waarop Cassandra gegevens opslaat, zijn sommige querypatronen helemaal niet efficiënt, waaronder de volgende:

• Gegevens ophalen van meerdere partities - hiervoor is een coördinator nodig om de gegevens van meerdere knooppunten op te halen, deze tijdelijk in heap op te slaan en vervolgens de gegevens samen te voegen voordat de resultaten naar de gebruiker worden teruggestuurd
• Op samenvoeging gebaseerde vragen - vanwege het gedistribueerde karakter ondersteunt Cassandra tabeljoins in query's niet op dezelfde manier als een relationele database, en als gevolg daarvan, vragen metjoins zullen langzamer zijn en kunnen ook leiden tot inconsistentie en beschikbaarheidsproblemen

7. Conclusie

In deze tutorial hebben we verschillende best practices behandeld voor het benaderen van datamodellering in Cassandra.

Het begrijpen van de kernconcepten en het vooraf identificeren van de querypatronen is noodzakelijk om een ​​correct datamodel te ontwerpen dat de beste prestaties haalt uit een Cassandra-cluster.