Utiliser des colonnes statiques - ApsaraDB for Cassandra - Deprecated

Scénario

Supposons qu'une table Cassandra stocke les informations utilisateur (adresse e-mail et mot de passe) ainsi que les mises à jour de statut. En général, les informations utilisateur restent stables tandis que le statut change fréquemment. Mettre à jour les informations utilisateur à chaque modification de statut consomme inutilement beaucoup d'espace de stockage.

Cassandra propose les colonnes statiques pour résoudre ce problème. Une colonne statique, déclarée au sein d'une même clé de partition, ne possède qu'une seule valeur partagée par toutes les lignes de cette partition.

Définir une colonne statique

Ajoutez le mot-clé STATIC après le type de données d'une colonne pour la définir comme statique, comme illustré ci-dessous :

CREATE TABLE "iteblog_users_with_status_updates" (
  "username" text,
  "id" timeuuid,
  "email" text STATIC,
  "encrypted_password" blob STATIC,
  "body" text,
  PRIMARY KEY ("username", "id")
);

La commande précédente définit les champs email et encrypted_password comme statiques. Ainsi, pour un nom d'utilisateur donné, il n'existe qu'une seule valeur d'e-mail et une seule valeur de mot de passe chiffré, partagées par toutes les lignes de la partition.

Limites des colonnes statiques

Vous ne pouvez pas utiliser le mot-clé STATIC dans toutes les configurations de table. Les colonnes statiques sont soumises aux limites suivantes :

La table ne doit pas avoir de colonnes de clustering (clés de clustering). Si aucune colonne de clustering n'est définie, l'utilisation de colonnes statiques est interdite, comme le montre l'exemple suivant :

cqlsh:iteblog_keyspace> CREATE TABLE "iteblog_users_with_status_updates_invalid" (
                    ...   "username" text,
                    ...   "id" timeuuid,
                    ...   "email" text STATIC,
                    ...   "encrypted_password" blob STATIC,
                    ...   "body" text,
                    ...   PRIMARY KEY ("username")
                    ... );
InvalidRequest: Error from server: code=2200 [Invalid query] message="Static columns are only useful (and thus allowed) if the table has at least one clustering column"

La création de colonnes statiques échoue dans la table iteblog_users_with_status_updates_invalid car elle ne possède qu'une clé primaire de partition sans colonnes de clustering. Les colonnes statiques sont utiles lorsque plusieurs lignes partagent la même clé de partition (grâce aux colonnes de clustering). Sans colonnes de clustering, chaque clé de partition identifie une ligne unique, rendant les colonnes statiques inutiles.

La table utilise l'option COMPACT STORAGE, comme illustré ci-dessous :

cqlsh:iteblog_keyspace> CREATE TABLE "iteblog_users_with_status_updates_invalid" (
                    ...   "username" text,
                    ...   "id" timeuuid,
                    ...   "email" text STATIC,
                    ...   "encrypted_password" blob STATIC,
                    ...   "body" text,
                    ...   PRIMARY KEY ("username", "id")
                    ... )WITH COMPACT STORAGE;
InvalidRequest: Error from server: code=2200 [Invalid query] message="Static columns are not supported in COMPACT STORAGE tables"

Une colonne faisant partie de la clé de partition ou des colonnes de clustering ne peut pas être statique, comme le montrent les exemples suivants :

cqlsh:iteblog_keyspace> CREATE TABLE "iteblog_users_with_status_updates_invalid" (
                    ...   "username" text,
                    ...   "id" timeuuid STATIC,
                    ...   "email" text STATIC,
                    ...   "encrypted_password" blob STATIC,
                    ...   "body" text,
                    ...   PRIMARY KEY ("username", "id")
                    ... );
InvalidRequest: Error from server: code=2200 [Invalid query] message="Static column id cannot be part of the PRIMARY KEY"
cqlsh:iteblog_keyspace> CREATE TABLE "iteblog_users_with_status_updates_invalid" (
                    ...   "username" text,
                    ...   "id" timeuuid,
                    ...   "email" text STATIC,
                    ...   "encrypted_password" blob STATIC,
                    ...   "body" text,
                    ...   PRIMARY KEY (("username", "id"), email)
                    ... );
InvalidRequest: Error from server: code=2200 [Invalid query] message="Static column email cannot be part of the PRIMARY KEY"

Insérer des données dans une table contenant des colonnes statiques

L'insertion de données dans une table avec des colonnes statiques fonctionne comme dans une table standard. Exécutez les instructions suivantes pour insérer des données dans la table iteblog_users_with_status_updates :

