Cassandra e ScyllaDB

Come eseguire CQL, quale livello di coerenza scegliere, come arrivano le pagine e la traccia, cosa fa Interrompi e cosa CQL non ha.

Dove si trova: Workspace › Strumenti › Query CQL

Si applica a: Cassandra ScyllaDB

La query CQL invia al server quello che scrivi, sulla sessione aperta. Esegui (⌘↩) esegue tutto il testo istruzione per istruzione, o solo la selezione se c’è. Un BEGIN BATCH … APPLY BATCH va intero, e un ; dentro un letterale, un blocco $$…$$ o un commento non divide. La prima istruzione che fallisce ferma le altre, e l’errore dice quale («Istruzione 2: …»). Un USE cambia il keyspace della sessione, e la barra lo mostra.

Il livello di coerenza
Ogni dato vive su più repliche, e il livello di coerenza dice quante devono rispondere prima che il server risponda. Si sceglie in Coerenza e vale per quello che esegui dopo:
- LOCAL_ONE, quello predefinito, aspetta una replica del data center locale: è il più veloce, e una lettura può non vedere ancora una scrittura recente.
- ONE, TWO e THREE aspettano quel numero di repliche, ovunque siano.
- QUORUM aspetta la maggioranza delle repliche, LOCAL_QUORUM la maggioranza del data center locale e EACH_QUORUM la maggioranza di ciascuno. Una scrittura e una lettura in QUORUM si incontrano sempre su qualche replica.
- ALL le aspetta tutte, e fallisce appena una è giù.
- ANY vale solo per scrivere, e SERIAL e LOCAL_SERIAL sono per le transazioni leggere (IF NOT EXISTS, IF …).
Se non ci sono abbastanza repliche vive, il server risponde con un errore che dice quante ne servivano e quante ce n’erano. Vedi soluzione porta al capitolo del Manuale del DBA che spiega l’errore: quello della coerenza per questo o per un timeout, quello di ruoli e permessi per un Unauthorized, e quello degli errori frequenti per gli altri che spiega, anche uno di sintassi.

Le pagine
Un SELECT arriva a pagine, e Righe per pagina dice quante righe chiede ciascuna: 200 se non lo cambi. Pagina successiva porta la successiva finché il server dice che ce ne possono essere altre; a volte l’ultima arriva vuota, e allora lo dice: «Non ci sono altre righe.».

La traccia
Con Traccia attivo, il server annota da dove è passata ogni istruzione, e il piè di pagina porta il link alla sua traccia.

Cosa si vede
La griglia scrive ogni valore come cqlsh, e l’intestazione di ogni colonna porta il suo tipo. La vista JSON riesegue un SELECT come SELECT JSON e mostra cosa restituisce il server; per un’altra istruzione non c’è JSON. Gli avvisi del server compaiono in una striscia, «Avvisi del server»: Cassandra avvisa per esempio di un count(*) senza chiave di partizione, ScyllaDB no. Il piè di pagina dà le righe, il tempo e quante istruzioni sono state eseguite.

Cosa scrive
INSERT, UPDATE, DELETE, TRUNCATE, CREATE, ALTER, DROP, GRANT, REVOKE e un BATCH passano prima dalla protezione dell’etichetta d’ambiente della sessione, che può chiedere conferma. Una scrittura dice «Applicato. CQL non dice quante righe ha scritto.»: il protocollo non restituisce quante righe ha toccato.

Interrompi
Mentre è in corso, Interrompi (⌘.) smette di aspettare la risposta, e la connessione resta aperta. Ma il protocollo non ha modo di annullare sul server: quello che è già iniziato, il server lo finisce. Un UPDATE interrotto può essere stato applicato.

Cosa CQL non ha
Non ci sono EXPLAIN né transazioni di più istruzioni: un BATCH registrato si applica tutto o niente, ma non isola chi legge nel frattempo, e la traccia è quanto di più simile a un piano. Una query che non filtra per la chiave di partizione viene rifiutata dal server a meno che non porti ALLOW FILTERING, che lo obbliga a leggere tutte le partizioni: su una tabella grande è costoso, e la risposta è quasi sempre un’altra tabella con un’altra chiave.

Parole chiave: cassandra, scylladb, cql, query, coerenza, quorum, local_one, pagina, traccia, allow filtering, batch, keyspace, interrompi

