Différence entre la clé de partition, la clé composite et la clé de clustering dans Cassandra?

J’ai lu des articles sur le net pour comprendre les différences entre les types de key suivants. Mais cela me semble difficile à comprendre. Les exemples aideront certainement à mieux comprendre.

 primary key, partition key, composite key clustering key 

Il y a beaucoup de confusion autour de cela, je vais essayer de le rendre aussi simple que possible.

La clé primaire est un concept général pour indiquer une ou plusieurs colonnes utilisées pour extraire des données d’une table.

La clé primaire peut être SIMPLE et même déclarée en ligne:

  create table stackoverflow_simple ( key text PRIMARY KEY, data text ); 

Cela signifie qu’il est fait par une seule colonne.

Mais la clé primaire peut également être COMPOSITE (aka COMPOUND ), générée à partir de plusieurs colonnes.

  create table stackoverflow_composite ( key_part_one text, key_part_two int, data text, PRIMARY KEY(key_part_one, key_part_two) ); 

Dans une situation de clé primaire COMPOSITE , la “première partie” de la clé est appelée PARTITION KEY (dans cet exemple, key_part_one est la clé de partition) et la deuxième partie de la clé est CLUSTERING KEY (dans cet exemple key_part_two )

Veuillez noter que la clé de partition et la clé de cluster peuvent être créées par plusieurs colonnes . Voici comment:

  create table stackoverflow_multiple ( k_part_one text, k_part_two int, k_clust_one text, k_clust_two int, k_clust_three uuid, data text, PRIMARY KEY((k_part_one, k_part_two), k_clust_one, k_clust_two, k_clust_three) ); 

Derrière ces noms …

  • La clé de partition est responsable de la dissortingbution des données entre vos nœuds.
  • La clé de cluster est responsable du sorting des données dans la partition.
  • La clé primaire est équivalente à la clé de partition dans une table de clé à champ unique (c.-à-d. Simple ).
  • La Composite / Compound Key est une clé à plusieurs colonnes

Informations supplémentaires sur l’utilisation: DOCUMENTATION DATASTAX


Petits exemples d’utilisation et de contenu
Clé simple:

 insert into stackoverflow_simple (key, data) VALUES ('han', 'solo'); select * from stackoverflow_simple where key='han'; 

contenu de la table

 key | data ----+------ han | solo 

COMPOSITE / COMPOUND KEY peut récupérer des “lignes larges” (c’est-à-dire que vous pouvez interroger uniquement la clé de partition, même si vous avez défini des clés de cluster)

 insert into stackoverflow_composite (key_part_one, key_part_two, data) VALUES ('ronaldo', 9, 'football player'); insert into stackoverflow_composite (key_part_one, key_part_two, data) VALUES ('ronaldo', 10, 'ex-football player'); select * from stackoverflow_composite where key_part_one = 'ronaldo'; 

contenu de la table

  key_part_one | key_part_two | data --------------+--------------+-------------------- ronaldo | 9 | football player ronaldo | 10 | ex-football player 

Mais vous pouvez interroger avec toutes les clés (partition et clustering) …

 select * from stackoverflow_composite where key_part_one = 'ronaldo' and key_part_two = 10; 

sortie de requête

  key_part_one | key_part_two | data --------------+--------------+-------------------- ronaldo | 10 | ex-football player 

Remarque importante: la clé de partition est le spécificateur minimum requirejs pour effectuer une requête en utilisant une where clause . Si vous avez une clé de partition composite, comme ci-dessous

ex: PRIMARY KEY((col1, col2), col10, col4))

Vous pouvez effectuer une requête uniquement en transmettant au moins les deux colonnes col1 et col2. Ce sont les deux colonnes qui définissent la clé de partition. La règle “générale” pour faire la requête est que vous devez transmettre au moins toutes les colonnes de clé de partition, vous pouvez alors append éventuellement chaque clé de cluster dans l’ordre où elles sont définies.

donc les requêtes valides sont (à l’ exclusion des index secondaires )

  • col1 et col2
  • col1 et col2 et col10
  • col1 et col2 et col10 et col 4

