Cassandra Modello di dati con esempio di database semplice

Sebbene il Cassandra il linguaggio di query assomiglia a SQL linguaggio, i loro metodi di modellazione dei dati sono totalmente diversi.

In Cassandra, un modello dati errato 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.

Cassandra Regole del modello di dati

In Cassandra, le scritture non sono costose. Cassandra non supporta join, raggruppamenti per, clausole OR, aggregazioni, ecc. Quindi devi archiviare i tuoi dati in modo tale che siano completamente recuperabili. Pertanto è necessario tenere presenti queste regole durante la modellazione dei dati Cassandra.

Massimizza il numero di scritture

In Cassandra, le scritture sono molto economiche. Cassandra è ottimizzato per prestazioni di scrittura elevate. Quindi prova a massimizzare le tue scritture per migliorare le prestazioni di lettura e la disponibilità dei dati. Esiste un compromesso tra scrittura e lettura dei dati. Pertanto, 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 Cassandra. Lo spazio su disco non è più costoso della memoria, dell'elaborazione della CPU e del funzionamento degli I/O. COME Cassandra è un database distribuito, quindi la duplicazione dei dati fornisce disponibilità immediata dei dati e nessun singolo punto di errore.

Cassandra Obiettivi della modellazione dei dati

Dovresti avere i seguenti obiettivi durante la modellazione dei dati in Cassandra:

Diffondere i dati in modo uniforme intorno al Cluster

Desideri una quantità uguale di dati su ciascun nodo di Cassandra Cluster. I dati vengono distribuiti su diversi nodi in base alle chiavi di partizione che rappresentano la prima parte della chiave primaria. Quindi, prova a scegliere i numeri interi come chiave primaria per distribuire i dati in modo uniforme nel cluster.

Ridurre al minimo il numero di partizioni lette durante l'esecuzione di query sui dati

La partizione è un gruppo di record con la stessa chiave di partizione. Quando viene emessa la query di lettura, raccoglie dati da diversi nodi da diverse partizioni.

Se saranno presenti molte partizioni, sarà necessario visitarle tutte per raccogliere i dati della query.

Ciò non significa che non si debbano creare partizioni. Se i tuoi dati sono molto grandi, non puoi conservare un'enorme quantità di dati su un'unica partizione. La singola partizione verrà rallentata.

Quindi prova a scegliere un numero equilibrato di partizioni.

Buona chiave primaria Cassandra

Facciamo un esempio e scopriamo 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, tabella MusicPlaylist,

• Songid è la chiave di partizione e
• SongName è la colonna di clustering
• I dati verranno raggruppati in base a SongName. Verrà creata solo una partizione con SongId. Non ci sarà nessun'altra partizione nella tabella MusicPlaylist.

Il recupero dei dati sarà lento da parte di questo modello dati a causa della chiave primaria errata.

Ecco un'altra tabella MusicPlaylist.

Create table MusicPlaylist
    (
        SongId int,
        SongName text,
        Year int,
        Singer text,
        Primary key((SongId, Year), SongName)
    );

Nell'esempio sopra, tabella MusicPlaylist,

• Songid e Year sono la chiave di partizione e
• SongName è la colonna di clustering.
• I dati verranno raggruppati in base a 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à rapido grazie a questo modello di dati.

Modella i tuoi dati in Cassandra

Quando si modellano le query, è opportuno tenere a mente i seguenti aspetti:

Determina quali query vuoi supportare

Prima di tutto, determina quali query desideri.

Ad esempio, hai bisogno?

• Entra a far parte
• Raggruppa per
• Filtraggio su quale colonna, ecc.

Crea una tabella in base alle tue domande

Crea una tabella in base alle tue domande. Crea una tabella che soddisfi le tue domande. Prova a creare una tabella in modo tale da dover leggere un numero minimo di partizioni.

Gestire la relazione uno a uno in Cassandra

La relazione uno a uno significa che due tabelle hanno una corrispondenza uno a uno. Ad esempio, lo studente può iscriversi a un solo corso e io voglio cercare su uno studente a quale corso è iscritto un determinato studente.

In questo caso, lo schema della tabella dovrebbe comprendere tutti i dettagli dello studente corrispondenti a quel particolare corso, come il nome del corso, il numero di matricola dello studente, il nome dello studente, ecc.

Create table Student_Course
    (
        Student rollno int primary key,
        Student_name text,
        Course_name text,
    );

Gestire la relazione uno a molti in Cassandra

Relazioni uno a molti significa avere corrispondenza uno a molti tra due tabelle.

Ad esempio, un corso può essere seguito da molti studenti. Voglio cercare tutti gli studenti che stanno studiando un corso particolare.

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 di un corso specifico tramite la seguente query.

Select * from Student_Course where Course_name='Course Name';

Gestire la relazione molti a molti in Cassandra

Relazioni molti a molti significa avere una 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 corso particolare. Inoltre, voglio cercare tutto il corso che sta studiando un determinato studente.

Quindi in questo caso avrò due tabelle, ovvero dividerò il problema in due casi.

Per prima cosa creerò una tabella in cui potrai trovare i corsi di un particolare studente.

Create table Student_Course
    (
        Student_rollno int primary key,
        Student_name text,
        Course_name text,
    );

Posso trovare tutti i corsi tenuti da uno studente specifico tramite la seguente query.

Select * from Student_Course where student_rollno=rollno;

In secondo luogo, creerò una tabella in base alla quale potrai scoprire quanti studenti stanno studiando un particolare corso.

Create table Course_Student
    (
        Course_name text primary key,
        Student_name text,
        student_rollno int
    );

Posso trovare uno studente in un corso specifico tramite la seguente query.

Select * from Course_Student where Course_name=CourseName;

Differenza tra RDBMS e Cassandra Modellazione dei dati

RDBMS	Cassandra
Memorizza i dati in forma normalizzata	Memorizza i dati in forma denormalizzata
DBm legacy; dati strutturati	Negozio ad ampia fila, dinamico; dati strutturati e non strutturati

Sommario

• Modellazione dei dati in Cassandra è diverso dagli altri Banche dati RDBMS.
• Cassandra la modellazione dei dati 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 gestirli.
• La relazione uno a uno significa che due tabelle hanno una corrispondenza uno a uno.
• Relazioni uno a molti significa avere corrispondenza uno a molti tra due tabelle.
• Relazioni molti a molti significa avere una corrispondenza molti a molti tra due tabelle.