schéma de base de données Cassandra et sélectionnez dans le numéro

Question

Je suit le schéma de base de données

CREATE TABLE sensor_info_table 
(
    asset_id text, 
    event_time timestamp, 
    "timestamp" timeuuid, 
    sensor_reading map<text, text>, 
    sensor_serial_number text, 
    sensor_type int, 
    PRIMARY KEY ((asset_id), event_time, "timestamp") 
); 

CREATE INDEX event_time_index ON sensor_info_table (event_time); 

CREATE INDEX timestamp_index ON sensor_info_table ("timestamp"); 

Maintenant, je suis en mesure d'insérer les données dans ce tableau, je suis cependant incapable de faire la requête suivante où je veux sélectionner des éléments avec timeuuid spécifiques valeurs. Cela me donne l'erreur suivante.

SELECT * from mydb.sensor_info_table where timestamp IN (bfdfa614-3166-11e4-a61d-b888e30f5d17 , bf4521ac-3166-11e4-87a3-b888e30f5d17) ; 

Bad Request: colonne de clé primaire "horodatage" ne peut pas être limité (colonne précédente "event_time" est soit pas restreinte ou par une relation non-EQ)

Que dois-je faire pour que cela fonctionne? Voici les informations sur la version du logiciel.

voir VERSION;

[cqlsh 4.1.1 | Cassandra 2.0.9 | CQL spec 3.1.1 | Thrift protocol 19.39.0] 

Je ne comprends vraiment pas ce que le message d'erreur précédent colonne « event_time » est soit pas limité ou non-EQ relation?

-Subodh

Answer 1

Vous ne pouvez pas le faire fonctionner comme ça. IN Le prédicat sur les colonnes indexées de recherche n'est pas pris en charge. Vous ne pourrez donc pas utiliser IN dans la colonne "horodatage". Vous pouvez utiliser IN si vous fournissez aussi à la fois asset_id et event_time - c'est ce que cqlsh vous dit avec le message

Bad Request: « timestamp » colonne de clé primaire ne peut pas être limitée (colonne précédente « event_time » est soit pas de restriction ou par une relation non-EQ )

La solution à votre problème est la dénormalisation. Qu'est-ce qui se passe sous le capot lors de la création d'un index est que Cassandra va créer et gérer pour vous une nouvelle table ayant l'indexé comme clé de partition - donc Cassandra a déjà dénormalisé et dupliqué vos données. Retirez votre index et créer une nouvelle table

CREATE TABLE sensor_info_table_by_timestamp 
(
    asset_id text, 
    event_time timestamp, 
    "timestamp" timeuuid, 
    sensor_reading map<text, text>, 
    sensor_serial_number text, 
    sensor_type int, 
    PRIMARY KEY ("timestamp", asset_id, event_time) 
); 

Maintenant, quand vous écrivez des données que vous mettez dans les deux tables (vous pouvez utiliser un lot). Et votre requête sera

SELECT * from mydb.sensor_info_table_by_timestamp where timestamp IN (bfdfa614-3166-11e4-a61d-b888e30f5d17 , bf4521ac-3166-11e4-87a3-b888e30f5d17) ; 

Je vois que vous aussi créé un index de recherche sur event_time - si vous devez effectuer la requête en utilisant IN prédicat vous devrez créer une troisième table ...

HTH , Carlo

Answer 2

[J'avais posté cette requête sur les utilisateurs cassandra liste de diffusion, et selon la suggestion que je fini par créer deux tables pour gérer cette exigence]

CREATE TABLE sensor_asset (
    asset_id text, 
    event_time timestamp, 
    tuuid timeuuid, 
    sensor_reading map<text, text>, 
    sensor_serial_number text, 
    sensor_type int, 
    PRIMARY KEY ((asset_id), event_time) 
); 

CREATE TABLE sensor_tuuid (
    asset_id text, 
    event_time timestamp, 
    tuuid timeuuid, 
    sensor_reading map<text, text>, 
    sensor_serial_number text, 
    sensor_type int, 
    PRIMARY KEY (tuuid) 
);