L’albero dello schema, da dove viene il DDL, il campione di righe e cosa si modifica per chiave primaria e cosa no.

Dove si trova: Workspace › Strumenti › Keyspace

Si applica a: Cassandra ScyllaDB

L’esploratore legge system_schema e mostra ogni keyspace con le sue tabelle, viste materializzate, tipi, indici, funzioni e aggregati. Un keyspace si legge quando lo espandi o lo scegli, non tutti insieme, e una categoria vuota non viene disegnata. Filtra per nome filtra l’albero per nome. I keyspace che appartengono al server stesso (system*, e audit in ScyllaDB) vanno in fondo, chiusi, sotto «Keyspace del server».

La chiave di partizione
In Cassandra la chiave primaria ha due parti. La chiave di partizione decide su quali nodi vive ogni riga: le righe con la stessa chiave di partizione vivono insieme, e una query efficiente la fornisce per intero. Le colonne di clustering ordinano le righe dentro la partizione, nell’ordine che dichiara la tabella (ASC o DESC). Il resto sono colonne regolari, e una statica conserva un valore per partizione, non per riga. Struttura mostra ogni colonna con il suo ruolo, la sua posizione e il suo ordine, la chiave primaria completa e le proprietà della tabella.

DDL
Il DDL lo scrive il server: lo si chiede con DESCRIBE, che Cassandra e ScyllaDB accettano per keyspace, tabella, vista, tipo, indice, funzione e aggregato, e il pannello dice che viene da lì. Quello di una tabella porta dietro i suoi indici e le sue viste. Se un server non accetta DESCRIBE, il DDL si ricostruisce da system_schema e anche questo il pannello lo dice; funzioni e aggregati non si ricostruiscono. Copia DDL lo copia per intero.

Righe
Il campione legge 100 righe per pagina, senza WHERE né ALLOW FILTERING, nell’ordine in cui il server percorre le partizioni, che non è l’ordine di inserimento. Pagina successiva porta la successiva e Ricarica righe ricomincia. Mostra il token della partizione aggiunge la colonna token(), il numero che decide su quale nodo cade ogni partizione, e Ora di scrittura e TTL di aggiunge writetime e ttl di una colonna regolare: quando è stato scritto il valore, in microsecondi, e quanti secondi gli restano prima di scadere. Non vale per una colonna della chiave, un contatore o una collezione non congelata.

Modificare le righe
Inserisci riga…, sopra la griglia, e in ogni riga il menu «…» con Modifica riga… e Elimina riga… scrivono sempre per la chiave intera, partizione e clustering, e con una transazione leggera: inserire è INSERT … IF NOT EXISTS, quindi una chiave che esiste già non viene sostituita; salvare è UPDATE … IF EXISTS ed eliminare è DELETE … IF EXISTS, e se la riga non è più sul server lo si dice. Salvando si scrive solo ciò che è cambiato, e Senza valore (null) svuota la cella. Ciò che digiti viene convertito nel tipo che dichiara il server prima di inviare qualsiasi cosa: date e ore in UTC (2026-01-31 10:00:00), un blob in esadecimale (0x…), una durata come 1h30m e un decimale con il punto o con la virgola. Dopo la scrittura, la riga viene riletta e cambia al suo posto, senza ricaricare la pagina. L’avviso di eliminazione nomina la chiave intera.

Cosa non si modifica qui
Una collezione, un UDT, una tupla, un tipo custom e una colonna statica si cambiano nella query CQL, e il foglio lo dice. Non si modificano nemmeno una tabella di contatori, che ammette solo somme o sottrazioni, un keyspace del server né una tabella la cui chiave ha un tipo che non si scrive su una riga. Non c’è TRUNCATE né eliminazione per filtro: per questo c’è la query CQL. Con un’etichetta d’ambiente in «sola lettura» non si disegna nulla di ciò che scrive, e con una che «conferma le scritture» la protezione chiede prima di ogni scrittura.

Parole chiave: cassandra, scylladb, keyspace, schema, ddl, describe, chiave di partizione, clustering, token, writetime, ttl, modificare riga, inserire, eliminare

Quali nodi mostra e da dove vengono, cos’è la quota dell’anello, come si sa che un nodo è fermo e cosa resta a nodetool.

Dove si trova: Workspace › Strumenti › Cluster

Si applica a: Cassandra ScyllaDB

