Inleiding tot datamodel in Cassandra
Apache Cassandra is een van de krachtigste NoSQL-databases geworden. Het is de juiste keuze als u hoge beschikbaarheid en schaalbaarheid wilt zonder concessies te doen aan de prestaties, vooral voor toepassingen die het zich niet kunnen veroorloven gegevens te verliezen. In dit onderwerp gaan we meer te weten komen over het datamodel in Cassandra.
Een snel gegeven: de ingenieurs van Cassandra behoren vandaag tot de best betaalde technische professionals. Bedrijven zoals Netflix, Instagram en Apple gebruiken Cassandra om een zeer individuele klantervaring te bieden. Om de juiste prestaties te krijgen, moet u het schema dat specifiek is voor het bedrijfsprobleem zorgvuldig ontwerpen. In dit artikel kijken we naar het Cassandra-gegevensmodel dat aanzienlijk verschilt van wat we in RDBMS zien.
Cassandra-gegevensmodelregels
In eenvoudige woorden, datamodel is de logische structuur van een database. Het beschrijft hoe gegevens worden opgeslagen en benaderd, en de relaties tussen verschillende soorten gegevens.
Het kiezen van het juiste datamodel kan het moeilijkste onderdeel zijn van het gebruik van een NoSQL-database zoals Cassandra. Zoals ik al eerder zei, is datamodellering in Cassandra anders dan wat we in een RDBMS zien.
Partitiesleutel en Clustering-sleutel zijn de voorwaarden waar iedereen die met Cassandra te maken heeft zich bewust van moet zijn. Voordat we in de basisregels van gegevensmodellering in Cassandra duiken, laten we snel kijken naar wat deze termen betekenen,
tussenschot
Cassandra is een gedistribueerde database waarin gegevens worden gepartitioneerd en opgeslagen over verschillende knooppunten in een cluster. De gegevens worden geportioneerd met behulp van een partitiesleutel - dit kunnen een of meer gegevensvelden zijn. Deze partitiesleutel wordt gebruikt om een hashing-mechanisme te maken om gegevens uniform over alle knooppunten te verspreiden.
TROS
Een cluster is een verzameling knooppunten die een enkele logische database vertegenwoordigen. Een clustersleutel bestaat uit een of meer velden die worden gebruikt om gegevens in een partitie te groeperen.
In deze tabelrestaurants worden gegevens gepartitioneerd met behulp van landcode, staatnaam en plaatsnaam, en binnen die partitie worden gegevens geclusterd en gesorteerd op basis van openingsgegevens en restaurantnaam.
Laten we nu eens kijken naar de twee regels voor gegevensmodellering die in gedachten moeten worden gehouden.
- Gegevens worden gelijkmatig over het cluster verdeeld
- Lees van zo min mogelijk partities
Laten we eens kijken wat deze regels proberen over te brengen
- We weten wat een cluster klopt? Een cluster bestaat uit meerdere knooppunten. We willen de gegevens onder deze knooppunten verdelen zodat elk knooppunt ongeveer dezelfde hoeveelheid gegevens heeft. Zoals we weten, worden gegevens in verschillende knooppunten gepartitioneerd met behulp van een hash van de partitiesleutel (wat de eerste sleutel van de primaire sleutel is), dus in het kort: "U moet een goede primaire sleutel kiezen".
- Elke partitie bevindt zich op een ander knooppunt, dus wanneer u gegevens ophaalt, wilt u ervoor zorgen dat de gegevens uit zo min mogelijk partities worden opgehaald. Als uw zoekopdracht gegevens van verschillende partities vereist, wordt een opdracht uitgegeven om afzonderlijke knooppunten te verkrijgen om u die gegevens te bezorgen, die overhead zijn en tot latentie leiden.
De sleutel tot een efficiënt gegevensmodel zou een evenwicht tussen deze twee regels zijn.
Omgaan met relaties in Cassandra
Een ding om in gedachten te houden is datamodellering in Cassandra wordt gedaan met behulp van Query-gedreven aanpak in tegenstelling tot RDBMS waar u eerst entiteiten identificeert, tabellen maakt en vervolgens query's vormt met JOINS om gegevens op te halen.
Om het simpel uit te drukken, we modelleren niet rond relaties of objecten, we modelleren rond vragen.
1. Eén op één relatie
Overweeg op een universiteit dat een student zich voor slechts één seminar kan aanmelden. Dit is een één op één relatie. Met de # 1 regel denken we aan de vragen die we willen. Ik wil zoeken naar het seminar dat een student bijwoont. In dit geval zullen we slechts één tabel maken. De tabel moet de studentgegevens en de seminardetails bevatten.
2. Eén op veel relaties
Wat als ik in dezelfde context naar alle studenten wilde zoeken die een seminar bijwoonden? In plaats van dezelfde tabel te gebruiken en elke rij te herhalen om de studentnaam voor dat specifieke seminar te krijgen, kan ik een andere tabel maken die de gegevens verdeelt op seminarnaam. Dus wanneer ik de query geef, raakt deze slechts één knooppunt in plaats van naar alle knooppunten te gaan om de seminarnaam te krijgen.
3. Veel tot veel relaties
Laten we nu eens kijken, een student kan veel seminars bijwonen en een seminar kan door veel studenten worden bijgewoond. Hier hebben we veel tot veel relaties. In dit geval kunt u de bovenstaande twee tabellen gebruiken om query's te maken zonder complexe overheadvragen te maken met behulp van Joins, wat u normaal gesproken zou doen in RDBMS.
Het belang van Cassandra
Met de snelle uitbreiding van digitale gegevens wordt het belangrijker om een zeer schaalbare, fouttolerante database te hebben. Laat me een paar punten opsommen waarom u Cassandra zou moeten gebruiken
- Snelle leesbewerkingen aansteken: we hebben besproken hoe het modelleren van uw gegevens op de juiste manier leesbewerkingen op grote schaal kan optimaliseren.
- Fouttolerant: gegevens worden over knooppunten gerepliceerd, dus zelfs als een knoop uitvalt, zijn uw gegevens veilig.
- Aangepaste afstemming: u kunt Cassandra instellen om te werken op basis van uw werklast. Als u veel gegevens schrijft, zoals logboekregistratie, kunt u deze aanpassen om schrijfzware systemen te verwerken. Er zijn verschillende andere afstemmingsopties beschikbaar.
- Omgaan met grote datavolumes: Op basis van de clustergrootte kan Cassandra omgaan met de enorme datavolumes.
Hoe de gegevens in Cassandra te modelleren?
Een goede datamodellering volgt deze stappen
- Conceptualiseer de vragen die vereist zijn voor uw toepassing
- Tabellen maken om aan die vragen te voldoen
Voordat we deze regels toepassen, is een ding om in gedachten te houden: "We richten ons op het optimaliseren van onze leesoperaties, zelfs als het gegevensduplicatie vereist". We kunnen veel tabellen hebben die bijna vergelijkbare gegevens kunnen bevatten.
Overweeg nu dat we een database willen waarin informatie over restaurants wordt opgeslagen. Laten we de beperking opleggen dat restaurantnamen uniek moeten zijn.
De onderstaande tabel kan worden gebruikt wanneer we willen zoeken op basis van de restaurantnaam:
Als we nu de restaurants voor een bepaalde locatie willen opzoeken, zouden we een zoekopdracht schrijven die alle rijen doorloopt en restaurantnamen ophaalt.
In plaats daarvan kunnen we, rekening houdend met regel # 2, eenvoudig een andere tabel maken die aan onze behoefte voldoet.
Nu worden onze gegevens zodanig gepartitioneerd dat een knooppunt in het cluster restaurants voor een bepaalde locatie heeft. Dit optimaliseert onze leesquery's, omdat het opzoeken van query's slechts op één knooppunt met veel minder rijen zal plaatsvinden dan de eerste tabel die we hebben gemaakt.
Wat als we restaurants in een bepaalde stad wilden zoeken, kunnen we een andere tabel maken in plaats van alle rijen in een enkele partitie van de bovenstaande tabel te doorlopen.
Conclusie
In dit artikel heb ik enkele best practices behandeld die u kunt volgen om gegevensmodellering in Cassandra te benaderen. Als u deze concepten begrijpt en het soort vragen dat uw toepassing nodig heeft, efficiënt kan herkennen, kunt u een geweldig gegevensmodel ontwerpen om hoge prestaties uit uw database te halen.
Aanbevolen artikelen
Dit is een gids voor datamodel in Cassandra. Hier bespreken we hoe we onze gegevens in Cassandra kunnen modelleren, samen met de regels en het belang van Cassandra-gegevensmodellen. U kunt ook onze andere voorgestelde artikelen doornemen voor meer informatie -
- Wat is gegevensmodellering?
- Gegevensmodellen in DBMS
- Sollicitatievragen voor Data Modeling
- Cassandra-gegevensmodellering