Cassandra et ScyllaDB

Comment exécuter du CQL, quel niveau de cohérence choisir, comment arrivent les pages et la trace, ce que fait Arrêter et ce que CQL n’a pas.

Où le trouver : Espace de travail › Outils › Requête CQL

S'applique à : Cassandra ScyllaDB

La requête CQL envoie au serveur ce que vous tapez, par la session ouverte. Exécuter (⌘↩) exécute tout le texte instruction par instruction, ou seulement la sélection s’il y en a une. Un BEGIN BATCH … APPLY BATCH part entier, et un ; dans un littéral, un bloc $$…$$ ou un commentaire ne coupe pas. La première instruction qui échoue arrête les suivantes, et l’erreur dit laquelle (« Instruction 2 : … »). Un USE change le keyspace de la session, et la barre l’indique.

Le niveau de cohérence
Chaque donnée vit sur plusieurs répliques, et le niveau de cohérence dit combien doivent répondre avant que le serveur réponde. On le choisit dans Cohérence, et il vaut pour ce qui s’exécute ensuite :
- LOCAL_ONE, celui par défaut, attend une réplique du centre de données local : c’est le plus rapide, et une lecture peut ne pas encore voir une écriture récente.
- ONE, TWO et THREE attendent ce nombre de répliques, où qu’elles soient.
- QUORUM attend la majorité des répliques, LOCAL_QUORUM la majorité du centre de données local et EACH_QUORUM la majorité de chacun. Une écriture et une lecture en QUORUM se rencontrent toujours sur une réplique.
- ALL les attend toutes, et échoue dès qu’une est en panne.
- ANY ne vaut que pour écrire, et SERIAL et LOCAL_SERIAL servent aux transactions légères (IF NOT EXISTS, IF …).
S’il n’y a pas assez de répliques vivantes, le serveur répond par une erreur qui dit combien il en fallait et combien il y en avait. Voir la solution mène au chapitre du Manuel du DBA qui explique l’erreur : celui de la cohérence pour celle-ci ou un délai dépassé, celui des rôles et permissions pour un Unauthorized, et celui des erreurs fréquentes pour les autres qu’il explique, une erreur de syntaxe comprise.

Les pages
Un SELECT arrive par pages, et Lignes par page dit combien de lignes chacune demande : 200 si vous ne le changez pas. Page suivante ramène la suivante tant que le serveur dit qu’il peut y en avoir d’autres ; parfois la dernière arrive vide, et c’est alors indiqué : « Il n’y a plus de lignes. ».

La trace
Avec Tracer activé, le serveur note par où est passée chaque instruction, et le pied de page porte le lien vers sa trace.

Ce qu’on voit
La grille écrit chaque valeur comme cqlsh, et l’en-tête de chaque colonne porte son type. La vue JSON réexécute un SELECT en SELECT JSON et montre ce que renvoie le serveur ; pour une autre instruction, il n’y a pas de JSON. Les avertissements du serveur apparaissent dans un bandeau, « Avertissements du serveur » : Cassandra avertit par exemple d’un count(*) sans clé de partition, ScyllaDB non. Le pied de page donne les lignes, le temps et le nombre d’instructions exécutées.

Ce qui écrit
INSERT, UPDATE, DELETE, TRUNCATE, CREATE, ALTER, DROP, GRANT, REVOKE et un BATCH passent d’abord par la garde de l’étiquette d’environnement de la session, qui peut demander une confirmation. Une écriture affiche « Appliqué. CQL n’indique pas combien de lignes il a écrites. » : le protocole ne renvoie pas combien de lignes elle a touchées.

Arrêter
Pendant l’exécution, Arrêter (⌘.) cesse d’attendre la réponse, et la connexion reste ouverte. Mais le protocole n’a aucun moyen d’annuler sur le serveur : ce qui a commencé, le serveur le termine. Un UPDATE arrêté peut avoir été appliqué.

