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 keytypes suivants . Mais cela me semble difficile à saisir. Les exemples aideront certainement à mieux comprendre.

primary key,
partition key, 
composite key 
clustering key

Il y a beaucoup de confusion à ce sujet, 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 récupérer 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 constitué d'une seule colonne.

Mais la clé primaire peut également être COMPOSITE (alias 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 CLÉ DE PARTITION (dans cet exemple, key_part_one est la clé de partition) et la deuxième partie de la clé est la CLUSTERING KEY (dans cet exemple, key_part_two )

Veuillez noter que la clé de partition et de cluster peut être créée 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 distribution des données sur vos nœuds.
• La Clustering Key est responsable du tri des données dans la partition.
• La clé primaire est équivalente à la clé de partition dans une table de clé à champ unique (c'est-à-dire simple ).
• La clé composite / composée est n'importe quelle clé à plusieurs colonnes

Autres informations d'utilisation: DOCUMENTATION DE DONNÉES

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 requis pour effectuer une requête à l'aide de a where clause. Si vous avez une clé de partition composite, comme la suivante

par exemple: PRIMARY KEY((col1, col2), col10, col4))

Vous pouvez effectuer une requête uniquement en passant au moins col1 et col2, ce sont les 2 colonnes qui définissent la clé de partition. La règle "générale" pour effectuer une requête est que vous devez passer au moins toutes les colonnes de clés de partition, puis vous pouvez éventuellement ajouter chaque clé de clustering dans l'ordre de leur définition.

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.

L'ajout d'une réponse sommaire comme acceptée est assez long. Les termes «ligne» et «colonne» sont utilisés dans le contexte de CQL, et non de la manière dont Cassandra est réellement implémentée.

• 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 recherche principale pour trouver un ensemble de lignes, c'est-à-dire une partition.
• Une clé de clustering est la partie de la clé primaire qui n'est pas la clé de partition (et définit l'ordre 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 clustering 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 clustering est c.
• PRIMARY KEY ((a, b), c, d): La clé de partition composite est (a, b), la clé de cluster composite est (c, d).

Dans cassandra, la différence entre la clé primaire, la clé de partition, la clé composite, la clé de clustering crée toujours une certaine confusion. Je vais donc expliquer ci-dessous et me relier les uns aux autres. Nous utilisons CQL (Cassandra Query Language) pour l'accès à la base de données Cassandra. Remarque: - La réponse est conforme à la version mise à jour de Cassandra. Clé primaire :-

Dans cassandra, il existe 2 façons 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 la CLÉ PRIMAIRE est important. La première colonne de la clé est appelée la clé de partition ayant la propriété que toutes les lignes partageant la même clé de partition (même à travers la table en fait) sont stockées sur le même nœud physique. De plus, 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 jeu de parenthèses supplémentaire pour définir quelles colonnes forment la clé de partition.

Partitionnement et clustering La définition de PRIMARY KEY est composée de deux parties: la clé de partition et les colonnes de clustering. La première partie correspond à la clé de ligne du moteur de stockage, tandis que la seconde est utilisée pour regrouper les colonnes dans 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 cluster_key.

Nous pouvons également avoir plusieurs clés de cluster ainsi que des clés de partition qui dépendent de la déclaration.

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

Clé primaire composée : Comme indiqué ci-dessus, les clés de clustering sont facultatives dans une clé primaire. S'ils ne sont pas mentionnés, il s'agit d'une simple clé primaire. Si des clés de clustering 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 larges (en fonction du cas d'utilisation / de la modélisation 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, laquelle est obligatoire , laquelle peut être ignorée, etc. dans une requête, essayer d' imaginer Cassandra comme un géant HashMap aide. Ainsi, 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é. Ainsi, chaque requête doit les avoir spécifiées. Sans quoi Cassandra ne saura pas quel nœud rechercher.
Les clés de clustering (colonnes, facultatives) aident à affiner davantage votre recherche de requête après que Cassandra a découvert le nœud spécifique (et ses répliques) responsable de cette clé de partition spécifique.

En bref:

La clé de partition n'est rien d'autre que l' identification d'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 ).

