Esta página describe Calíope 1.7, la versión que estoy construyendo ahora mismo. La 1.6 está en la App Store para Mac, iPad, iPhone, Apple Watch, Apple TV y Apple Vision Pro. El changelog dice en qué versión llegó cada función.
Añade un botón «Abrir en Calíope» a cada tema. Sólo funciona con la app instalada.
Cómo ejecutar CQL, qué nivel de consistencia elegir, cómo llegan las páginas y la traza, qué hace Detener y lo que CQL no tiene.
Dónde está: Espacio de Trabajo › Herramientas › Consulta CQL
Aplica a:CassandraScyllaDB
La Consulta CQL envía al servidor lo que escribes, por la sesión abierta. Ejecutar (⌘↩) corre todo el texto sentencia a sentencia, o sólo lo seleccionado si hay selección. Un BEGIN BATCH … APPLY BATCH va entero, y un ; dentro de un literal, de un bloque $$…$$ o de un comentario no corta. La primera sentencia que falla detiene las demás, y el error dice cuál («Sentencia 2: …»). Un USE cambia el keyspace de la sesión, y la barra lo dice.
El nivel de consistencia
Cada dato vive en varias réplicas, y el nivel de consistencia dice cuántas tienen que contestar antes de que el servidor responda. Se elige en Consistencia y vale para lo que se ejecute después:
- LOCAL_ONE, el de omisión, espera a una réplica del centro de datos local: es lo más rápido, y una lectura puede no ver todavía una escritura reciente.
- ONE, TWO y THREE esperan a ese número de réplicas, estén donde estén.
- QUORUM espera a la mayoría de las réplicas, LOCAL_QUORUM a la mayoría del centro de datos local y EACH_QUORUM a la mayoría de cada uno. Una escritura y una lectura en QUORUM siempre coinciden en alguna réplica.
- ALL espera a todas, y falla en cuanto una está caída.
- ANY sólo vale para escribir, y SERIAL y LOCAL_SERIAL son para las transacciones ligeras (IF NOT EXISTS, IF …).
Si no hay réplicas vivas suficientes, el servidor contesta con un error que dice cuántas hacían falta y cuántas había. Ver solución lleva al capítulo del Manual del DBA que explica el error: el de consistencia con eso o con un tiempo agotado, el de roles y permisos con un Unauthorized, y el de errores frecuentes con los demás que explica, también uno de sintaxis.
Las páginas
Un SELECT llega por páginas, y Filas por página dice cuántas filas pide cada una: 200 si no lo cambias. Siguiente página trae la siguiente mientras el servidor diga que puede haber más; a veces la última llega vacía, y entonces se dice: «No hay más filas.».
La traza
Con Trazar encendido, el servidor anota por dónde pasó cada sentencia, y el pie trae el enlace a su traza.
Lo que se ve
La rejilla escribe cada valor como cqlsh, y la cabecera de cada columna lleva su tipo. La vista JSON vuelve a ejecutar un SELECT como SELECT JSON y enseña lo que devuelve el servidor; para otra sentencia no hay JSON. Los avisos del servidor salen en una franja, «Avisos del servidor»: Cassandra avisa, por ejemplo, de un count(*) sin clave de partición, y ScyllaDB no. El pie dice las filas, el tiempo y cuántas sentencias corrieron.
Lo que escribe INSERT, UPDATE, DELETE, TRUNCATE, CREATE, ALTER, DROP, GRANT, REVOKE y un BATCH pasan antes por el guarda de la etiqueta de entorno de la sesión, que puede pedir confirmación. Una escritura dice «Aplicado. CQL no dice cuántas filas escribió.»: el protocolo no devuelve cuántas filas tocó.
Detener
Mientras corre, Detener (⌘.) deja de esperar la respuesta, y la conexión sigue abierta. Pero el protocolo no tiene forma de cancelar en el servidor: lo que ya empezó, el servidor lo termina. Un UPDATE detenido puede haberse aplicado.
Lo que CQL no tiene
No hay EXPLAIN ni transacciones de varias sentencias: un BATCH registrado se aplica entero o no se aplica, pero no aísla a quien lee mientras tanto, y la traza es lo más parecido a un plan. Una consulta que no filtra por la clave de partición la rechaza el servidor salvo que lleve ALLOW FILTERING, que lo obliga a leer todas las particiones: en una tabla grande es caro, y casi siempre la respuesta es otra tabla con otra clave.
El árbol del esquema, de dónde sale el DDL, la muestra de filas y qué se edita por clave primaria y qué no.
Dónde está: Espacio de Trabajo › Herramientas › Keyspaces
Aplica a:CassandraScyllaDB
El Explorador lee system_schema y enseña cada keyspace con sus tablas, vistas materializadas, tipos, índices, funciones y agregados. Un keyspace se lee al desplegarlo o elegirlo, no todos de golpe, y una categoría vacía no se dibuja. Filtrar por nombre filtra el árbol por nombre. Los keyspaces que son del propio servidor (system*, y audit en ScyllaDB) van al final, plegados, bajo «Keyspaces del servidor».
La clave de partición
En Cassandra la clave primaria tiene dos partes. La clave de partición decide en qué nodos vive cada fila: las filas con la misma clave de partición viven juntas, y una consulta eficiente la da entera. Las columnas de agrupamiento ordenan las filas dentro de la partición, en el orden que declara la tabla (ASC o DESC). El resto son columnas regulares, y una estática guarda un valor por partición, no por fila. Estructura enseña cada columna con su papel, su posición y su orden, la clave primaria completa y las propiedades de la tabla.
DDL
El DDL lo escribe el servidor: se le pide con DESCRIBE, que Cassandra y ScyllaDB aceptan para keyspace, tabla, vista, tipo, índice, función y agregado, y el panel dice que salió de ahí. El de una tabla trae detrás sus índices y sus vistas. Si un servidor no acepta DESCRIBE, el DDL se reconstruye de system_schema y el panel también lo dice; funciones y agregados no se reconstruyen. Copiar DDL lo copia entero.
Filas
La muestra lee 100 filas por página, sin WHERE ni ALLOW FILTERING, en el orden en que el servidor recorre las particiones, que no es el de inserción. Siguiente página trae la siguiente y Recargar filas vuelve a empezar. Mostrar el token de la partición añade la columna token(), el número que decide en qué nodo cae cada partición, y Hora de escritura y TTL de añade writetime y ttl de una columna regular: cuándo se escribió el valor, en microsegundos, y cuántos segundos le quedan antes de caducar. No vale para una columna de la clave, un contador ni una colección sin congelar.
Editar filas Insertar fila…, encima de la rejilla, y en cada fila el menú «…» con Editar fila… y Borrar fila… escriben siempre por la clave entera, partición y agrupamiento, y con transacción ligera: insertar es INSERT … IF NOT EXISTS, así que una clave que ya existe no se sustituye; guardar es UPDATE … IF EXISTS y borrar es DELETE … IF EXISTS, y si la fila ya no está en el servidor se dice. Al guardar sólo se escribe lo que cambió, y Sin valor (null) borra la celda. Lo tecleado se convierte al tipo que declara el servidor antes de enviar nada: fechas y horas en UTC (2026-01-31 10:00:00), un blob en hexadecimal (0x…), una duración como 1h30m y un decimal con punto o con coma. Tras escribir, la fila se relee y cambia en su sitio, sin recargar la página. La alerta de borrar nombra la clave entera.
ScyllaDB
En ScyllaDB 2025.1, un keyspace con tablets no admite transacciones ligeras, y guardar falla con el mensaje del servidor («LWT is not yet supported with tablets»). Un keyspace creado con AND tablets = {'enabled': false} se edita como en las demás versiones.
Lo que no se edita aquí
Una colección, una UDT, una tupla, un tipo custom y una columna estática se cambian en la Consulta CQL, y la hoja lo dice. Tampoco se editan una tabla de contadores, que sólo admite sumar o restar, un keyspace del servidor ni una tabla cuya clave lleve un tipo que no se escribe en una línea. No hay TRUNCATE ni borrado por filtro: para eso está la Consulta CQL. Con una etiqueta de entorno de «solo lectura» no se dibuja nada de lo que escribe, y con una que «confirma lo que escribe», el guarda pregunta antes de cada escritura.
Qué nodos enseña y de dónde salen, qué es la parte del anillo, cómo se sabe que un nodo está abajo y lo que queda para nodetool.
Dónde está: Espacio de Trabajo › Herramientas › Clúster
Aplica a:CassandraScyllaDB
El Clúster enseña los nodos que conoce el nodo al que está conectada la sesión, el coordinador: su propia fila de system.local y las de sus pares, de system.peers_v2 en Cassandra (o system.peers si no la tiene) y de system.peers en ScyllaDB. A los pares no se les pregunta nada: lo que se ve es lo que el coordinador sabe de ellos. Arriba van el nombre del clúster, el particionador, cuántos nodos están arriba —con los que no lo están nombrados uno a uno— y si todos publican la misma versión de esquema; si no coinciden, un cambio de esquema todavía no ha llegado a todos.
El anillo
Cassandra y ScyllaDB reparten los datos en un anillo de tokens: cada fila cae en el token que sale de su clave de partición, y cada nodo es dueño de los tramos que acaban en sus tokens (la columna Tokens dice cuántos tiene). Parte del anillo es la parte del anillo que cubren los tokens de cada nodo sin contar réplicas, la misma que da nodetool status para un keyspace con factor de replicación 1. Sin keyspace, nodetool da la parte efectiva, que cuenta las copias: con tres nodos y factor 3, el 100 % de cada uno. Sólo se calcula con Murmur3Partitioner, el particionador por omisión; con otro, la columna queda en blanco y la nota lo dice.
Estado
En ScyllaDB el estado lo dice system.cluster_status. En Cassandra sale de system_views.gossip_info, que tiene una trampa: un nodo que se apaga con orden se despide y sale Abajo, pero uno que se cae sin despedirse sigue como NORMAL. Por eso se lee dos veces, unos segundos aparte, y si su latido (heartbeat) no avanzó sale Abajo: sin latido. Un nodo que está entrando, saliendo o moviéndose sale en tránsito, con la palabra del servidor. Y un par del que el coordinador no tiene fila de estado sale Desconocido: de un nodo que no se pudo ver no se afirma que esté abajo. Cada estado lleva su símbolo y su nombre, no sólo un color.
Actualizar
Nada se relee solo, porque cada lectura espera esos segundos para medir el latido: se vuelve a leer con Actualizar. Si una lectura falla y había otra antes, se enseña la anterior y se dice que no es la de ahora.
La versión en ScyllaDB
Los pares de ScyllaDB publican una versión de compatibilidad con Cassandra, no la suya: la columna enseña la del coordinador, leída de system.versions, y una nota lo dice.
Lo que no está aquí
La replicación de Cassandra es la del anillo, y se ve en esta pestaña: no hay un monitor de réplicas aparte. El Clúster sólo lee: lo que es oficio de nodetool —reparar, limpiar, sacar o mover un nodo, las instantáneas—, de JMX o de la API REST de ScyllaDB queda fuera.
Palabras clave: cassandra, scylladb, clúster, anillo, nodo, token, coordinador, gossip, heartbeat, latido, nodetool, owns, centro de datos, rack, versión de esquema
Lo que el nodo conectado dice de sí mismo —versión, cachés, compactaciones, disco, latencias y ajustes—, de dónde sale en cada producto y lo que queda para nodetool.
Dónde está: Espacio de Trabajo › Herramientas › Nodo
Aplica a:CassandraScyllaDB
El Nodo enseña lo que el nodo al que está conectada la sesión dice de sí mismo, leído de sus tablas virtuales: system_views en Cassandra y las tablas de system en ScyllaDB. Todo es de ese nodo: a los pares no se les pregunta nada, y en un clúster cada nodo tiene sus propias cachés, sus compactaciones y su disco. Para ver otro, la sesión tiene que conectarse a él.
Arriba Versión es la del servidor: la de system.local en Cassandra y la de system.versions en ScyllaDB, que es la suya y no la de compatibilidad con Cassandra. Detrás va una tarjeta por caché, con su tasa de aciertos, cuántas entradas tiene y cuánto ocupa de su capacidad: en Cassandra las de claves, filas y contadores, de system_views.caches; en ScyllaDB la Caché de filas, del grupo cache de system.runtime_info. Una caché con capacidad 0 está apagada en la configuración del servidor —la de filas de Cassandra viene así— y la tarjeta lo dice. Compactaciones en curso cuenta las que corren ahora: en Cassandra salen de system_views.sstable_tasks, con su avance; en ScyllaDB, de system.compactions_in_progress, que no da avance pero sí cuántas SSTables entran. Si hay alguna, debajo sale su tabla.
Las secciones
Debajo va una tabla por sección, y cada producto declara las suyas: lo que el servidor no publica no se dibuja.
- Grupos de hilos (sólo Cassandra, system_views.thread_pools): las tareas activas, pendientes y bloqueadas de cada grupo. Las pendientes y las bloqueadas son las que dicen si el nodo no da abasto.
- Latencia por tabla (sólo Cassandra, coordinator_read_latency y coordinator_write_latency): p50 y p99 de lectura y escritura, en milisegundos. Es la latencia que ve este nodo como coordinador de las peticiones que recibe, no la de sus réplicas.
- Tamaño por tabla: en Cassandra, el espacio en disco de system_views.disk_usage, redondeado hacia arriba a MiB enteros; en ScyllaDB, la estimación de system.size_estimates sumada por tabla, que da 0 a una tabla cuyos datos todavía no se han escrito a disco e incluye las tablas que ScyllaDB crea para los índices y para las transacciones ligeras (…$paxos), porque ocupan de verdad.
- Particiones grandes: en Cassandra, la partición más grande de cada tabla, de system_views.max_partition_size; en ScyllaDB, sólo las que pasaron el umbral del servidor al compactarse, de system.large_partitions, así que vacía es lo normal.
- Historial de compactaciones: las 100 compactaciones más recientes de system.compaction_history, con lo que leyeron y escribieron, y el total al lado.
- Cifras de funcionamiento: los contadores que el servidor publica, con su nombre: system_views.cql_metrics en Cassandra y system.runtime_info en ScyllaDB, que trae también el tiempo que lleva arriba, escrito por el servidor.
- Ajustes: la configuración con la que corre el nodo, de system_views.settings en Cassandra y de system.config en ScyllaDB, que dice además de dónde sale cada valor. Filtrar ajustes acota la lista por nombre.
Tamaño, particiones y latencias dejan fuera los keyspaces del servidor; el historial no. Si una sección no se puede leer, se dice cuál y por qué, y las demás siguen.
Actualizar
Nada se relee solo: se vuelve a leer con Actualizar. Si una lectura falla y había otra antes, se enseña la anterior y se dice que no es la de ahora.
Lo que no está aquí
El Nodo sólo lee. Lo que es oficio de nodetool —volcar las memtables, lanzar o detener una compactación, cambiar el nivel de registro, reconstruir índices—, de JMX o de la API REST de ScyllaDB queda fuera, y un ajuste no se cambia desde aquí: se cambia en la configuración del servidor.
Qué conexiones tiene abiertas el nodo conectado, con qué usuario, driver, protocolo y TLS, cuáles son de Calíope, y por qué no se desconectan desde aquí.
Dónde está: Espacio de Trabajo › Herramientas › Clientes
Aplica a:CassandraScyllaDB
Clientes enseña las conexiones abiertas en el nodo al que está conectada la sesión, tal como las publica él mismo: system_views.clients en Cassandra y system.clients en ScyllaDB. Sólo las de ese nodo: cada nodo publica las suyas, y las que un cliente tenga abiertas con otro nodo del clúster no salen aquí. Para verlas, la sesión tiene que conectarse a ese nodo.
Las columnas
- Cliente: la dirección y el puerto desde los que llega la conexión, con el nombre del equipo debajo cuando el servidor lo conoce y no es la propia dirección.
- Usuario: el usuario con el que se autenticó.
- Driver: el nombre y la versión que el driver declaró al conectar. cqlsh se presenta como «DataStax Python Driver» en Cassandra y como «ScyllaDB Python Driver» en ScyllaDB, y abre dos conexiones: una de control y otra para las consultas.
- Protocolo: la versión del protocolo nativo que negoció la conexión.
- TLS: si la conexión va cifrada y, cuando el servidor lo dice, con qué versión de TLS.
- Estado: la etapa de la conexión, escrita como la escribe el servidor (ScyllaDB, en mayúsculas: READY).
- Peticiones y Keyspace (sólo Cassandra): cuántas peticiones lleva la conexión y el keyspace en uso, que sale con una raya si no hizo USE.
- Shard (sólo ScyllaDB): el shard del nodo que atiende la conexión.
La columna que un producto no publica no se dibuja, y un valor que el servidor no da sale con una raya.
Calíope
Las conexiones de Calíope llevan su marca —un glifo y el nombre Calíope, no sólo un color— y van delante; las demás, por dirección y puerto. Calíope se presenta al servidor con el nombre «Caliope», y así se reconocen: se marcan todas las de la app, las de esta ventana y las de cualquier otro aparato con Calíope abierto contra el mismo nodo, porque la dirección no basta para saber cuál es de esta ventana (detrás de un túnel o de un NAT, todas llegan desde la misma).
Filtrar Filtrar por dirección, usuario, driver… acota la tabla por dirección, puerto, nombre del equipo, usuario, driver y su versión, keyspace o etapa, y el resumen dice cuántas de todas se ven.
Actualizar
La lista no se relee sola: se vuelve a leer con Actualizar. Si una lectura falla y había otra antes, se enseña la anterior y se dice que no es la de ahora.
Lo que no está aquí
Clientes sólo lee. Calíope no desconecta a nadie, porque CQL no tiene ninguna sentencia para cerrar la conexión de otro cliente, y el pie de la pestaña lo dice. Eso queda para nodetool, JMX o la API REST de ScyllaDB.
Cómo se lee una traza de Cassandra o ScyllaDB, qué publica además cada producto —las consultas lentas de ScyllaDB, lo que corre ahora en Cassandra— y cómo se enciende el registro de lentas de ScyllaDB.
Dónde está: Espacio de Trabajo › Herramientas › Trazas
Aplica a:CassandraScyllaDB
Trazas enseña lo que el servidor anota de las peticiones que se le piden trazar, y lo que cada producto publica además: las consultas lentas en ScyllaDB y lo que corre ahora en Cassandra. Las pestañas dependen del producto, y la que un producto no tiene no se dibuja.
Sesiones trazadas (los dos)
Una traza es lo que el coordinador y cada réplica anotaron mientras atendían una petición. El servidor la guarda en system_traces.sessions (una fila por petición) y system_traces.events (una por paso). Sólo se traza lo que se pide: activa Trazar en la Consulta CQL antes de ejecutar, y el pie del resultado trae un botón con el identificador de la traza que la abre aquí directamente. Las trazas caducan a las 24 horas.
La lista enseña las sesiones más recientes. En ScyllaDB se buscan por su índice por tiempo (sessions_time_idx), hacia atrás desde la hora del servidor, y el total no se lee. Cassandra no tiene ese índice: la tabla se lee hasta un techo y se ordena aquí, y si la lectura llegó al techo la pantalla lo dice, porque puede haber otras más recientes que no se leyeron. En ScyllaDB cada consulta lenta escribe también su sesión, así que la lista trae más que las que pediste trazar.
La hora de cada fila (Inicio) abre su traza: inicio, duración, comando, coordinador, cliente, el usuario (sólo ScyllaDB lo anota) y, si el servidor lo anota, el nivel de consistencia; la sentencia, con Abrir en la Consulta CQL; y los eventos en orden. Cada evento dice Transcurrido —los microsegundos que su nodo llevaba con la petición—, una barra proporcional a ese tiempo, la actividad, Nodo y el hilo. Dos nodos no comparten reloj: el tiempo de cada evento es el de su nodo, y comparar dos nodos por esa columna engaña.
El servidor escribe la traza mientras la petición sigue: una traza recién pedida puede llegar sin eventos o con la duración sin terminar. Al abrirla se vuelve a leer unas cuantas veces, medio segundo aparte, hasta que trae su duración; si no llega, se dice, y basta volver a leerla con Actualizar unos segundos después. Volver a las sesiones trazadas regresa a la lista.
Lentas (sólo ScyllaDB)
ScyllaDB anota en system_traces.node_slow_log cada consulta que pasa de un umbral, con su inicio, duración, sentencia, tablas, usuario, y el nodo y el shard que la atendieron. Se buscan por node_slow_log_time_idx, de las últimas 24 horas. La hora abre la traza de esa consulta —ScyllaDB escribe una por cada lenta— y el botón del final de la fila la lleva a la Consulta CQL.
El registro viene apagado, y ni el umbral ni si está encendido se leen por CQL: son de la API REST de ScyllaDB (puerto 10000). Por eso la pestaña enseña la entrada más reciente y la más corta de las leídas, que es lo único que CQL deja saber. Para encenderlo con un umbral de 500 µs (el umbral va en microsegundos), y para leer cómo está:
curl -X POST "http://<nodo>:10000/storage_service/slow_query?enable=true&threshold=500"
curl http://<nodo>:10000/storage_service/slow_query
La segunda devuelve algo como {"enable": true, "ttl": 86400, "threshold": 500, "fast": false}. Se enciende nodo a nodo, no está en scylla.yaml y un reinicio del nodo lo apaga. Calíope no lo hace por ti porque sólo habla CQL: la API REST es la puerta de administración de ScyllaDB, aparte de CQL y por lo general inalcanzable desde fuera del clúster, y lo que es oficio de nodetool, de JMX o de la REST queda fuera.
En curso (sólo Cassandra)
Lo que corre ahora en el nodo de la sesión, de system_views.queries: el hilo, En cola y Corriendo en microsegundos, y la petición. La lectura de esta lista es una de ellas, y cada nodo publica sólo las suyas. Cassandra no publica sus consultas lentas por CQL: las anota en su registro de texto a partir de slow_query_log_timeout, que el pie dice tal como lo tiene el nodo.
Actualizar
Nada se relee solo: la pestaña se vuelve a leer con Actualizar, y la barra dice a qué hora fue la última lectura. Si una lectura falla y había otra antes, se enseña la anterior y se dice que no es la de ahora.
Todo esto sólo lee: las trazas y el registro de lentas los escribe el servidor, y caducan solos.
Palabras clave: cassandra, scylladb, trazas, traza, tracing, sesiones, eventos, lentas, consultas lentas, registro de lentas, system_traces, node_slow_log, system_views.queries, umbral, api rest, curl
Qué es un rol de Cassandra o ScyllaDB, de dónde salen la lista y la ficha, sobre qué recursos se conceden los permisos, qué se escribe y cómo viaja la contraseña, y por qué sin autenticación no hay roles.
Dónde está: Espacio de Trabajo › Herramientas › Roles
Aplica a:CassandraScyllaDB
Roles enseña los roles del servidor y lo que cada uno puede hacer, y deja crearlos, cambiarlos, concederles permisos y borrarlos.
Qué es un rol
Un rol es a la vez un usuario y un grupo. Si Puede entrar y tiene contraseña, alguien se conecta con él; si no, sirve para juntar permisos y concedérselo a otros roles, que heredan lo que tiene. Un rol Superusuario puede hacerlo todo, aunque la lista no nombre cada permiso, y la ficha lo dice.
Sin autenticación no hay roles
Los roles existen sólo cuando el servidor pide usuario y contraseña al conectar (PasswordAuthenticator). Con AllowAllAuthenticator, que es lo que traen Cassandra y ScyllaDB recién instalados, cualquiera entra sin credenciales y no hay nada que administrar: la pestaña lo dice con su motivo y no le pregunta nada al servidor, que contestaría con un error.
La lista y la ficha
La lista sale de LIST ROLES, igual en los dos productos: el nombre, Superusuario, Puede entrar y, sólo en Cassandra, Centros de datos. El filtro acota por nombre. Al elegir un rol, la ficha enseña Permisos propios, de LIST ALL PERMISSIONS OF; aparte, Heredados de los roles a los que pertenece, cada uno con el rol del que viene; y Pertenece a, de LIST ROLES OF. Lo heredado no se revoca aquí: se quita en el rol del que viene, o se saca el rol de ese grupo.
Recursos y permisos
Un permiso se concede sobre un recurso: Todos los keyspaces, Un keyspace, Una tabla, Todos los roles, Un rol o Todas las funciones. Los permisos son ALL PERMISSIONS, SELECT, MODIFY, CREATE, ALTER, DROP, AUTHORIZE, DESCRIBE y EXECUTE; Cassandra suma SELECT_MASKED y UNMASK, los de las columnas enmascaradas, que ScyllaDB no tiene. No todo permiso vale para todo recurso, y el servidor rechaza la pareja que no tiene sentido con su mensaje.
Lo que se escribe Nuevo rol… crea un rol con su nombre, su contraseña y si Puede entrar o es Superusuario; sin contraseña el rol no puede entrar aunque tenga LOGIN. Cambiar… manda sólo lo que cambias (ALTER ROLE); Cassandra no deja cambiar la contraseña de un rol dos veces en menos de 5 segundos. Conceder permiso… concede un permiso sobre un recurso, y Añadir a un rol…, la pertenencia a otro rol; el botón del final de cada fila lo revoca. Borrar rol… borra el rol con sus permisos y sus pertenencias. Quitar algo —borrar o revocar— pide antes una confirmación que nombra el rol.
Todo lo que escribe pasa por la protección de la conexión: con una etiqueta de entorno de solo lectura no se dibuja nada que escriba, y con una que confirma, cada cambio pregunta antes de mandarse.
La contraseña
CQL no deja mandar la contraseña aparte: viaja dentro de la sentencia (CREATE ROLE … WITH PASSWORD = '…') hasta el servidor, que la guarda como hash y no en claro. Por la red va cifrada sólo si la conexión usa TLS. En Registro de comandos la sentencia queda con la contraseña tapada.
Actualizar
Nada se relee solo: la lista se vuelve a leer con Actualizar, y la barra dice a qué hora fue la última lectura. Si una lectura falla y había otra antes, se enseña la anterior y se dice que no es la de ahora.
Palabras clave: cassandra, scylladb, roles, rol, permisos, usuarios, grant, revoke, create role, alter role, drop role, list roles, superusuario, login, contraseña, autenticación, passwordauthenticator, allowallauthenticator
Qué es un reporte CQL: un solo SELECT con parámetros :nombre, preparado y atado por el tipo de cada columna, que lee todas las páginas hasta el techo.
Dónde está: Espacio de Trabajo › Herramientas › Reportes
Aplica a:CassandraScyllaDB
En una sesión Cassandra o ScyllaDB, Nuevo reporte crea un reporte CQL: su texto es una sola sentencia SELECT, y nace con SELECT * FROM demo.productos LIMIT 100. Otra sentencia —un INSERT, un USE—, dos sentencias o un ? sin nombre se rechazan antes de mandar nada al servidor.
Parámetros
Un parámetro se escribe :nombre en el texto y se declara con Declarar parámetros. Calíope cambia cada :nombre por ? y prepara la sentencia: el servidor dice el tipo CQL de cada marcador, y el valor se escribe por ese tipo, nunca dentro del texto. Un uuid va como uuid y un decimal exacto, sin pasar por coma flotante; un valor que no casa con su columna se rechaza con el nombre del parámetro. Si el servidor cuenta otro número de marcadores que el de parámetros, el reporte falla y dice los dos números.
Lo que se lee
Cada vez que pulsas Ejecutar, Calíope lee todas las páginas del resultado, de 200 en 200, hasta el techo de filas del reporte, y si se recortó lo dice. Detener lo para entre una página y la siguiente. Los tipos de las columnas salen de lo que el servidor declara del resultado: enteros, decimal, float y double como números, timestamp como fecha y hora en UTC, date como fecha, blob como binario y boolean; las colecciones, los tipos de usuario, uuid e inet salen como los escribe cqlsh.
Lo demás
Lo que lee un reporte no queda en el Registro de comandos: es una lectura de la herramienta, no una sentencia de la Consulta CQL. Exportar y Historial funcionan como en cualquier reporte. Un reporte CQL sólo se ejecuta en una sesión Cassandra o ScyllaDB, no admite un guion de varias sentencias y Programar no sirve con él: sólo se programan reportes de una base relacional.