Il Cluster mostra i nodi che conosce il nodo a cui è collegata la sessione, il coordinatore: la sua riga di system.local e quelle dei suoi peer, da system.peers_v2 in Cassandra (o system.peers se non c’è) e da system.peers in ScyllaDB. Ai peer non si chiede nulla: quello che si vede è ciò che il coordinatore sa di loro. In alto ci sono il nome del cluster, il partitioner, quanti nodi sono attivi —con quelli che non lo sono nominati uno per uno— e se tutti pubblicano la stessa versione dello schema; se no, una modifica dello schema non ha ancora raggiunto tutti.

L’anello
Cassandra e ScyllaDB distribuiscono i dati su un anello di token: ogni riga finisce sul token che dà la sua chiave di partizione, e ogni nodo possiede i tratti che terminano nei suoi token (la colonna Token dice quanti ne ha). Quota dell’anello è la parte dell’anello coperta dai token di ogni nodo senza contare le repliche, la stessa che dà nodetool status per un keyspace con fattore di replica 1. Senza keyspace, nodetool dà la quota effettiva, che conta le copie: con tre nodi e fattore 3, il 100% di ciascuno. Si calcola solo con Murmur3Partitioner, il partitioner predefinito; con un altro la colonna resta vuota e la nota lo dice.

Stato
In ScyllaDB lo stato lo dice system.cluster_status. In Cassandra viene da system_views.gossip_info, che nasconde una trappola: un nodo che si spegne in modo ordinato si congeda e appare Fermo, ma uno che cade senza congedarsi resta NORMAL. Per questo si legge due volte, a pochi secondi di distanza, e se il suo heartbeat non è avanzato appare Fermo: nessun heartbeat. Un nodo che sta entrando, uscendo o spostandosi appare in transizione, con la parola del server. E un peer per cui il coordinatore non ha una riga di stato è Sconosciuto: di un nodo che non si è potuto vedere non si afferma che sia fermo. Ogni stato ha il suo simbolo e il suo nome, non solo un colore.

Aggiorna
Niente si rilegge da solo, perché ogni lettura aspetta quei secondi per misurare l’heartbeat: si rilegge con Aggiorna. Se una lettura fallisce e ce n’era una prima, resta quella precedente, con l’avviso che non è attuale.

La versione in ScyllaDB
I peer di ScyllaDB pubblicano una versione di compatibilità con Cassandra, non la loro: la colonna mostra quella del coordinatore, letta da system.versions, e una nota lo dice.

Cosa non c’è qui
La replica di Cassandra è l’anello stesso, e si vede in questa scheda: non c’è un monitor delle repliche a parte. Il Cluster legge soltanto: ciò che è compito di nodetool —riparare, ripulire, dismettere o spostare un nodo, gli snapshot—, di JMX o dell’API REST di ScyllaDB resta fuori.

Parole chiave: cassandra, scylladb, cluster, anello, nodo, token, coordinatore, gossip, heartbeat, nodetool, owns, data center, rack, versione dello schema

Ciò che il nodo connesso dice di sé —versione, cache, compattazioni, disco, latenze e impostazioni—, da dove viene in ogni prodotto e ciò che resta a nodetool.

Dove si trova: Workspace › Strumenti › Nodo

Si applica a: Cassandra ScyllaDB

Il Nodo mostra ciò che il nodo a cui è connessa la sessione dice di sé, letto dalle sue tabelle virtuali: system_views in Cassandra e le tabelle di system in ScyllaDB. Tutto è di quel nodo: ai peer non si chiede nulla, e in un cluster ogni nodo ha le sue cache, le sue compattazioni e il suo disco. Per vederne un altro, la sessione deve connettersi a quello.

In alto
Versione è quella del server: quella di system.local in Cassandra e quella di system.versions in ScyllaDB, che è la sua e non quella di compatibilità con Cassandra. Seguono una scheda per cache, con il suo tasso di successo, quante voci contiene e quanto occupa della sua capacità: in Cassandra le cache di chiavi, righe e contatori, da system_views.caches; in ScyllaDB la Cache delle righe, dal gruppo cache di system.runtime_info. Una cache con capacità 0 è disattivata nella configurazione del server —quella delle righe di Cassandra arriva così— e la scheda lo dice. Compattazioni in corso conta quelle in esecuzione ora: in Cassandra vengono da system_views.sstable_tasks, con il loro avanzamento; in ScyllaDB da system.compactions_in_progress, che non dà l’avanzamento ma dice quante SSTable entrano. Se ce ne sono, sotto compare la loro tabella.

