web-dev-qa-db-fra.com

cassandra la colonne de clé primaire ne peut pas être restreinte

J'utilise Cassandra pour la première fois dans une application web et j'ai un problème de requête. Voici mon onglet:

CREATE TABLE vote (
    doodle_id uuid,
    user_id uuid,
    schedule_id uuid,
    vote int,
    PRIMARY KEY ((doodle_id), user_id, schedule_id)
);

À chaque demande, j'indique ma clé de partition, doodle_id. Par exemple je peux faire sans aucun problème:

select * from vote where doodle_id = c4778a27-f2ca-4c96-8669-15dcbd5d34a7 and user_id = 97a7378a-e1bb-4586-ada1-177016405142;

Mais à la dernière demande que j'ai faite:

select * from vote where doodle_id = c4778a27-f2ca-4c96-8669-15dcbd5d34a7 and schedule_id = c37df0ad-f61d-463e-bdcc-a97586bea633;

J'ai eu l'erreur suivante:

Bad Request: PRIMARY KEY column "schedule_id" cannot be restricted (preceding column "user_id" is either not restricted or by a non-EQ relation)

Je suis nouveau avec Cassandra, mais corrigez-moi si je me trompe, dans une clé primaire composite, la première partie est la CLÉ DE PARTITION qui est obligatoire pour permettre Cassandra de savoir où chercher Ensuite, les autres parties sont CLUSTERING KEY pour trier les données.

Mais je ne comprends toujours pas pourquoi ma première demande fonctionne et pas la deuxième?

Si quelqu'un pouvait aider, ce serait un grand plaisir.

cassandracqlcqlsh
18
Orodan

Dans Cassandra, vous devez concevoir votre modèle de données en fonction de vos requêtes. Par conséquent, la bonne façon de prendre en charge votre deuxième requête (requêtes par doodle_id et schedule_id, mais pas nécessairement avec user_id), consiste à créer une nouvelle table pour gérer cette requête spécifique. Ce tableau sera à peu près le même, sauf que la CLÉ PRIMAIRE sera légèrement différente:

CREATE TABLE votebydoodleandschedule (
    doodle_id uuid,
    user_id uuid,
    schedule_id uuid,
    vote int,
    PRIMARY KEY ((doodle_id), schedule_id, user_id)
);

Maintenant, cette requête fonctionnera:

SELECT * FROM votebydoodleandschedule 
WHERE doodle_id = c4778a27-f2ca-4c96-8669-15dcbd5d34a7 
AND schedule_id = c37df0ad-f61d-463e-bdcc-a97586bea633;

Cela vous oblige à spécifier ALLOW FILTERING. Reposant sur ALLOW FILTERING n'est jamais une bonne idée et n'est certainement pas quelque chose que vous devriez faire dans un cluster de production.

12
Aaron

La clé de clustering est également utilisée pour rechercher les colonnes d'une partition donnée. Avec votre modèle, vous pourrez interroger par:

  • doodle_id
  • doodle_id/user_id
  • doodle_id/user_id/schedule_id
  • user_id utilisant ALLOW FILTERING
  • user_id/schedule_id utilisant ALLOW FILTERING

Vous pouvez voir votre clé primaire comme un chemin de fichier doodle_id # 123/user_id # 456/schedule_id # 789 où toutes les données sont stockées dans le dossier le plus profond (c.-à-d. Schedule_id # 789). Lorsque vous interrogez, vous devez indiquer le sous-dossier/sous-arbre d'où vous commencez la recherche.

Votre deuxième requête ne fonctionne pas en raison de l'organisation des colonnes dans la partition. Cassandra ne peut pas obtenir un tranche continu de colonnes dans la partition car elles sont entrelacées.

Vous devez inverser l'ordre des clés primaires (doodle_id, schedule_id, user_id) pour pouvoir exécuter votre requête.

3
G Quintana