Invalide:

  • col1 et col2 et col4
  • tout ce qui ne contient pas à la fois col1 et col2

J’espère que cela t’aides.

Ajouter une réponse redux comme étant accepté est assez long. Les termes “row” et “column” sont utilisés dans le contexte de CQL, pas comment Cassandra est réellement implémenté.

  • Une clé primaire identifie de manière unique une ligne.
  • Une clé composite est une clé formée de plusieurs colonnes.
  • Une clé de partition est la référence principale pour rechercher un ensemble de lignes, c’est-à-dire une partition.
  • Une clé de cluster est la partie de la clé primaire qui n’est pas la clé de partition (et définit le classement dans une partition).

Exemples:

  • PRIMARY KEY (a) : la clé de partition est a .
  • PRIMARY KEY (a, b) : la clé de partition est a , la clé de cluster est b .
  • PRIMARY KEY ((a, b)) : La clé de partition composite est (a, b) .
  • PRIMARY KEY (a, b, c) : la clé de partition est a , la clé de clustering composite est (b, c) .
  • PRIMARY KEY ((a, b), c) : La clé de partition composite est (a, b) , la clé de regroupement est c .
  • PRIMARY KEY ((a, b), c, d) : La clé de partition composite est (a, b) , la clé de regroupement composite est (c, d) .

Dans cassandra, la différence entre la clé primaire, la clé de partition, la clé composite et la clé de regroupement crée toujours une certaine confusion. Je vais donc vous expliquer ci-dessous et vous relier. Nous utilisons CQL (Cassandra Query Language) pour l’access à la firebase database Cassandra. Remarque: – La réponse est conforme à la version mise à jour de Cassandra. Clé primaire :-

En cassandra il y a 2 manières différentes d’utiliser la clé primaire.

 CREATE TABLE Cass ( id int PRIMARY KEY, name text ); 

 Create Table Cass ( id int, name text, PRIMARY KEY(id) ); 

Dans CQL, l’ordre dans lequel les colonnes sont définies pour le PRIMARY KEY est important. La première colonne de la clé s’appelle la clé de partition ayant la propriété que toutes les lignes partageant la même clé de partition (même entre les tables) sont stockées sur le même nœud physique. En outre, l’insertion / mise à jour / suppression sur les lignes partageant la même clé de partition pour une table donnée est effectuée de manière atomique et isolée. Notez qu’il est possible d’avoir une clé de partition composite, c’est-à-dire une clé de partition formée de plusieurs colonnes, en utilisant un ensemble supplémentaire de parenthèses pour définir les colonnes qui constituent la clé de partition.

Partitionnement et clustering La définition PRIMARY KEY est composée de deux parties: la clé de partition et les colonnes de regroupement. La première partie correspond à la clé de ligne du moteur de stockage, tandis que la seconde est utilisée pour regrouper les colonnes d’une ligne.

 CREATE TABLE device_check ( device_id int, checked_at timestamp, is_power boolean, is_locked boolean, PRIMARY KEY (device_id, checked_at) ); 

Ici, device_id est la clé de partition et checked_at est la clé de cluster.

Nous pouvons avoir plusieurs clés de cluster ainsi qu’une clé de partition qui dépend de la déclaration.

Clé primaire : est composée de clé (s) de partition [et de clés (ou colonnes) de regroupement facultatives]
Clé de partition : la valeur de hachage de la clé de partition est utilisée pour déterminer le noeud spécifique dans un cluster pour stocker les données.
Clustering Key : Utilisé pour sortinger les données dans chacune des partitions (ou noeud responsable et ses répliques)

Clé primaire composée : Comme indiqué ci-dessus, les clés de regroupement sont facultatives dans une clé primaire. S’ils ne sont pas mentionnés, c’est une clé primaire simple. Si des clés de cluster sont mentionnées, il s’agit d’une clé primaire composée.

Clé de partition composite : L’utilisation d’une seule colonne comme clé de partition peut entraîner des problèmes de lignes étendues (en fonction de la modélisation du cas d’utilisation / des données). Par conséquent, la clé de partition est parfois spécifiée comme une combinaison de plusieurs colonnes.