Le sezioni
Sotto c’è una tabella per sezione, e ogni prodotto dichiara le sue: ciò che il server non pubblica non viene disegnato.
- Pool di thread (solo Cassandra, system_views.thread_pools): le attività attive, in attesa e bloccate di ogni pool. Quelle in attesa e quelle bloccate dicono se il nodo tiene il passo.
- Latenza per tabella (solo Cassandra, coordinator_read_latency e coordinator_write_latency): p50 e p99 di lettura e scrittura, in millisecondi. È la latenza che vede questo nodo come coordinatore delle richieste che riceve, non quella delle sue repliche.
- Dimensione per tabella: in Cassandra, lo spazio su disco di system_views.disk_usage, arrotondato per eccesso a MiB interi; in ScyllaDB, la stima di system.size_estimates sommata per tabella, che dà 0 a una tabella i cui dati non sono ancora stati scritti su disco e include le tabelle che ScyllaDB crea per gli indici e per le transazioni leggere (…$paxos), perché occupano davvero spazio.
- Partizioni grandi: in Cassandra, la partizione più grande di ogni tabella, da system_views.max_partition_size; in ScyllaDB, solo quelle che hanno superato la soglia del server durante la compattazione, da system.large_partitions, quindi vuota è la norma.
- Cronologia delle compattazioni: le 100 compattazioni più recenti di system.compaction_history, con ciò che hanno letto e scritto, e il totale accanto.
- Valori di funzionamento: i contatori che il server pubblica, con il loro nome: system_views.cql_metrics in Cassandra e system.runtime_info in ScyllaDB, che riporta anche da quanto tempo è attivo, come lo scrive il server.
- Impostazioni: la configurazione con cui gira il nodo, da system_views.settings in Cassandra e da system.config in ScyllaDB, che dice inoltre da dove viene ogni valore. Filtra impostazioni restringe l’elenco per nome.

Dimensione, partizioni e latenze lasciano fuori i keyspace del server; la cronologia no. Se una sezione non si può leggere, si dice quale e perché, e le altre continuano.

Aggiorna
Nulla si rilegge da solo: si rilegge con Aggiorna. Se una lettura fallisce e ce n’era una prima, resta visibile la precedente e si dice che non è quella attuale.

Ciò che non c’è qui
Il Nodo legge soltanto. Ciò che è compito di nodetool —svuotare le memtable, avviare o fermare una compattazione, cambiare il livello di log, ricostruire indici—, di JMX o dell’API REST di ScyllaDB resta fuori, e un’impostazione non si cambia da qui: si cambia nella configurazione del server.

Parole chiave: cassandra, scylladb, nodo, versione, cache, tasso di successo, compattazione, sstable, thread pool, latenza, disco, dimensione, partizione grande, impostazioni, configurazione, uptime, nodetool, jmx

Quali connessioni ha aperte il nodo connesso, con quale utente, driver, protocollo e TLS, quali sono di Calíope, e perché da qui non si disconnettono.

Dove si trova: Workspace › Strumenti › Client

Si applica a: Cassandra ScyllaDB

Client mostra le connessioni aperte sul nodo a cui è connessa la sessione, come le pubblica il nodo stesso: system_views.clients in Cassandra e system.clients in ScyllaDB. Solo quelle di quel nodo: ogni nodo pubblica le sue, e quelle che un client ha aperte con un altro nodo del cluster non compaiono qui. Per vederle, la sessione deve connettersi a quel nodo.

Le colonne
- Client: l’indirizzo e la porta da cui arriva la connessione, con il nome host sotto quando il server lo conosce e non è l’indirizzo stesso.
- Utente: l’utente con cui si è autenticata.
- Driver: il nome e la versione che il driver ha dichiarato connettendosi. cqlsh si presenta come «DataStax Python Driver» in Cassandra e come «ScyllaDB Python Driver» in ScyllaDB, e apre due connessioni: una di controllo e un’altra per le query.
- Protocollo: la versione del protocollo nativo che la connessione ha negoziato.
- TLS: se la connessione è cifrata e, quando il server lo dice, con quale versione di TLS.
- Fase: la fase della connessione, scritta come la scrive il server (ScyllaDB, in maiuscolo: READY).
- Richieste e Keyspace (solo Cassandra): quante richieste ha fatto la connessione e il keyspace in uso, che mostra un trattino se non ha eseguito USE.
- Shard (solo ScyllaDB): lo shard del nodo che serve la connessione.