Ce que CQL n’a pas
Il n’y a ni EXPLAIN ni transactions de plusieurs instructions : un BATCH journalisé s’applique en entier ou pas du tout, mais n’isole pas ceux qui lisent pendant ce temps, et la trace est ce qui ressemble le plus à un plan. Une requête qui ne filtre pas par la clé de partition est refusée par le serveur sauf si elle porte ALLOW FILTERING, qui l’oblige à lire toutes les partitions : sur une grande table, c’est coûteux, et la réponse est presque toujours une autre table avec une autre clé.

Mots-clés : cassandra, scylladb, cql, requête, cohérence, quorum, local_one, page, trace, allow filtering, batch, keyspace, arrêter

L’arbre du schéma, d’où vient le DDL, l’échantillon de lignes, et ce qui se modifie par clé primaire et ce qui ne se modifie pas.

Où le trouver : Espace de travail › Outils › Keyspaces

S'applique à : Cassandra ScyllaDB

L’explorateur lit system_schema et affiche chaque keyspace avec ses tables, vues matérialisées, types, index, fonctions et agrégats. Un keyspace est lu quand on le déplie ou qu’on le choisit, pas tous d’un coup, et une catégorie vide n’est pas dessinée. Filtrer par nom filtre l’arbre par nom. Les keyspaces qui appartiennent au serveur lui-même (system*, et audit dans ScyllaDB) viennent en dernier, repliés, sous « Keyspaces du serveur ».

La clé de partition
Dans Cassandra, la clé primaire a deux parties. La clé de partition décide sur quels nœuds vit chaque ligne : les lignes avec la même clé de partition vivent ensemble, et une requête efficace la donne entière. Les colonnes de regroupement ordonnent les lignes dans la partition, dans l’ordre que déclare la table (ASC ou DESC). Le reste, ce sont des colonnes régulières, et une colonne statique garde une valeur par partition, pas par ligne. Structure affiche chaque colonne avec son rôle, sa position et son ordre, la clé primaire complète et les propriétés de la table.

DDL
C’est le serveur qui écrit le DDL : on le lui demande avec DESCRIBE, que Cassandra et ScyllaDB acceptent pour keyspace, table, vue, type, index, fonction et agrégat, et le panneau dit qu’il vient de là. Celui d’une table est suivi de ses index et de ses vues. Si un serveur n’accepte pas DESCRIBE, le DDL est reconstruit à partir de system_schema et le panneau le dit aussi ; les fonctions et les agrégats ne sont pas reconstruits. Copier le DDL le copie en entier.

Lignes
L’échantillon lit 100 lignes par page, sans WHERE ni ALLOW FILTERING, dans l’ordre où le serveur parcourt les partitions, qui n’est pas l’ordre d’insertion. Page suivante apporte la suivante et Recharger les lignes recommence. Afficher le jeton de la partition ajoute la colonne token(), le nombre qui décide sur quel nœud tombe chaque partition, et Heure d’écriture et TTL de ajoute writetime et ttl d’une colonne régulière : quand la valeur a été écrite, en microsecondes, et combien de secondes il lui reste avant d’expirer. Cela ne vaut ni pour une colonne de la clé, ni pour un compteur, ni pour une collection non figée.

Modifier des lignes
Insérer une ligne…, au-dessus de la grille, et sur chaque ligne le menu « … » avec Modifier la ligne… et Supprimer la ligne… écrivent toujours par la clé entière, partition et regroupement, et avec une transaction légère : insérer, c’est INSERT … IF NOT EXISTS, donc une clé qui existe déjà n’est pas remplacée ; enregistrer, c’est UPDATE … IF EXISTS et supprimer, DELETE … IF EXISTS, et si la ligne n’est plus sur le serveur, on le dit. En enregistrant, seul ce qui a changé est écrit, et Sans valeur (null) efface la cellule. Ce qu’on tape est converti au type que déclare le serveur avant d’envoyer quoi que ce soit : dates et heures en UTC (2026-01-31 10:00:00), un blob en hexadécimal (0x…), une durée comme 1h30m et un décimal avec un point ou une virgule. Après l’écriture, la ligne est relue et change sur place, sans recharger la page. L’alerte de suppression nomme la clé entière.