En ce qui concerne la confusion de savoir lequel est obligatoire , lequel peut être ignoré, etc. dans une requête, essayer d’ imaginer Cassandra comme un HashMap géant peut aider. Donc, dans un HashMap, vous ne pouvez pas récupérer les valeurs sans la clé.
Ici, les clés de partition jouent le rôle de cette clé. Chaque requête doit donc être spécifiée. Sans lequel Cassandra ne saura pas quel noeud rechercher.
Les clés de regroupement (colonnes, facultatives) aident à réduire davantage la recherche de requêtes après que Cassandra ait découvert le nœud spécifique (et ses répliques) responsables de cette clé de partition spécifique.

En bref:

La clé de partition n’est rien d’autre qu’une identification pour une ligne, cette identification est la plupart du temps la colonne unique (appelée clé primaire ), parfois une combinaison de plusieurs colonnes (appelée clé de partition composite ).

Clé de cluster n’est rien d’autre que l’ indexation et le sorting . Les clés de cluster dépendent de peu de choses:

  1. Quelles colonnes utilisez-vous dans la clause where, à l’exception des colonnes de clé primaire.

  2. Si vous avez des dossiers très volumineux, alors sur quelle préoccupation je peux diviser la date pour faciliter la gestion. Exemple, j’ai des données de 1 million de dossiers de population d’un comté. Donc, pour faciliter la gestion, je regroupe les données en fonction de l’état et du code PIN, etc.

À noter, vous utiliserez probablement ces lots plus que dans des concepts similaires dans le monde relationnel (clés composites).

Exemple – supposons que vous deviez trouver les N derniers utilisateurs ayant récemment rejoint le groupe d’utilisateurs X. Comment feriez-vous cela efficacement étant donné que les lectures prédominent dans ce cas? Comme ça (du guide officiel Cassandra ):

 CREATE TABLE group_join_dates ( groupname text, joined timeuuid, join_date text, username text, email text, age int, PRIMARY KEY ((groupname, join_date), joined) ) WITH CLUSTERING ORDER BY (joined DESC) 

Ici, la clé de partitionnement est elle-même composée et la clé de clustering est une date jointe. La raison pour laquelle une clé de cluster est une date de jointure est que les résultats sont déjà sortingés (et stockés, ce qui accélère les recherches). Mais pourquoi utilisons-nous une clé composée pour la clé de partitionnement ? Parce que nous voulons toujours lire le moins de partitions possible . Comment mettre join_date là-dedans aide? Les utilisateurs du même groupe et de la même date de jointure résident désormais dans une seule partition! Cela signifie que nous lirons toujours aussi peu de partitions que possible (commencez par le plus récent, puis déplacez-vous vers l’ancien et ainsi de suite, plutôt que de sauter entre elles).

En fait, dans les cas extrêmes, vous devez également utiliser le hachage d’une join_date plutôt que d’une join_date – de sorte que si vous interrogez les 3 derniers jours, ceux-ci partagent souvent le même hachage et sont donc disponibles à partir de la même partition!

Dans la conception de la firebase database, une clé composée est un ensemble de super-clés qui n’est pas minimal.

Une clé composite est un ensemble qui contient une clé composée et au moins un atsortingbut qui n’est pas une super-clé

Table donnée: EMPLOYEES {employee_id, firstname, surname}

Les superkeys possibles sont:

 {employee_id} {employee_id, firstname} {employee_id, firstname, surname} 

{employé_id} est la seule super-clé minimale, ce qui en fait la seule clé candidate – étant donné que {prénom} et {nom} ne garantissent pas l’unicité. Etant donné qu’une clé primaire est définie comme clé candidate choisie et qu’une seule clé candidate existe dans cet exemple, {employé_id} est la super-clé minimale, la seule clé candidate et la seule clé primaire possible.

La liste exhaustive des clés composées est la suivante:

 {employee_id, firstname} {employee_id, surname} {employee_id, firstname, surname} 

La seule clé composite est {employee_id, firstname, surname} car cette clé contient une clé composée ({employee_id, firstname}) et un atsortingbut qui n’est pas une super-clé ({nom}).