Una colonna che un prodotto non pubblica non viene disegnata, e un valore che il server non dà mostra un trattino.

Calíope
Le connessioni di Calíope portano il loro segno —un glifo e il nome Calíope, non solo un colore— e vengono per prime; le altre seguono per indirizzo e porta. Calíope si presenta al server con il nome «Caliope», ed è così che si riconoscono: vengono segnate tutte quelle dell’app, quelle di questa finestra e quelle di qualsiasi altro dispositivo con Calíope aperto sullo stesso nodo, perché l’indirizzo non basta a sapere quale sia di questa finestra (dietro un tunnel o un NAT arrivano tutte dallo stesso).

Filtrare
Filtra per indirizzo, utente, driver… restringe la tabella per indirizzo, porta, nome host, utente, driver e sua versione, keyspace o fase, e il riepilogo dice quante del totale sono mostrate.

Aggiorna
L’elenco non si rilegge da solo: si rilegge con Aggiorna. Se una lettura fallisce e ce n’era una prima, resta visibile la precedente e si dice che non è quella attuale.

Ciò che non c’è qui
Client legge soltanto. Calíope non disconnette nessuno, perché CQL non ha alcuna istruzione per chiudere la connessione di un altro client, e il piè di pagina della scheda lo dice. Questo resta a nodetool, a JMX o all’API REST di ScyllaDB.

Parole chiave: cassandra, scylladb, client, connessioni, sessioni, utente, driver, protocollo, tls, keyspace, shard, cqlsh, calíope, nodetool

Come si legge una traccia di Cassandra o ScyllaDB, cosa pubblica in più ogni prodotto —le query lente di ScyllaDB, ciò che è in esecuzione ora in Cassandra— e come si attiva il registro delle query lente di ScyllaDB.

Dove si trova: Workspace › Strumenti › Tracce

Si applica a: Cassandra ScyllaDB

Tracce mostra ciò che il server annota delle richieste che gli si chiede di tracciare, e ciò che ogni prodotto pubblica in più: le query lente in ScyllaDB e ciò che è in esecuzione ora in Cassandra. Le schede dipendono dal prodotto, e quella che un prodotto non ha non viene disegnata.

Sessioni tracciate (entrambi)
Una traccia è ciò che il coordinatore e ogni replica hanno annotato mentre servivano una richiesta. Il server la conserva in system_traces.sessions (una riga per richiesta) e system_traces.events (una per passo). Si traccia solo ciò che si chiede: attiva Traccia nella Query CQL prima di eseguire, e il piè del risultato porta un pulsante con l’identificativo della traccia che la apre qui direttamente. Le tracce scadono dopo 24 ore.

L’elenco mostra le sessioni più recenti. In ScyllaDB si cercano tramite il suo indice temporale (sessions_time_idx), andando indietro dall’ora del server, e il totale non viene letto. Cassandra non ha quell’indice: la tabella si legge fino a un tetto e si ordina qui, e se la lettura ha raggiunto il tetto lo schermo lo dice, perché possono essercene di più recenti non lette. In ScyllaDB ogni query lenta scrive anche la sua sessione, quindi l’elenco contiene più di quelle che hai chiesto di tracciare.

L’ora di ogni riga (Inizio) apre la sua traccia: inizio, durata, comando, coordinatore, client, l’utente (lo annota solo ScyllaDB) e, quando il server lo annota, il livello di coerenza; l’istruzione, con Apri nella Query CQL; e gli eventi in ordine. Ogni evento indica Trascorso —i microsecondi che il suo nodo aveva già dedicato alla richiesta—, una barra proporzionale a quel tempo, l’attività, Nodo e il thread. Due nodi non condividono l’orologio: il tempo di ogni evento è quello del suo nodo, e confrontare due nodi con quella colonna inganna.

Il server scrive la traccia mentre la richiesta prosegue: una traccia appena richiesta può arrivare senza eventi o con la durata non terminata. All’apertura viene riletta alcune volte, a mezzo secondo di distanza, finché non porta la sua durata; se non arriva, lo si dice, e basta rileggerla con Aggiorna qualche secondo dopo. Torna alle sessioni tracciate torna all’elenco.