Ce qui ne se modifie pas ici
Une collection, un UDT, un tuple, un type custom et une colonne statique se changent dans la requête CQL, et la feuille le dit. On ne modifie pas non plus une table de compteurs, qui n’admet qu’ajouter ou soustraire, un keyspace du serveur, ni une table dont la clé porte un type qui ne s’écrit pas sur une ligne. Il n’y a ni TRUNCATE ni suppression par filtre : la requête CQL est là pour ça. Avec une étiquette d’environnement en « lecture seule », rien de ce qui écrit n’est dessiné, et avec une qui « confirme les écritures », le garde demande avant chaque écriture.

Mots-clés : cassandra, scylladb, keyspace, schéma, ddl, describe, clé de partition, regroupement, token, writetime, ttl, modifier une ligne, insérer, supprimer

Quels nœuds il affiche et d’où ils viennent, ce qu’est la part de l’anneau, comment on sait qu’un nœud est arrêté, et ce qui reste à nodetool.

Où le trouver : Espace de travail › Outils › Cluster

S'applique à : Cassandra ScyllaDB

Le Cluster affiche les nœuds que connaît le nœud auquel la session est connectée, le coordinateur : sa propre ligne de system.local et celles de ses pairs, lues dans system.peers_v2 sous Cassandra (ou system.peers s’il ne l’a pas) et dans system.peers sous ScyllaDB. On ne demande rien aux pairs : ce qu’on voit, c’est ce que le coordinateur sait d’eux. En haut viennent le nom du cluster, le partitionneur, combien de nœuds sont actifs —ceux qui ne le sont pas, nommés un par un— et si tous publient la même version de schéma ; sinon, un changement de schéma n’a pas encore atteint tout le monde.

L’anneau
Cassandra et ScyllaDB répartissent les données sur un anneau de jetons : chaque ligne tombe sur le jeton que donne sa clé de partition, et chaque nœud possède les tranches qui se terminent à ses jetons (la colonne Jetons dit combien il en a). Part de l’anneau est la part de l’anneau couverte par les jetons de chaque nœud sans compter les réplicas, la même que donne nodetool status pour un keyspace au facteur de réplication 1. Sans keyspace, nodetool donne la part effective, qui compte les copies : avec trois nœuds et un facteur 3, 100 % pour chacun. Elle n’est calculée qu’avec Murmur3Partitioner, le partitionneur par défaut ; avec un autre, la colonne reste vide et la note le dit.

État
Sous ScyllaDB, l’état vient de system.cluster_status. Sous Cassandra, il vient de system_views.gossip_info, qui cache un piège : un nœud qui s’arrête proprement dit au revoir et apparaît Arrêté, mais un nœud qui tombe sans prévenir reste NORMAL. On le lit donc deux fois, à quelques secondes d’intervalle, et si son battement (heartbeat) n’a pas avancé, il apparaît Arrêté : pas de battement. Un nœud qui entre, sort ou se déplace apparaît en transition, avec le mot du serveur. Et un pair pour lequel le coordinateur n’a aucune ligne d’état est Inconnu : d’un nœud qu’on n’a pas pu voir, on n’affirme pas qu’il est arrêté. Chaque état porte son symbole et son nom, pas seulement une couleur.

Actualiser
Rien ne se relit tout seul, parce que chaque lecture attend ces quelques secondes pour mesurer le battement : on relit avec Actualiser. Si une lecture échoue et qu’il y en avait une avant, l’ancienne reste affichée et on vous dit qu’elle n’est pas à jour.

La version sous ScyllaDB
Les pairs de ScyllaDB publient une version de compatibilité avec Cassandra, pas la leur : la colonne affiche celle du coordinateur, lue dans system.versions, et une note le dit.

Ce qui n’est pas ici
La réplication de Cassandra, c’est l’anneau lui-même, et elle se voit dans cet onglet : il n’y a pas de moniteur de réplicas à part. Le Cluster ne fait que lire : ce qui relève de nodetool —réparer, nettoyer, retirer ou déplacer un nœud, les instantanés—, de JMX ou de l’API REST de ScyllaDB reste en dehors.