La clé de cluster n'est rien d'autre que l' indexation et le tri . Les clés de cluster dépendent de quelques éléments:

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

2. Si vous avez des dossiers très volumineux, je peux diviser la date pour une gestion facile. Exemple, j'ai des données de 1 million d'enregistrements de population de comté. Donc, pour une gestion facile, je regroupe les données en fonction de l'état et du code PIN, etc.

Il convient de noter que 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 qui ont récemment rejoint le groupe d'utilisateurs X. Comment feriez-vous cela efficacement étant donné que les lectures sont prédominantes dans ce cas? Comme ça (du guide officiel de 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 composée elle-même et la clé de clustering est une date jointe. La raison pour laquelle une clé de clustering est une date de jointure est que les résultats sont déjà triés (et stockés, ce qui accélère les recherches). Mais pourquoi utilisons-nous une clé composée pour partitionner la clé ? Parce que nous voulons toujours lire le moins de partitions possible . Comment mettre join_date là-dedans aide? Désormais, les utilisateurs du même groupe et de la même date de jointure résideront dans une seule partition! Cela signifie que nous lirons toujours le moins de partitions possible (commencez d'abord par la plus récente, puis passez à l'ancienne et ainsi de suite, plutôt que de sauter entre elles).

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

La clé primaire de Cassandra se compose généralement de deux parties: la clé de partition et les colonnes de clustering.

primary_key ((partition_key), clustering_col)

Clé de partition - La première partie de la clé primaire. Le but principal d'une clé de partition est d'identifier le nœud qui stocke la ligne particulière.

CREATE TABLE phone_book (phone_num int, nom du texte, age int, texte de la ville, PRIMARY KEY ((phone_num, nom), age);

Ici, (numéro_téléphone, nom) est la clé de partition. Lors de l'insertion des données, la valeur de hachage de la clé de partition est générée et cette valeur décide dans quel nœud la ligne doit entrer.

Considérons un cluster à 4 nœuds, chaque nœud a une plage de valeurs de hachage qu'il peut stocker. (Écrire) INSÉRER DANS LES VALEURS de l'annuaire (7826573732, «Joey», 25, «New York»);

Maintenant, la valeur de hachage de la clé de partition est calculée par le partitionneur Cassandra. disons, valeur de hachage (7826573732, 'Joey') → 12, maintenant, cette ligne sera insérée dans le noeud C.

(Lire) SELECT * FROM phone_book WHERE phone_num = 7826573732 et name = 'Joey';

Maintenant, encore une fois la valeur de hachage de la clé de partition (7826573732, 'Joey') est calculée, qui est 12 dans notre cas qui réside dans le nœud C, à partir duquel la lecture est effectuée.

2. Colonnes de clustering - Deuxième partie de la clé primaire. Le but principal d'avoir des colonnes de clustering est de stocker les données dans un ordre trié. Par défaut, l'ordre est croissant.

Il peut y avoir plusieurs clés de partition et colonnes de clustering dans une clé primaire selon la requête que vous résolvez.

clé_principale ((pk1, pk2), col 1, col2)

Dans la conception d'une base de données, 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 attribut qui n'est pas une super-clé

Tableau donné: EMPLOYÉS {id_employé, prénom, nom}

Les super-clés possibles sont:

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

{employee_id} est la seule super-clé minimale, ce qui en fait également la seule clé candidate - étant donné que {prénom} et {nom} ne garantissent pas l'unicité. Puisqu'une clé primaire est définie comme une clé candidate choisie et qu'une seule clé candidate existe dans cet exemple, {employee_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 {employé_id, prénom, nom} car cette clé contient une clé composée ({employé_id, prénom}) et un attribut qui n'est pas une super-clé ({nom}).