Lente (solo ScyllaDB)
ScyllaDB annota in system_traces.node_slow_log ogni query che supera una soglia, con inizio, durata, istruzione, tabelle, utente, e il nodo e lo shard che l’hanno servita. Si cercano tramite node_slow_log_time_idx, nelle ultime 24 ore. L’ora apre la traccia di quella query —ScyllaDB ne scrive una per ogni query lenta— e il pulsante in fondo alla riga la porta nella Query CQL.

Il registro è spento di serie, e né la soglia né se è acceso si leggono via CQL: appartengono all’API REST di ScyllaDB (porta 10000). Per questo la scheda mostra la voce più recente e la più breve tra quelle lette, che è tutto ciò che CQL lascia sapere. Per accenderlo con una soglia di 500 µs (la soglia è in microsecondi), e per leggerne lo stato:

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

Il secondo restituisce qualcosa come {"enable": true, "ttl": 86400, "threshold": 500, "fast": false}. Si accende nodo per nodo, non è in scylla.yaml, e un riavvio del nodo lo spegne. Calíope non lo fa al posto tuo perché parla solo CQL: l’API REST è la porta di amministrazione di ScyllaDB, separata da CQL e di solito irraggiungibile dall’esterno del cluster, e ciò che è mestiere di nodetool, di JMX o dell’API REST resta fuori.

In corso (solo Cassandra)
Ciò che è in esecuzione ora sul nodo della sessione, da system_views.queries: il thread, In coda e In esecuzione in microsecondi, e la richiesta. La lettura di questo elenco è una di esse, e ogni nodo pubblica solo le sue. Cassandra non pubblica le sue query lente via CQL: le annota nel suo registro di testo a partire da slow_query_log_timeout, che il piè di pagina indica così come lo ha il nodo.

Aggiorna
Niente si rilegge da solo: la scheda si rilegge con Aggiorna, e la barra dice a che ora è stata l’ultima lettura. Se una lettura fallisce e ce n’era una prima, resta visibile la precedente e si dice che non è quella attuale.

Tutto questo legge soltanto: le tracce e il registro delle query lente li scrive il server, e scadono da soli.

Parole chiave: cassandra, scylladb, tracce, traccia, tracing, sessioni, eventi, lente, query lente, registro delle query lente, system_traces, node_slow_log, system_views.queries, soglia, api rest, curl

Che cos’è un ruolo di Cassandra o ScyllaDB, da dove vengono l’elenco e la scheda, su quali risorse si concedono i permessi, che cosa si scrive e come viaggia la password, e perché senza autenticazione non ci sono ruoli.

Dove si trova: Workspace › Strumenti › Ruoli

Si applica a: Cassandra ScyllaDB

Ruoli mostra i ruoli del server e quello che ciascuno può fare, e permette di crearli, modificarli, concedere loro permessi ed eliminarli.

Che cos’è un ruolo
Un ruolo è insieme un utente e un gruppo. Se ha Può accedere e una password, qualcuno si collega con esso; altrimenti serve a raccogliere permessi e a essere concesso ad altri ruoli, che ereditano quello che ha. Un ruolo Superutente può fare tutto, anche se l’elenco non nomina ogni permesso, e la scheda lo dice.

Senza autenticazione non ci sono ruoli
I ruoli esistono solo quando il server chiede utente e password alla connessione (PasswordAuthenticator). Con AllowAllAuthenticator, quello con cui Cassandra e ScyllaDB vengono installati, chiunque entra senza credenziali e non c’è niente da amministrare: la scheda lo dice con il suo motivo e non chiede niente al server, che risponderebbe con un errore.

L’elenco e la scheda
L’elenco viene da LIST ROLES, uguale nei due prodotti: il nome, Superutente, Può accedere e, solo in Cassandra, Data center. Il filtro restringe per nome. Quando scegli un ruolo, la scheda mostra Permessi propri, da LIST ALL PERMISSIONS OF; a parte, Ereditati dai ruoli a cui appartiene, ciascuno con il ruolo da cui viene; e Appartiene a, da LIST ROLES OF. Quello che è ereditato non si revoca qui: si toglie sul ruolo da cui viene, o si toglie il ruolo da quel gruppo.