Mots-clés : cassandra, scylladb, cluster, anneau, nœud, jeton, coordinateur, gossip, heartbeat, battement, nodetool, owns, centre de données, rack, version de schéma

Ce que le nœud connecté dit de lui-même —version, caches, compactages, disque, latences et réglages—, d’où cela vient dans chaque produit, et ce qui reste à nodetool.

Où le trouver : Espace de travail › Outils › Nœud

S'applique à : Cassandra ScyllaDB

Le Nœud affiche ce que le nœud auquel la session est connectée dit de lui-même, lu dans ses tables virtuelles : system_views dans Cassandra et les tables de system dans ScyllaDB. Tout est à ce nœud : on ne demande rien aux pairs, et dans un cluster chaque nœud a ses propres caches, ses compactages et son disque. Pour en voir un autre, la session doit s’y connecter.

En haut
Version est celle du serveur : celle de system.local dans Cassandra et celle de system.versions dans ScyllaDB, qui est la sienne et non celle de compatibilité avec Cassandra. Viennent ensuite une carte par cache, avec son taux de succès, son nombre d’entrées et ce qu’il occupe de sa capacité : dans Cassandra les caches de clés, de lignes et de compteurs, de system_views.caches ; dans ScyllaDB le Cache de lignes, du groupe cache de system.runtime_info. Un cache de capacité 0 est désactivé dans la configuration du serveur —celui des lignes de Cassandra est livré ainsi— et la carte le dit. Compactages en cours compte ceux qui tournent maintenant : dans Cassandra, ils viennent de system_views.sstable_tasks, avec leur avancement ; dans ScyllaDB, de system.compactions_in_progress, qui ne donne pas d’avancement mais dit combien de SSTables y entrent. S’il y en a, leur table apparaît en dessous.

Les sections
En dessous, une table par section, et chaque produit déclare les siennes : ce que le serveur ne publie pas n’est pas dessiné.
- Pools de threads (Cassandra seulement, system_views.thread_pools) : les tâches actives, en attente et bloquées de chaque pool. Ce sont les tâches en attente et bloquées qui disent si le nœud suit.
- Latence par table (Cassandra seulement, coordinator_read_latency et coordinator_write_latency) : p50 et p99 de lecture et d’écriture, en millisecondes. C’est la latence que voit ce nœud comme coordinateur des requêtes qu’il reçoit, pas celle de ses répliques.
- Taille par table : dans Cassandra, l’espace disque de system_views.disk_usage, arrondi au Mio entier supérieur ; dans ScyllaDB, l’estimation de system.size_estimates additionnée par table, qui donne 0 à une table dont les données n’ont pas encore été écrites sur disque et inclut les tables que ScyllaDB crée pour les index et pour les transactions légères (…$paxos), car elles occupent vraiment de la place.
- Grandes partitions : dans Cassandra, la plus grande partition de chaque table, de system_views.max_partition_size ; dans ScyllaDB, seulement celles qui ont dépassé le seuil du serveur lors du compactage, de system.large_partitions, donc vide est normal.
- Historique des compactages : les 100 compactages les plus récents de system.compaction_history, avec ce qu’ils ont lu et écrit, et le total à côté.
- Chiffres de fonctionnement : les compteurs que le serveur publie, avec leur nom : system_views.cql_metrics dans Cassandra et system.runtime_info dans ScyllaDB, qui donne aussi depuis combien de temps il tourne, tel que le serveur l’écrit.
- Réglages : la configuration avec laquelle tourne le nœud, de system_views.settings dans Cassandra et de system.config dans ScyllaDB, qui dit en plus d’où vient chaque valeur. Filtrer les réglages restreint la liste par nom.

La taille, les partitions et les latences laissent de côté les keyspaces du serveur ; l’historique, non. Si une section ne peut pas être lue, on vous dit laquelle et pourquoi, et les autres continuent.

Actualiser
Rien ne se relit tout seul : on relit avec Actualiser. Si une lecture échoue et qu’il y en avait une avant, la précédente reste affichée et on vous dit qu’elle n’est pas actuelle.

