Bien que le langage de requête Cassandra ressemble au langage SQL, leurs méthodes de modélisation de données sont totalement différentes.
Dans Cassandra, un mauvais modèle de données peut dégrader les performances, en particulier lorsque les utilisateurs tentent d'implémenter les concepts SGBDR sur Cassandra. Il est préférable de garder à l'esprit quelques règles détaillées ci-dessous.
Dans ce didacticiel, vous apprendrez-
- Règles du modèle de données Cassandra
- Modélisez vos données dans Cassandra
- Gérer une relation un à un
- Gérer une à plusieurs relations
- Gérer les relations plusieurs à plusieurs
Règles du modèle de données Cassandra
À Cassandra, les écritures ne coûtent pas cher. Cassandra ne prend pas en charge les jointures, group by, clause OR, agrégations, etc. Vous devez donc stocker vos données de manière à ce qu'elles soient complètement récupérables. Donc, ces règles doivent être gardées à l'esprit lors de la modélisation des données dans Cassandra.
- Maximisez le nombre d'écritures
À 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 et la lecture des données. Ainsi, 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 de 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 une disponibilité instantanée des données et aucun point de défaillance unique.
Objectifs de la modélisation des données
Vous devriez avoir les objectifs suivants lors de la modélisation des données dans Cassandra.
- Répartir les données uniformément dans le cluster
Vous voulez une quantité égale de données sur chaque nœud du cluster Cassandra. 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. Alors, essayez de choisir des entiers comme clé primaire pour répartir uniformément les données autour du 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 à partir de différentes partitions.
S'il y a de nombreuses partitions, toutes ces partitions doivent être visitées pour collecter les données de la requête.
Cela ne signifie pas que les partitions ne doivent pas être créées. 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
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, 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 par ce modèle de données en raison de la mauvaise clé primaire.
Voici une autre table MusicPlaylist.
Create table MusicPlaylist(SongId int,SongName text,Year int,Singer text,Primary key((SongId, Year), SongName));
Dans l'exemple ci-dessus, 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
- Rejoint
- Par groupe
- Filtrage sur quelle colonne etc.
- Créer un tableau en fonction de vos requêtes
Créez un tableau en fonction de vos requêtes. Créez une table qui satisfera vos requêtes. Essayez de créer une table de telle sorte qu'un nombre minimum de partitions doit être lu.
Tout d'abord, déterminez les requêtes que vous souhaitez.
Par exemple, avez-vous besoin?
Gérer une relation un à un
Une relation un à un signifie que deux tables ont une correspondance une à une. Par exemple, l'étudiant ne peut s'inscrire qu'à un seul cours et je souhaite rechercher sur un élève le cours auquel un étudiant en particulier est inscrit.
Donc, 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 rouleau 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 une à plusieurs relations
Une à plusieurs relations signifie avoir une à plusieurs correspondance entre deux tables.
Par exemple, un cours peut être étudié par de nombreux étudiants. Je veux 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 par la requête suivante.
Select * from Student_Course where Course_name='Course Name';
Gérer les relations plusieurs à plusieurs
Des relations plusieurs à plusieurs signifient avoir plusieurs à plusieurs correspondances entre deux tables.
Par exemple, un cours peut être étudié par de nombreux étudiants, et un étudiant peut également étudier de nombreux cours.
Je veux rechercher tous les étudiants qui étudient un cours particulier. Aussi, je veux rechercher tous les cours qu'un étudiant particulier étudie.
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 dans lequel vous pouvez 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 par la requête suivante. ->
Select * from Student_Course where student_rollno=rollno;
Deuxièmement, je vais créer un tableau dans lequel vous pouvez trouver 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 par la requête suivante.
Select * from Course_Student where Course_name=CourseName;
Différence entre le SGBDR et la modélisation de données Cassandra
|
SGBDR |
Cassandra |
|
Stocke les données sous forme normalisée |
Stocke les données sous forme dénormalisée |
|
Dbms hérités; données structurées |
Magasin de rangées large, dynamique; données structurées et non structurées |
Résumé
La modélisation des données dans Cassandra est différente des autres bases de données SGBDR. La modélisation des données Cassandra a quelques règles. Ces règles doivent être suivies pour une bonne modélisation des données. Outre ces règles, nous avons vu trois cas de modélisation de données différents et comment les gérer.