Risorse e permessi
Un permesso si concede su una risorsa: Tutti i keyspace, Un keyspace, Una tabella, Tutti i ruoli, Un ruolo o Tutte le funzioni. I permessi sono ALL PERMISSIONS, SELECT, MODIFY, CREATE, ALTER, DROP, AUTHORIZE, DESCRIBE ed EXECUTE; Cassandra aggiunge SELECT_MASKED e UNMASK, quelli delle colonne mascherate, che ScyllaDB non ha. Non ogni permesso vale per ogni risorsa, e il server rifiuta con il suo messaggio la coppia che non ha senso.

Che cosa si scrive
Nuovo ruolo… crea un ruolo con il suo nome, la sua password e se ha Può accedere o è Superutente; senza password il ruolo non può accedere anche con LOGIN. Modifica… invia solo quello che cambi (ALTER ROLE); Cassandra non lascia cambiare la password di un ruolo due volte in meno di 5 secondi. Concedi permesso… concede un permesso su una risorsa, e Aggiungi a un ruolo… l’appartenenza a un altro ruolo; il pulsante in fondo a ogni riga lo revoca. Elimina ruolo… elimina il ruolo con i suoi permessi e le sue appartenenze. Togliere qualcosa —eliminare o revocare— chiede prima una conferma che nomina il ruolo.

Tutto ciò che scrive passa per la protezione della connessione: con un’etichetta d’ambiente di sola lettura non si disegna niente che scriva, e con una che conferma ogni modifica chiede prima di essere inviata.

La password
CQL non lascia inviare la password a parte: viaggia dentro l’istruzione (CREATE ROLE … WITH PASSWORD = '…') fino al server, che la conserva come hash e non in chiaro. In rete è cifrata solo se la connessione usa TLS. In Registro dei comandi l’istruzione resta con la password coperta.

Aggiorna
Niente si rilegge da solo: l’elenco si rilegge con Aggiorna, e la barra dice a che ora è stata l’ultima lettura. Se una lettura fallisce e ce n’era una prima, resta quella precedente e ti si dice che non è quella di adesso.

Parole chiave: cassandra, scylladb, ruoli, ruolo, permessi, utenti, grant, revoke, create role, alter role, drop role, list roles, superutente, login, password, autenticazione, passwordauthenticator, allowallauthenticator

Che cos’è un report CQL: un solo SELECT con parametri :nome, preparato e legato secondo il tipo di ogni colonna, che legge tutte le pagine fino al tetto.

Dove si trova: Workspace › Strumenti › Report

Si applica a: Cassandra ScyllaDB

In una sessione Cassandra o ScyllaDB, Nuovo report crea un report CQL: il suo testo è una sola istruzione SELECT, e nasce con SELECT * FROM demo.productos LIMIT 100. Un’altra istruzione —un INSERT, un USE—, due istruzioni o un ? senza nome vengono rifiutati prima di mandare qualcosa al server.

Parametri
Un parametro si scrive :nome nel testo e si dichiara con Dichiara i parametri. Calíope cambia ogni :nome in ? e prepara l’istruzione: il server dice il tipo CQL di ogni segnaposto, e il valore si scrive secondo quel tipo, mai dentro il testo. Un uuid va come uuid e un decimal esatto, senza passare dalla virgola mobile; un valore che non va con la sua colonna viene rifiutato con il nome del parametro. Se il server conta un numero di segnaposto diverso da quello dei parametri, il report fallisce e dice i due numeri.

Cosa si legge
Ogni volta che premi Esegui, Calíope legge tutte le pagine del risultato, 200 alla volta, fino al tetto di righe del report, e dice se è stato tagliato. Ferma lo ferma tra una pagina e la successiva. I tipi delle colonne vengono da ciò che il server dichiara del risultato: interi, decimal, float e double come numeri, timestamp come data e ora in UTC, date come data, blob come binario e boolean; le collezioni, i tipi utente, uuid e inet escono come li scrive cqlsh.

Il resto
Ciò che legge un report non resta nel Registro dei comandi: è una lettura dello strumento, non un’istruzione della Query CQL. Esporta e Cronologia funzionano come in ogni report. Un report CQL si esegue solo in una sessione Cassandra o ScyllaDB, non accetta uno script di più istruzioni, e Pianifica non serve con esso: si pianificano solo i report su un database relazionale.

Parole chiave: cassandra, scylladb, cql, report, select, parametro, preparare, pagine, tetto, esportare, cronologia