Sebbene il linguaggio di query Cassandra assomigli al linguaggio SQL, i loro metodi di modellazione dei dati sono completamente diversi.
In Cassandra, un modello di dati non valido può ridurre le prestazioni, soprattutto quando gli utenti tentano di implementare i concetti RDBMS su Cassandra. È meglio tenere a mente alcune regole dettagliate di seguito.
In questo tutorial imparerai-
- Regole del modello di dati Cassandra
- Modella i tuoi dati in Cassandra
- Gestione del rapporto uno a uno
- Gestire relazioni da uno a molti
- Gestione della relazione molti a molti
Regole del modello di dati Cassandra
In Cassandra, le scritture non sono costose. Cassandra non supporta join, group by, clausole OR, aggregazioni, ecc. Quindi devi memorizzare i tuoi dati in modo tale che siano completamente recuperabili. Quindi queste regole devono essere tenute a mente durante la modellazione dei dati in Cassandra.
- Massimizza il numero di scritture
In Cassandra, le scritture costano molto poco. Cassandra è ottimizzata per prestazioni di scrittura elevate. Quindi cerca di massimizzare le tue scritture per migliorare le prestazioni di lettura e la disponibilità dei dati. Esiste un compromesso tra la scrittura dei dati e la lettura dei dati. Quindi, ottimizza le prestazioni di lettura dei dati massimizzando il numero di scritture di dati.
- Massimizza la duplicazione dei dati
La denormalizzazione e la duplicazione dei dati sono di fatto di Cassandra. Lo spazio su disco non è più costoso della memoria, dell'elaborazione della CPU e del funzionamento degli I / O. Poiché Cassandra è un database distribuito, la duplicazione dei dati fornisce una disponibilità immediata dei dati e nessun singolo punto di errore.
Obiettivi di modellazione dei dati
Dovresti avere i seguenti obiettivi durante la modellazione dei dati in Cassandra.
- Distribuire i dati in modo uniforme nel cluster
Vuoi una quantità uguale di dati su ogni nodo del cluster Cassandra. I dati vengono distribuiti a diversi nodi in base alle chiavi di partizione che è la prima parte della chiave primaria. Quindi, prova a scegliere numeri interi come chiave primaria per distribuire i dati in modo uniforme nel cluster.
- Ridurre al minimo il numero di partizioni lette durante l'interrogazione dei dati
Le partizioni sono un gruppo di record con la stessa chiave di partizione. Quando viene eseguita la query di lettura, raccoglie i dati da diversi nodi da diverse partizioni.
Se sono presenti molte partizioni, è necessario visitare tutte queste partizioni per raccogliere i dati della query.
Ciò non significa che le partizioni non dovrebbero essere create. Se i tuoi dati sono molto grandi, non puoi mantenere quell'enorme quantità di dati sulla singola partizione. La singola partizione verrà rallentata.
Quindi prova a scegliere un numero equilibrato di partizioni.
Buona chiave primaria
Facciamo un esempio e troviamo quale chiave primaria è buona.
Ecco la tabella MusicPlaylist.
Create table MusicPlaylist(SongId int,SongName text,Year int,Singer text,Primary key(SongId, SongName));
Nell'esempio sopra, table MusicPlaylist,
- Songid è la chiave di partizione e
- SongName è la colonna di clustering
- I dati verranno raggruppati sulla base di SongName. Verrà creata solo una partizione con SongId. Non ci saranno altre partizioni nella tabella MusicPlaylist.
Il recupero dei dati sarà lento da questo modello di dati a causa della chiave primaria non valida.
Ecco un altro tavolo MusicPlaylist.
Create table MusicPlaylist(SongId int,SongName text,Year int,Singer text,Primary key((SongId, Year), SongName));
Nell'esempio sopra, table MusicPlaylist,
- Songid e Year sono la chiave di partizione e
- SongName è la colonna di clustering.
- I dati verranno raggruppati sulla base di SongName. In questa tabella, ogni anno, verrà creata una nuova partizione. Tutte le canzoni dell'anno saranno sullo stesso nodo. Questa chiave primaria sarà molto utile per i dati.
Il nostro recupero dei dati sarà veloce grazie a questo modello di dati.
Modella i tuoi dati in Cassandra
Le seguenti cose dovrebbero essere tenute a mente mentre modellate le vostre query.
- Determina quali query desideri supportare
- Si unisce
- Raggruppare per
- Filtrare su quale colonna ecc.
- Crea una tabella in base alle tue domande
Crea una tabella in base alle tue domande. Crea una tabella che soddisferà le tue domande. Prova a creare una tabella in modo tale che sia necessario leggere un numero minimo di partizioni.
Prima di tutto, determina quali query desideri.
Ad esempio, hai bisogno?
Gestione del rapporto uno a uno
Una relazione uno a uno significa che due tabelle hanno una corrispondenza uno a uno. Ad esempio, lo studente può registrare un solo corso e io voglio cercare uno studente in cui è registrato un determinato studente.
Quindi, in questo caso, lo schema della tabella dovrebbe comprendere tutti i dettagli dello studente in corrispondenza di quel particolare corso come il nome del corso, il numero di tiro dello studente, il nome dello studente, ecc.
Create table Student_Course(Student rollno int primary key,Student_name text,Course_name text,);
Gestire relazioni da uno a molti
Relazioni uno a molti significa avere una corrispondenza uno a molti tra due tabelle.
Ad esempio, un corso può essere studiato da molti studenti. Voglio cercare tutti gli studenti che stanno studiando un determinato corso.
Quindi, interrogando il nome del corso, avrò molti nomi di studenti che studieranno un corso particolare.
Create table Student_Course(Student_rollno int,Student_name text,Course_name text,);
Posso recuperare tutti gli studenti per un determinato corso tramite la seguente query.
Select * from Student_Course where Course_name='Course Name';
Gestione della relazione molti a molti
Relazioni molti a molti significa avere corrispondenza molti a molti tra due tabelle.
Ad esempio, un corso può essere studiato da molti studenti e uno studente può anche studiare molti corsi.
Voglio cercare tutti gli studenti che stanno studiando un determinato corso. Inoltre, voglio cercare in tutto il corso che sta studiando un particolare studente.
Quindi, in questo caso, avrò due tabelle, ovvero dividere il problema in due casi.
Per prima cosa creerò una tabella in cui puoi trovare i corsi di un determinato studente.
Create table Student_Course(Student_rollno int primary key,Student_name text,Course_name text,);
Posso trovare tutti i corsi di un determinato studente tramite la seguente query. ->
Select * from Student_Course where student_rollno=rollno;
In secondo luogo, creerò una tabella in base alla quale puoi trovare quanti studenti stanno studiando un determinato corso.
Create table Course_Student(Course_name text primary key,Student_name text,student_rollno int);
Posso trovare uno studente in un corso particolare tramite la seguente query.
Select * from Course_Student where Course_name=CourseName;
Differenza tra RDBMS e Cassandra Data Modeling
|
RDBMS |
Cassandra |
|
Memorizza i dati in forma normalizzata |
Memorizza i dati in forma denormalizzata |
|
Dbms legacy; dati strutturati |
Magazzino a file larghe, dinamico; dati strutturati e non strutturati |
Sommario
La modellazione dei dati in Cassandra è diversa dagli altri database RDBMS. La modellazione dei dati di Cassandra ha alcune regole. Queste regole devono essere seguite per una buona modellazione dei dati. Oltre a queste regole, abbiamo visto tre diversi casi di modellazione dei dati e come affrontarli.