Ce qui n’est pas ici
Le Nœud ne fait que lire. Ce qui relève de nodetool —vider les memtables, lancer ou arrêter un compactage, changer le niveau de journalisation, reconstruire des index—, de JMX ou de l’API REST de ScyllaDB est laissé de côté, et un réglage ne se change pas d’ici : il se change dans la configuration du serveur.

Mots-clés : cassandra, scylladb, nœud, version, cache, taux de succès, compactage, sstable, threads, thread pool, latence, disque, taille, grande partition, réglages, configuration, uptime, nodetool, jmx

Quelles connexions le nœud connecté a ouvertes, avec quel utilisateur, pilote, protocole et TLS, lesquelles sont à Calíope, et pourquoi on ne les déconnecte pas d’ici.

Où le trouver : Espace de travail › Outils › Clients

S'applique à : Cassandra ScyllaDB

Clients affiche les connexions ouvertes sur le nœud auquel la session est connectée, telles que ce nœud les publie lui-même : system_views.clients dans Cassandra et system.clients dans ScyllaDB. Seulement celles de ce nœud : chaque nœud publie les siennes, et celles qu’un client a ouvertes avec un autre nœud du cluster n’apparaissent pas ici. Pour les voir, la session doit se connecter à ce nœud.

Les colonnes
- Client : l’adresse et le port d’où vient la connexion, avec le nom d’hôte en dessous quand le serveur le connaît et que ce n’est pas l’adresse elle-même.
- Utilisateur : l’utilisateur avec lequel elle s’est authentifiée.
- Pilote : le nom et la version que le pilote a déclarés en se connectant. cqlsh se présente comme « DataStax Python Driver » dans Cassandra et comme « ScyllaDB Python Driver » dans ScyllaDB, et ouvre deux connexions : une de contrôle et une autre pour les requêtes.
- Protocole : la version du protocole natif que la connexion a négociée.
- TLS : si la connexion est chiffrée et, quand le serveur le dit, avec quelle version de TLS.
- Étape : l’étape de la connexion, écrite comme l’écrit le serveur (ScyllaDB, en majuscules : READY).
- Requêtes et Keyspace (Cassandra seulement) : combien de requêtes la connexion a faites et le keyspace utilisé, qui affiche un tiret si elle n’a pas fait de USE.
- Shard (ScyllaDB seulement) : le shard du nœud qui sert la connexion.

Une colonne qu’un produit ne publie pas n’est pas dessinée, et une valeur que le serveur ne donne pas affiche un tiret.

Calíope
Les connexions de Calíope portent leur marque —un glyphe et le nom Calíope, pas seulement une couleur— et viennent en premier ; les autres suivent par adresse et port. Calíope se présente au serveur sous le nom « Caliope », et c’est ainsi qu’on les reconnaît : toutes celles de l’app sont marquées, celles de cette fenêtre et celles de tout autre appareil où Calíope est ouvert sur le même nœud, car l’adresse ne suffit pas à savoir laquelle est celle de cette fenêtre (derrière un tunnel ou un NAT, elles arrivent toutes de la même).

Filtrer
Filtrer par adresse, utilisateur, pilote… restreint le tableau par adresse, port, nom d’hôte, utilisateur, pilote et sa version, keyspace ou étape, et le résumé dit combien du total sont affichées.

Actualiser
La liste ne se relit pas toute seule : on la relit avec Actualiser. Si une lecture échoue et qu’il y en avait une avant, la précédente reste affichée et on vous dit qu’elle n’est pas actuelle.

Ce qui n’est pas ici
Clients ne fait que lire. Calíope ne déconnecte personne, car CQL n’a aucune instruction pour fermer la connexion d’un autre client, et le pied de l’onglet le dit. Cela reste à nodetool, à JMX ou à l’API REST de ScyllaDB.

Mots-clés : cassandra, scylladb, clients, connexions, sessions, utilisateur, pilote, protocole, tls, keyspace, shard, cqlsh, calíope, nodetool