cqlsh:iteblog_keyspace> INSERT INTO "iteblog_users_with_status_updates"
                    ... ("username", "id", "email", "encrypted_password", "body")
                    ... VALUES (
                    ...   'iteblog',
                    ...   NOW(),
                    ...   'iteblog_hadoop@iteblog.com',
                    ...   0x877E8C36EFA827DBD4CAFBC92DD90D76,
                    ...   'Learning Cassandra!'
                    ... );
cqlsh:iteblog_keyspace> select username, email, encrypted_password, body from iteblog_users_with_status_updates;
 username | email                      | encrypted_password                 | body
----------+----------------------------+------------------------------------+---------------------
  iteblog | iteblog_hadoop@iteblog.com | 0x877e8c36efa827dbd4cafbc92dd90d76 | Learning Cassandra!
(1 rows)

Cette insertion réalise deux opérations :

Elle définit les valeurs des colonnes statiques email et encrypted_password pour l'utilisateur iteblog (iteblog_hadoop@iteblog.com et 0x877e8c36efa827dbd4cafbc92dd90d76).
Elle ajoute une ligne contenant le corps « Learning Cassandra! » à la partition iteblog. Exécutez l'instruction suivante pour insérer une autre ligne :

cqlsh:iteblog_keyspace> INSERT INTO "iteblog_users_with_status_updates"
                    ... ("username", "id", "body")
                    ... VALUES ('iteblog', NOW(), 'I love Cassandra!') ;
cqlsh:iteblog_keyspace> select username, email, encrypted_password, body from iteblog_users_with_status_updates;
 username | email                      | encrypted_password                 | body
----------+----------------------------+------------------------------------+---------------------
  iteblog | iteblog_hadoop@iteblog.com | 0x877e8c36efa827dbd4cafbc92dd90d76 | Learning Cassandra!
  iteblog | iteblog_hadoop@iteblog.com | 0x877e8c36efa827dbd4cafbc92dd90d76 |   I love Cassandra!
(2 rows)
cqlsh:iteblog_keyspace>

Notez que les colonnes email et encrypted_password ne sont pas spécifiées lors de la seconde insertion. Pourtant, le résultat de la requête montre que la nouvelle ligne hérite des valeurs définies précédemment pour ces colonnes statiques.

Si l'utilisateur modifie son adresse e-mail, comme illustré ci-dessous :

cqlsh:iteblog_keyspace> UPDATE iteblog_users_with_status_updates SET email = 'iteblog@iteblog.com'
                    ... WHERE username = 'iteblog';
cqlsh:iteblog_keyspace> select username, email, encrypted_password, body from iteblog_users_with_status_updates;
 username | email               | encrypted_password                 | body
----------+---------------------+------------------------------------+---------------------
  iteblog | iteblog@iteblog.com | 0x877e8c36efa827dbd4cafbc92dd90d76 | Learning Cassandra!
  iteblog | iteblog@iteblog.com | 0x877e8c36efa827dbd4cafbc92dd90d76 |   I love Cassandra!
(2 rows)

Le résultat de la requête confirme que l'adresse e-mail a été mise à jour pour toutes les lignes de l'utilisateur iteblog, car la colonne email est statique.

La table stocke les informations utilisateur (e-mail, mot de passe). Si un utilisateur modifie ses identifiants via l'interface, le backend doit récupérer les valeurs actuelles en exécutant l'instruction suivante :

cqlsh:iteblog_keyspace> SELECT "username", "email", "encrypted_password"
                    ... FROM "iteblog_users_with_status_updates"
                    ... WHERE "username" = 'iteblog';
 username | email               | encrypted_password
----------+---------------------+------------------------------------
  iteblog | iteblog@iteblog.com | 0x877e8c36efa827dbd4cafbc92dd90d76
  iteblog | iteblog@iteblog.com | 0x877e8c36efa827dbd4cafbc92dd90d76
(2 rows)

Cette requête renvoie plusieurs lignes dupliquées pour les colonnes statiques, ce qui peut être inattendu. Utilisez SELECT DISTINCT pour éliminer les doublons :

cqlsh:iteblog_keyspace> SELECT DISTINCT "username", "email", "encrypted_password"
                    ... FROM "iteblog_users_with_status_updates"
                    ... WHERE "username" = 'iteblog';
 username | email               | encrypted_password
----------+---------------------+------------------------------------
  iteblog | iteblog@iteblog.com | 0x877e8c36efa827dbd4cafbc92dd90d76
(1 rows)

Les doublons sont éliminés et une seule ligne unique apparaît.

Cassandra n'effectue pas une opération de déduplication coûteuse sur l'ensemble des données. Comme une seule valeur est stockée physiquement pour la colonne statique dans le système sous-jacent, le résultat est obtenu efficacement.