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

Ajouter une réponse redux car la réponse acceptée est assez longue. Les Termes " row " et "column" sont utilisés dans le contexte de CQL, pas comment Cassandra est réellement implémenté.

• 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 les de la commande à l'intérieur d'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, le composite clé de cluster est (b, c).
• PRIMARY KEY ((a, b), c): Le composite clé de partition est (a, b), la clé de cluster est c.
• PRIMARY KEY ((a, b), c, d): la clé de partition composite est (a, b), le composite la clé de clustering est (c, d).

Dans cassandra , la différence entre la clé primaire, la clé de partition, la clé composite, la clé de clustering fait toujours une certaine confusion.. Donc, je vais expliquer ci-dessous et CO se rapportent 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 selon 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 les questions de clé primaire. 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 des 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éfinissez les colonnes qui forment la clé de partition.

Partitionnement et regroupement La définition de clé primaire se compose 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 des colonnes dans une rangée.

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 avoir plusieurs clés de cluster ainsi que la clé de partition qui dépend de la déclaration.

Clé Primaire: Est composé de la clé de partition(s) [et facultatif clés de clusters(ou des colonnes)]
Clé de Partition: La valeur de hachage de la clé de Partition est utilisée pour déterminer le nœud dans un cluster pour stocker les données
Clé de cluster: Est utilisé pour trier les données dans chacune des partitions(ou responsable nœud et répliques)

Compound Primary Key : comme indiqué ci-dessus, les clés de clustering sont facultatives dans une clé primaire. Si elles ne sont pas mentionnées, c'est un clé primaire simple. Si les clés de clustering sont mentionnées, c'est 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 ligne (dépend de la modélisation des cas d'Utilisation/données). Donc la clé de partition est parfois spécifié comme une combinaison de plus d'une colonne.

en ce qui concerne la confusion dont un est obligatoire, lequel peut être ignoré etc. dans une requête, en essayant de imaginez Cassandra comme un HashMap géant ça aide. 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é. Donc, chaque requête doit les avoir spécifiées. Sans lequel Cassandra ne saura pas quel nœud rechercher.
Les clés de clustering (colonnes, qui sont facultatives) aident à réduire davantage votre recherche de requête après que Cassandra ait découvert le nœud spécifique (et ses répliques) responsable de ce nœud spécifique clé de Partition.

En bref:

Clé de Partition n'est rien, mais identification pour une ligne, que l'identification, la plupart du temps est la seule colonne (appelée Clé Primaire) parfois, une combinaison de plusieurs colonnes (appelé Composite Clé de Partition).

La clé de Cluster n'est rien, mais Indexation & Tri. Les clés de Cluster dépendent de peu de choses:

1. Quelles colonnes vous utilisez dans la clause where sauf primaire colonnes de clé.

2. Si vous avez de très grands dossiers alors sur quelle préoccupation 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 cluster les données en fonction de l'état et après pincode et ainsi de suite.

À 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 qui ont 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 un clustering key est une date de jointure est que les résultats sont déjà triés (et stockés, ce qui rend les recherches rapides). Mais pourquoi utilisons-nous une clé composée pour clé de partitionnement ? Parce que nous voulons toujours lire le moins de partitions possible . Comment mettre join_date là-dedans aide? Maintenant, les utilisateurs du même groupe et la même date de jointure résideront dans une seule partition! Cela signifie que nous lirons toujours aussi peu de partitions que possible (commencez par le plus récent, puis passez à l'ancien et ainsi de suite sur, plutôt que de sauter entre eux).

En fait, dans les cas extrêmes, vous devrez également utiliser le hachage d'un join_date plutôt qu'un join_date seul - de sorte que si vous interrogez pour 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 base de données, une clé composée est un ensemble de superkeys qui n'est pas minimal.

Une clé composite est un ensemble qui contient un composé clé et au moins un attribut qui n'est pas un superkey

Table donnée: employés {employee_id, prénom, nom de famille}

Les superkeys possibles sont:

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

{employee_id} est la seule superkey minimale, ce qui en fait également la seule clé candidate-étant donné que {firstname} et {NAME} ne garantissent pas l'unicité. Depuis une clé primaire est défini comme une clé candidate choisie, et une seule clé candidate existe dans cet exemple, {employee_id} est la superkey minimale, la seule clé candidate et la seule clé primaire possible.

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

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

La seule clé composite est {employee_id, firstname, name} puisque cette clé contient une clé composée ({employee_id, firstname}) et un attribut qui n'est pas une superkey ({nom de famille}).