Cassandra Modèle de données avec exemple de base de données simple

Bien que Cassandra le langage de requête ressemble à SQL langage, leurs méthodes de modélisation des données sont totalement différentes.

In Cassandra, un mauvais modèle de données peut dégrader les performances, en particulier lorsque les utilisateurs tentent d'implémenter les concepts du SGBDR sur Cassandra. Il est préférable de garder à l’esprit quelques règles détaillées ci-dessous.

Cassandra Règles du modèle de données

In Cassandra, les écritures ne sont pas chères. Cassandra ne prend pas en charge les jointures, le groupe par, la clause OR, les agrégations, etc. Vous devez donc stocker vos données de manière à ce qu'elles soient entièrement récupérables. Ces règles doivent donc être gardées à l'esprit lors de la modélisation des données dans Cassandra.

Maximiser le nombre d'écritures

In Cassandra, les écritures sont très bon marché. Cassandra est optimisé pour des performances d'écriture élevées. Essayez donc de maximiser vos écritures pour de meilleures performances de lecture et une meilleure disponibilité des données. Il existe un compromis entre l'écriture de données et la lecture de données. Alors, optimisez vos performances de lecture de données en maximisant le nombre d’écritures de données.

Maximiser la duplication des données

La dénormalisation et la duplication des données sont de facto Cassandra. L'espace disque n'est pas plus cher que la mémoire, le traitement du processeur et le fonctionnement des E/S. Comme Cassandra est une base de données distribuée, la duplication des données offre donc une disponibilité instantanée des données et aucun point de défaillance unique.

Cassandra Objectifs de modélisation des données

Vous devez avoir les objectifs suivants lors de la modélisation des données dans Cassandra:

Répartir les données uniformément autour du Cluster

Vous voulez une quantité égale de données sur chaque nœud de Cassandra Cluster. Les données sont réparties sur différents nœuds en fonction des clés de partition qui constituent la première partie de la clé primaire. Essayez donc de choisir des nombres entiers comme clé primaire pour répartir les données uniformément dans le cluster.

Minimiser le nombre de partitions lues lors de l'interrogation des données

La partition est un groupe d'enregistrements avec la même clé de partition. Lorsque la requête de lecture est émise, elle collecte les données de différents nœuds de différentes partitions.

S'il y a plusieurs partitions, alors toutes ces partitions doivent être visitées pour collecter les données de requête.

Cela ne veut pas dire qu’il ne faut pas créer de partitions. Si vos données sont très volumineuses, vous ne pouvez pas conserver cette énorme quantité de données sur une seule partition. La partition unique sera ralentie.

Essayez donc de choisir un nombre équilibré de partitions.

Bonne clé primaire dans Cassandra

Prenons un exemple et trouvons quelle clé primaire est bonne.

Voici le tableau MusicPlaylist.

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

Dans l'exemple ci-dessus, la table MusicPlaylist,

• Songid est la clé de partition, et
• SongName est la colonne de clustering
• Les données seront regroupées sur la base de SongName. Une seule partition sera créée avec le SongId. Il n'y aura aucune autre partition dans la table MusicPlaylist.

La récupération des données sera lente avec ce modèle de données en raison d'une mauvaise clé primaire.

Voici un autre tableau MusicPlaylist.

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

Dans l'exemple ci-dessus, la table MusicPlaylist,

• Songid et Year sont la clé de partition, et
• SongName est la colonne de clustering.
• Les données seront regroupées sur la base de SongName. Dans ce tableau, chaque année, une nouvelle partition sera créée. Toutes les chansons de l'année seront sur le même nœud. Cette clé primaire sera très utile pour les données.

Notre récupération de données sera rapide grâce à ce modèle de données.

Modélisez vos données dans Cassandra

Les éléments suivants doivent être gardés à l’esprit lors de la modélisation de vos requêtes :

Déterminez les requêtes que vous souhaitez prendre en charge

Tout d’abord, déterminez les requêtes que vous souhaitez.

Par exemple, avez-vous besoin ?

• Joint
• Par groupe
• Filtrage sur quelle colonne etc.

Créez un tableau en fonction de vos requêtes

Créez un tableau en fonction de vos requêtes. Créez un tableau qui satisfera vos requêtes. Essayez de créer une table de telle sorte qu'un nombre minimum de partitions doive être lu.

Gérer une relation individuelle dans Cassandra

Une relation un à un signifie que deux tables ont une correspondance un à un. Par exemple, l'étudiant ne peut s'inscrire qu'à un seul cours et je souhaite rechercher sur un étudiant le cours auquel il est inscrit.

Ainsi, dans ce cas, votre schéma de table doit englober tous les détails de l'étudiant correspondant à ce cours particulier, comme le nom du cours, le numéro de rôle de l'étudiant, le nom de l'étudiant, etc.

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

Gérer les relations un à plusieurs dans Cassandra

Les relations un à plusieurs signifient avoir une correspondance un à plusieurs entre deux tables.

Par exemple, un cours peut être étudié par de nombreux étudiants. Je souhaite rechercher tous les étudiants qui étudient un cours particulier.

Ainsi, en interrogeant le nom du cours, j'aurai de nombreux noms d'étudiants qui étudieront un cours particulier.

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

Je peux récupérer tous les étudiants d'un cours particulier grâce à la requête suivante.

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

Gérer les relations plusieurs à plusieurs dans Cassandra

Les relations plusieurs à plusieurs signifient avoir une correspondance plusieurs à plusieurs entre deux tables.

Par exemple, un cours peut être étudié par de nombreux étudiants, et un étudiant peut également étudier plusieurs cours.

Je souhaite rechercher tous les étudiants qui étudient un cours particulier. De plus, je souhaite rechercher tous les cours qu'étudie un étudiant en particulier.

Donc dans ce cas, j'aurai deux tableaux, c'est à dire diviser le problème en deux cas.

Tout d’abord, je vais créer un tableau grâce auquel vous pourrez trouver les cours d’un étudiant en particulier.

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

Je peux trouver tous les cours d'un étudiant en particulier grâce à la requête suivante.

Select * from Student_Course where student_rollno=rollno;

Deuxièmement, je vais créer un tableau grâce auquel vous pourrez savoir combien d’étudiants étudient un cours particulier.

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

Je peux trouver un étudiant dans un cours particulier grâce à la requête suivante.

Select * from Course_Student where Course_name=CourseName;

Différence entre SGBDR et Cassandra Modélisation des données

RDBMS	Cassandra
Stocke les données sous forme normalisée	Stocke les données sous forme dénormalisée
SGBD hérités ; données structurées	Magasin à larges rangées, dynamique ; données structurées et non structurées

Résumé

• Modélisation des données dans Cassandra est différent des autres Bases de données SGBDR.
• Cassandra la modélisation des données a quelques règles. Ces règles doivent être respectées pour une bonne modélisation des données. Outre ces règles, nous avons vu trois cas différents de modélisation de données et comment les gérer.
• Une relation un à un signifie que deux tables ont une correspondance un à un.
• Les relations un à plusieurs signifient avoir une correspondance un à plusieurs entre deux tables.
• Les relations plusieurs à plusieurs signifient avoir une correspondance plusieurs à plusieurs entre deux tables.