Comment lire une trace de Cassandra ou ScyllaDB, ce que chaque produit publie en plus —les requêtes lentes de ScyllaDB, ce qui tourne en ce moment dans Cassandra— et comment activer le journal des requêtes lentes de ScyllaDB.

Où le trouver : Espace de travail › Outils › Traces

S'applique à : Cassandra ScyllaDB

Traces affiche ce que le serveur enregistre des requêtes qu’on lui demande de tracer, et ce que chaque produit publie en plus : les requêtes lentes dans ScyllaDB et ce qui tourne en ce moment dans Cassandra. Les onglets dépendent du produit, et celui qu’un produit n’a pas n’est pas dessiné.

Sessions tracées (les deux)
Une trace, c’est ce que le coordinateur et chaque réplique ont noté en servant une requête. Le serveur la garde dans system_traces.sessions (une ligne par requête) et system_traces.events (une par étape). On ne trace que ce qu’on demande : activez Tracer dans la Requête CQL avant d’exécuter, et le pied du résultat apporte un bouton avec l’identifiant de la trace, qui l’ouvre directement ici. Les traces expirent au bout de 24 heures.

La liste affiche les sessions les plus récentes. Dans ScyllaDB, on les cherche par leur index temporel (sessions_time_idx), en remontant depuis l’heure du serveur, et le total n’est pas lu. Cassandra n’a pas cet index : la table est lue jusqu’à un plafond et triée ici, et si la lecture a atteint le plafond l’écran le dit, car il peut y en avoir de plus récentes qui n’ont pas été lues. Dans ScyllaDB, chaque requête lente écrit aussi sa session, si bien que la liste contient plus que celles que vous avez demandé de tracer.

L’heure de chaque ligne (Début) ouvre sa trace : début, durée, commande, coordinateur, client, l’utilisateur (seul ScyllaDB le note) et, quand le serveur le note, le niveau de cohérence ; l’instruction, avec Ouvrir dans la Requête CQL ; et les événements dans l’ordre. Chaque événement donne Écoulé —les microsecondes que son nœud avait passées sur la requête—, une barre proportionnelle à ce temps, l’activité, Nœud et le thread. Deux nœuds ne partagent pas d’horloge : le temps de chaque événement est celui de son nœud, et comparer deux nœuds par cette colonne induit en erreur.

Le serveur écrit la trace pendant que la requête continue : une trace qu’on vient de demander peut arriver sans événements ou avec sa durée non terminée. À l’ouverture, elle est relue quelques fois, à une demi-seconde d’intervalle, jusqu’à ce qu’elle apporte sa durée ; si elle n’arrive pas, on vous le dit, et il suffit de la relire avec Actualiser quelques secondes plus tard. Revenir aux sessions tracées ramène à la liste.

Lentes (ScyllaDB seulement)
ScyllaDB note dans system_traces.node_slow_log chaque requête qui dépasse un seuil, avec son début, sa durée, l’instruction, les tables, l’utilisateur, et le nœud et le shard qui l’ont servie. On les cherche par node_slow_log_time_idx, sur les dernières 24 heures. L’heure ouvre la trace de cette requête —ScyllaDB en écrit une pour chaque requête lente— et le bouton en bout de ligne l’emmène dans la Requête CQL.

Le journal est désactivé par défaut, et ni le seuil ni son état ne se lisent par CQL : ils relèvent de l’API REST de ScyllaDB (port 10000). C’est pourquoi l’onglet affiche l’entrée la plus récente et la plus courte de celles lues, seule chose que CQL permet de savoir. Pour l’activer avec un seuil de 500 µs (le seuil est en microsecondes), et pour lire son état :

curl -X POST "http://<nœud>:10000/storage_service/slow_query?enable=true&threshold=500"
curl http://<nœud>:10000/storage_service/slow_query

La seconde renvoie quelque chose comme {"enable": true, "ttl": 86400, "threshold": 500, "fast": false}. Il s’active nœud par nœud, il n’est pas dans scylla.yaml, et un redémarrage du nœud le désactive. Calíope ne le fait pas à votre place parce qu’il ne parle que CQL : l’API REST est la porte d’administration de ScyllaDB, distincte de CQL et en général inaccessible depuis l’extérieur du cluster, et ce qui est le métier de nodetool, de JMX ou de l’API REST reste dehors.

En cours (Cassandra seulement)
Ce qui tourne en ce moment sur le nœud de la session, depuis system_views.queries : le thread, En file et En cours en microsecondes, et la requête. La lecture de cette liste en fait partie, et chaque nœud ne publie que les siennes. Cassandra ne publie pas ses requêtes lentes par CQL : elle les note dans son journal texte à partir de slow_query_log_timeout, que le pied indique tel que le nœud l’a.

Actualiser
Rien ne se relit tout seul : l’onglet se relit avec Actualiser, et la barre dit à quelle heure a eu lieu la dernière lecture. Si une lecture échoue et qu’il y en avait une avant, la précédente reste affichée et on vous dit qu’elle n’est pas actuelle.

Tout cela ne fait que lire : les traces et le journal des requêtes lentes sont écrits par le serveur, et ils expirent tout seuls.

Mots-clés : cassandra, scylladb, traces, trace, tracing, sessions, événements, lentes, requêtes lentes, journal des requêtes lentes, system_traces, node_slow_log, system_views.queries, seuil, api rest, curl

Ce qu’est un rôle de Cassandra ou ScyllaDB, d’où viennent la liste et la fiche, sur quelles ressources on accorde les permissions, ce qui s’écrit et comment voyage le mot de passe, et pourquoi il n’y a pas de rôles sans authentification.

Où le trouver : Espace de travail › Outils › Rôles

S'applique à : Cassandra ScyllaDB

Rôles affiche les rôles du serveur et ce que chacun peut faire, et permet de les créer, de les modifier, de leur accorder des permissions et de les supprimer.

Ce qu’est un rôle
Un rôle est à la fois un utilisateur et un groupe. S’il a Peut se connecter et un mot de passe, quelqu’un se connecte avec lui ; sinon, il sert à regrouper des permissions et à être accordé à d’autres rôles, qui héritent de ce qu’il a. Un rôle Superutilisateur peut tout faire, même si la liste ne nomme pas chaque permission, et la fiche le dit.

Sans authentification, pas de rôles
Les rôles n’existent que lorsque le serveur demande un utilisateur et un mot de passe à la connexion (PasswordAuthenticator). Avec AllowAllAuthenticator, ce que Cassandra et ScyllaDB ont à l’installation, n’importe qui entre sans identifiants et il n’y a rien à administrer : l’onglet le dit avec son motif et ne demande rien au serveur, qui répondrait par une erreur.

La liste et la fiche
La liste vient de LIST ROLES, la même dans les deux produits : le nom, Superutilisateur, Peut se connecter et, dans Cassandra seulement, Centres de données. Le filtre restreint par nom. Quand vous choisissez un rôle, la fiche affiche Permissions propres, de LIST ALL PERMISSIONS OF ; à part, Hérités des rôles dont il fait partie, chacune avec le rôle dont elle vient ; et Fait partie de, de LIST ROLES OF. Ce qui est hérité ne se révoque pas ici : on le retire sur le rôle dont il vient, ou on sort le rôle de ce groupe.

Ressources et permissions
Une permission s’accorde sur une ressource : Tous les keyspaces, Un keyspace, Une table, Tous les rôles, Un rôle ou Toutes les fonctions. Les permissions sont ALL PERMISSIONS, SELECT, MODIFY, CREATE, ALTER, DROP, AUTHORIZE, DESCRIBE et EXECUTE ; Cassandra ajoute SELECT_MASKED et UNMASK, celles des colonnes masquées, que ScyllaDB n’a pas. Toute permission ne vaut pas pour toute ressource, et le serveur rejette avec son message la paire qui n’a pas de sens.

Ce qui s’écrit
Nouveau rôle… crée un rôle avec son nom, son mot de passe et s’il a Peut se connecter ou est Superutilisateur ; sans mot de passe, le rôle ne peut pas se connecter même avec LOGIN. Modifier… n’envoie que ce que vous changez (ALTER ROLE) ; Cassandra ne laisse pas changer le mot de passe d’un rôle deux fois en moins de 5 secondes. Accorder une permission… accorde une permission sur une ressource, et Ajouter à un rôle…, l’appartenance à un autre rôle ; le bouton au bout de chaque ligne la révoque. Supprimer le rôle… supprime le rôle avec ses permissions et ses appartenances. Retirer quelque chose —supprimer ou révoquer— demande d’abord une confirmation qui nomme le rôle.

Tout ce qui écrit passe par la protection de la connexion : avec une étiquette d’environnement en lecture seule, rien de ce qui écrit n’est dessiné, et avec une qui confirme, chaque changement demande avant d’être envoyé.

Le mot de passe
CQL ne permet pas d’envoyer le mot de passe à part : il voyage dans l’instruction (CREATE ROLE … WITH PASSWORD = '…') jusqu’au serveur, qui le garde sous forme de hash, pas en clair. Sur le réseau, il n’est chiffré que si la connexion utilise TLS. Dans Journal des commandes, l’instruction reste avec le mot de passe masqué.

Actualiser
Rien ne se relit tout seul : la liste se relit avec Actualiser, et la barre dit à quelle heure a eu lieu la dernière lecture. Si une lecture échoue et qu’il y en avait une avant, la précédente reste affichée et on vous dit qu’elle n’est pas celle de maintenant.

Mots-clés : cassandra, scylladb, rôles, rôle, permissions, utilisateurs, grant, revoke, create role, alter role, drop role, list roles, superutilisateur, login, mot de passe, authentification, passwordauthenticator, allowallauthenticator

Ce qu’est un rapport CQL : un seul SELECT avec des paramètres :nom, préparé et lié selon le type de chaque colonne, qui lit toutes les pages jusqu’au plafond.

Où le trouver : Espace de travail › Outils › Rapports

S'applique à : Cassandra ScyllaDB

Dans une session Cassandra ou ScyllaDB, Nouveau rapport crée un rapport CQL : son texte est une seule instruction SELECT, et il naît avec SELECT * FROM demo.productos LIMIT 100. Une autre instruction —un INSERT, un USE—, deux instructions ou un ? sans nom sont refusés avant d’envoyer quoi que ce soit au serveur.

Paramètres
Un paramètre s’écrit :nom dans le texte et se déclare avec Déclarer les paramètres. Calíope remplace chaque :nom par ? et prépare l’instruction : le serveur donne le type CQL de chaque marqueur, et la valeur s’écrit selon ce type, jamais dans le texte. Un uuid part comme uuid et un decimal exact, sans passer par la virgule flottante ; une valeur qui ne va pas avec sa colonne est refusée avec le nom du paramètre. Si le serveur compte un autre nombre de marqueurs que de paramètres, le rapport échoue et donne les deux nombres.

Ce qui est lu
Chaque fois que vous appuyez sur Exécuter, Calíope lit toutes les pages du résultat, 200 par 200, jusqu’au plafond de lignes du rapport, et dit s’il a été coupé. Arrêter l’arrête entre une page et la suivante. Les types des colonnes viennent de ce que le serveur déclare du résultat : entiers, decimal, float et double comme nombres, timestamp comme date et heure en UTC, date comme date, blob comme binaire et boolean ; les collections, les types utilisateur, uuid et inet sortent tels que cqlsh les écrit.

Le reste
Ce que lit un rapport ne reste pas dans le Journal des commandes : c’est une lecture de l’outil, pas une instruction de la Requête CQL. Exporter et Historique marchent comme pour tout rapport. Un rapport CQL ne s’exécute que dans une session Cassandra ou ScyllaDB, n’accepte pas de script à plusieurs instructions, et Planifier ne sert à rien avec lui : seuls les rapports sur une base relationnelle se planifient.

Mots-clés : cassandra, scylladb, cql, rapport, select, paramètre, préparer, pages, plafond, exporter, historique