Esta página describe Calíope 1.6, la versión que estoy construyendo ahora mismo. La 1.5 ya 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 recorrer, leer y editar las claves de un servidor Redis.
Dónde está: Espacio de Trabajo › Herramientas › Claves
Aplica a:Redis
El explorador enseña a la izquierda las claves de la base, agrupadas por prefijo, y a la derecha el detalle de la que elijas.
Cómo se recorren las claves
Calíope las pide con SCAN, por tandas, y nunca con KEYS: KEYS recorre la base entera de un tirón y, como Redis atiende las órdenes de una en una, mientras dura no contesta a nadie más. El pie dice cuántas claves se han recorrido y si el recorrido terminó o quedan claves por recorrer; Cargar más claves pide la tanda siguiente. En un clúster se recorre cada nodo primario y el pie dice cuántos respondieron; si falta uno, lo nombra con su motivo.
El campo de arriba es un patrón de MATCH —app:*, *:1001—, no una búsqueda por contenido, y lo aplica el servidor en cuanto dejas de escribir.
Los grupos los hace Calíope, no el servidor
Redis no tiene carpetas: cada clave es un nombre plano. Los grupos salen de partir los nombres por el carácter del menú Separador de la barra (:, /, ., | o Ninguno: lista plana), y el servidor no sabe nada de ellos. El separador se elige para cada sesión, y cada grupo dice cuántas claves cuelgan de él. Con el teclado, las flechas recorren la lista y → y ← abren y cierran el grupo elegido; en el iPhone, tocar una clave abre su detalle.
Tipo y caducidad
Cada clave lleva su tipo, con su glifo y su nombre, y su caducidad, que en el detalle cuenta hacia atrás. Sin caducidad y Ya no existe no son lo mismo: la primera es una clave que dura hasta que alguien la borre; la segunda, una que caducó, o que borró otro cliente, después de recorrerla.
El detalle
Debajo de la clave, el tipo y la caducidad van el tamaño —Longitud en bytes, Campos o Elementos—, la Codificación interna y la Memoria, y después el Valor. El tamaño se pregunta antes que el contenido: un valor grande se lee por trozos, y un botón carga el siguiente. En una lista cada elemento lleva su Índice, porque en Redis la posición es parte del dato; un conjunto avisa de que no tiene orden; un conjunto ordenado enseña cada Miembro junto a su Puntuación, de menor a mayor; y un stream enseña primero sus datos —primera y última entrada, último id generado, mayor id borrado—, después sus grupos de consumidores con los pendientes y el retraso, y al final sus Entradas. Un valor que no es UTF-8 se enseña en hexadecimal, y los caracteres de control, escapados.
Qué se puede editar
Sobre la clave elegida, en la barra y en el menú contextual de la lista: Caducidad… (o Quitar la caducidad, si la clave caduca); Renombrar…, que avisa si el nombre ya existe y sólo pisa la otra clave con Sustituir; y Borrar clave…, que pregunta siempre y nombra la clave, su tipo y su tamaño. A esa misma pregunta llevan la tecla de borrar y, en el iPhone y el iPad, deslizar la fila hacia la izquierda.
En el valor: Editar el valor… en un string, que conserva su caducidad; Añadir campo…, Editar… y Quitar en un hash; Editar… de una posición en una lista; Añadir miembro… y Quitar en un conjunto; y Añadir miembro…, Editar… —que cambia la puntuación— y Quitar en un conjunto ordenado. Quitar el último elemento avisa de que Redis borra la clave cuando se queda vacía. Cada cambio se ve en su sitio, sin recargar la lista, y queda en el registro de lo que Calíope ejecutó.
No se edita un valor binario, ni uno de más de 64 KiB, ni un stream. Y no hay vaciado de la base ni borrado por patrón: se borra una clave cada vez, sabiendo cuál.
Perfiles abiertos con Calíope 1.4
Un perfil de Redis sincronizado con un aparato que todavía tiene Calíope 1.4 se lee allí como MariaDB en el mismo puerto, porque esa versión no conoce Redis; si lo guardas desde ese aparato, se reescribe así en todos los tuyos. Se recupera eligiendo Redis otra vez en el perfil: el servidor y la contraseña no se pierden.
Qué enseña el panel del servidor Redis y cómo leer cada cifra.
Dónde está: Espacio de Trabajo › Herramientas › Servidor
Aplica a:Redis
El panel enseña el estado del servidor Redis tal como lo publica INFO. Se relee solo cada 2 segundos mientras está a la vista, y Actualizar lo relee en el acto. Debajo de cada cifra va el campo de INFO del que sale, para que puedas contrastarla con redis-cli.
Las seis tarjetas Memoria usada es used_memory, con el límite (maxmemory) y el porcentaje, o sin límite si maxmemory vale 0; debajo, qué hace el servidor al llenarse y el pico.
Fragmentación es la memoria que el proceso ocupa en el sistema dividida entre la que usa. Por encima de 1, el proceso ocupa más de lo que usa: huecos que el asignador de memoria aún no ha devuelto. Por debajo de 1 suele significar que parte de los datos está en el disco de intercambio, y eso es peor.
Tasa de aciertos y Claves caducadas son acumuladas desde el arranque del servidor, no desde la última lectura: una tasa que apenas se mueve no dice que ahora no haya fallos. Las caducadas llevan debajo las claves expulsadas por falta de memoria.
Clientes conectados se mide contra maxclients, que no sale si el servidor no deja usar CONFIG. Si lo contrastas con redis-cli, allí sale uno más: el propio redis-cli.
Operaciones por segundo las calcula el servidor (instantaneous_ops_per_sec), no Calíope, y cambian de un instante a otro.
Cuando la memoria o los clientes pasan del 90 % de su límite, la tarjeta dice Cerca del límite, con un glifo además del color.
Persistencia
Dice si AOF está encendido, qué guardados RDB hay programados (save), cuándo fue el último guardado —con fecha, hora y zona— y cuántos cambios lleva sin guardar; un guardado que falló sale como tal, con su glifo. Si AOF está apagado y no hay guardados programados, la tarjeta sólo dice eso, porque el servidor pierde todos sus datos si se reinicia. Si está cargando su volcado del disco, lo dice primero: hasta que acabe, las cifras no son las del servidor en marcha.
Pub/sub
Una foto tomada en cada lectura, no un flujo: Calíope no se suscribe a ningún canal ni enseña mensajes. Lista los canales que tienen suscriptores ahora, con cuántos, y las suscripciones por patrón. Si el servidor no deja usar PUBSUB a la conexión, la tarjeta lo dice.
Servidor
El pie da la versión, el modo, el rol, el protocolo (RESP2 o RESP3) y el tiempo encendido. En un clúster el panel es de un solo nodo, y el pie lo nombra.
Qué mide el analizador de memoria, lo que le cuesta al servidor y por qué su suma no cuadra con used_memory.
Dónde está: Espacio de Trabajo › Herramientas › Memoria
Aplica a:Redis
Analizar recorre las claves de la base con SCAN, mide cada una con MEMORY USAGE y suma lo medido por prefijo, partiendo los nombres por el mismo separador que el explorador (: si no elegiste otro). El servidor no conoce esos grupos: los hace Calíope.
Lo que cuesta
Medir es una lectura por clave, y en una base grande eso es carga real para un servidor que atiende las órdenes de una en una. Por eso el recorrido va por páginas, tiene techo y se puede parar. El techo se elige antes de analizar, en el menú del techo que hay junto a Analizar: de 10.000 a 5.000.000 claves, y 500.000 si no lo cambias. Mientras corre, el botón pasa a ser Detener, que también está en el panel de Actividad, y cerrar la pestaña o la sesión lo detiene. Hasta que termina se sigue viendo el análisis anterior. En un clúster recorre cada primario y suma.
Una estimación, no una cuenta exacta
Un string se mide exacto. Una lista, un hash, un conjunto, un conjunto ordenado o un stream se miden por muestreo: el servidor mira cinco elementos y estima el resto (SAMPLES 5). Si el análisis se paró en el techo o lo detuviste, la pantalla avisa de que es una muestra, con un glifo además del texto.
La rejilla Prefijo, Memoria, Claves y Parte: la parte es de lo medido, no de la base. El menú del orden, a su lado, ordena por memoria o por claves, de mayor a menor; en el Mac y en el iPad ancho también se ordena pulsando la cabecera de la columna. Los grupos se abren con el chevron, o con → y ← del teclado. Arriba, la cifra dice siempre de qué es —cuánto ocupan las claves medidas— y, debajo, si son todas las de la base (DBSIZE).
Por qué la suma no cuadra con used_memory
La suma de las claves es siempre menor que la memoria que el servidor dice usar (used_memory), y no es un error de medida. used_memory cuenta también lo que el servidor ocupa por sí mismo —uno vacío ya usa cerca de 1 MB (used_memory_startup)—, los búferes de los clientes y de la replicación, y las claves de todas las bases, mientras que el análisis recorre sólo la de la sesión. La cifra más cercana es used_memory_dataset, que descuenta lo fijo, y aun así incluye las demás bases. Con pocas claves la diferencia es enorme; con muchas, la suma se acerca.
Qué anota el registro de comandos lentos de Redis, por qué su umbral va en microsegundos y qué pasa al vaciarlo.
Dónde está: Espacio de Trabajo › Herramientas › Comandos lentos
Aplica a:Redis
El servidor anota cada comando que tarda en ejecutarse más que un umbral (SLOWLOG), y esta pestaña enseña lo que tiene anotado. La duración es la del servidor trabajando: no cuenta la red ni la espera en la cola. La pestaña se relee sola cada 5 segundos mientras está a la vista, y Actualizar relee en el acto.
El umbral va en microsegundos
En Redis el umbral (slowlog-log-slower-than) se escribe en microsegundos, no en los segundos o milisegundos de los otros motores: 10.000 µs son 10 ms, que es el valor con que viene Redis. Arriba, la tarjeta Registro del servidor lo dice en una frase, junto con cuántas entradas guarda (slowlog-max-len, 128 si nadie lo cambió). Un umbral de 0 anota todos los comandos, también los rápidos; uno negativo apaga el registro, y entonces la lista vacía lo dice: no es lo mismo que «ningún comando ha pasado del umbral». En un clúster la tarjeta nombra el nodo: cada nodo lleva su propio registro, y éste es el del nodo del perfil.
Una ventana, no un histórico
El registro guarda sólo las últimas entradas: al llegar una nueva con el registro lleno, sale la más antigua. Lo que se ve es lo que el servidor conserva ahora, no todo lo que fue lento desde que arrancó.
Cambiar los ajustes Cambiar ajustes… abre una hoja con Qué se anota (Lo que pase del umbral, Todo o Nada), Umbral (µs) y Entradas que guarda. Se escribe con CONFIG SET y se vuelve a leer, y lo que se enseña después es lo que dice tener el servidor. No se guarda en su archivo de configuración: un reinicio lo devuelve a lo que diga ese archivo.
La lista
En el Mac es una rejilla con Inicio (reloj del servidor), Duración, Comando y Cliente —ésta sólo si el servidor manda el cliente—, que se ordena pulsando la cabecera. En el iPhone y el iPad es una lista, y el orden se elige en el menú de orden de la barra: Más recientes o Más lentos. El campo Filtrar por comando o cliente filtra lo ya leído, sin volver al servidor. El servidor guarda como mucho 32 argumentos de cada comando y recorta cada uno a 128 bytes, y lo dice dentro del propio comando (... (N more arguments)): Calíope lo enseña tal cual. Un AUTH sale tapado.
El detalle de una entrada
Al elegir una entrada —en el Mac aparece debajo de la rejilla; en el iPhone y el iPad, al tocarla, en una hoja— se ve el comando entero, la hora con su zona (el reloj es el del servidor), la duración en ms y en µs, la dirección y el nombre del cliente, y el número de entrada. Copiar comando lo copia; Abrir en la consola lo deja escrito en la consola, sin ejecutarlo. Los dos están también en el menú contextual, y en el Mac un doble clic o Return abren la consola.
Vaciar Vaciar registro, en la barra, borra todas las entradas del servidor (SLOWLOG RESET). Antes pregunta, diciendo cuántas se van, contadas en ese momento con SLOWLOG LEN. No se puede deshacer.
Quién está conectado al servidor Redis, qué significan conectado, inactivo y las banderas, y qué pasa al desconectar a un cliente.
Dónde está: Espacio de Trabajo › Herramientas › Clientes
Aplica a:Redis
Esta pestaña enseña lo que contesta CLIENT LIST: cada conexión abierta contra el servidor, sea de una aplicación, de redis-cli o del propio Calíope. La lista se relee sola cada 5 segundos mientras está a la vista, y Actualizar la relee en el acto. El campo Filtrar por nombre, dirección o comando filtra lo ya leído —nombre, dirección, último comando, usuario, biblioteca e id— sin volver al servidor. En un clúster la lista es la del nodo del perfil, y un aviso lo dice: cada nodo tiene sus propios clientes.
Las columnas
En el Mac es una rejilla con Cliente, Id, Dirección, Conectado, Inactivo, Base, Último comando, Banderas y Memoria, que se ordena pulsando la cabecera; Usuario y Biblioteca sólo aparecen si alguna conexión los trae (el usuario de ACL existe desde Redis 6; la biblioteca, desde Redis 7.2 y sólo si el cliente se presentó). En el iPhone y el iPad cada cliente es una fila con esos mismos datos rotulados, y el orden se elige en el menú de orden de la barra: Por id, Más inactivos, Conectados hace menos o Más memoria.
Conectado e inactivo no son lo mismo Conectado (age) cuenta los segundos desde que se abrió la conexión; Inactivo (idle), los segundos desde su último comando. La conexión de un pool lleva horas conectada y pocos segundos inactiva; una que lleva mucho tiempo inactiva está abierta sin hacer nada, y aun así ocupa memoria del servidor. Un cliente bloqueado esperando datos —un BLPOP, por ejemplo— también suma inactividad mientras espera, y su último comando lo dice. Memoria (tot-mem) es lo que la conexión ocupa en el servidor, búferes de entrada y salida incluidos.
Las banderas Banderas (flags) va tal cual la escribe el servidor, una letra por bandera. Las más comunes: N, ninguna en particular (una conexión normal); b, bloqueada esperando datos (BLPOP, XREAD BLOCK…); P, suscrita a pub/sub; x, dentro de un MULTI que aún no se ha ejecutado; S, una réplica conectada a este servidor; M, el primario, en la conexión que una réplica tiene con él; y O, un cliente en MONITOR.
Las conexiones de Calíope están en la lista
Calíope también es un cliente, así que sus conexiones salen en la lista, con el nombre Caliope y la biblioteca caliope; su último comando suele ser la propia lectura (client|list). Van marcadas con un glifo y el rótulo Esta sesión, y no se pueden desconectar desde aquí: cerrarlas cerraría la sesión. Calíope las reconoce por su id, no por el nombre: otra instancia de Calíope conectada al mismo servidor se llama igual, y ésa sí es otro cliente.
Desconectar Desconectar… cierra la conexión del cliente elegido (CLIENT KILL ID). Antes pregunta siempre, nombrando al cliente, su dirección, su id y su último comando, y avisando de que lo que tuviera a medias —una transacción, una suscripción o un comando bloqueado— se pierde; se confirma con Desconectar. En el Mac se llega por la barra y por el menú contextual; en el iPhone y el iPad, por el menú contextual y deslizando la fila a la izquierda, que pregunta y no desconecta. Después, la fila se quita en su sitio y un aviso lo dice. El cliente puede volver a conectarse —muchos pools lo hacen solos—, y entonces reaparece en la lectura siguiente con otro id. El menú contextual tiene también Copiar dirección.
Cuando el servidor contesta 0
Si entre la lectura y la confirmación el cliente ya se había ido, el servidor contesta que cerró 0 conexiones. No es un fallo: Calíope dice que ya no estaba conectado y quita la fila.
Cómo se escribe y se lee un comando en la consola de Redis, qué comandos no ejecuta y por qué, y cuáles piden escribir su nombre antes de salir.
Dónde está: Espacio de Trabajo › Herramientas › Consola
Aplica a:Redis
La consola manda a Redis el comando que escribes, por la misma sesión que las demás pestañas. Ejecutar —o Intro— lo ejecuta; en el Mac, Opción+Intro parte la línea sin ejecutarla —un comando largo cabe en varias, y el salto cuenta como un espacio—, y en el iPhone y el iPad la tecla de retorno ejecuta siempre. La línea se parte como en redis-cli: los argumentos van separados por espacios, y las comillas simples o dobles juntan en uno lo que lleva espacios; dentro de comillas dobles valen \n, \t y \xHH. Una comilla sin cerrar no se manda, y la salida dice por qué.
El historial
La flecha arriba recupera el comando anterior cuando el cursor está en la primera línea, y la flecha abajo el siguiente cuando está en la última; los botones Comando anterior del historial y Comando siguiente del historial hacen lo mismo sin teclado. Guarda las últimas 200 líneas, también las que la consola no ejecutó, sin repetir dos iguales seguidas. Limpiar vacía la salida, no el historial. La salida, el historial y lo que esté escrito siguen ahí al cambiar de pestaña y volver.
Cómo se lee una respuesta
- Un estado como OK o PONG sale tal cual.
- Un entero lleva delante (entero).
- Un texto va siempre entre comillas, con los caracteres de control escapados como en redis-cli ("a\r\nb"); el que no es UTF-8 sale en hexadecimal, con su longitud en bytes.
- (nulo) es la ausencia de valor, y no es lo mismo que la cadena vacía, que sale como "".
- Una lista va numerada, y si no trae nada sale (lista vacía). Un mapa —lo que contestan HGETALL o CONFIG GET— va en pares numerados campo => valor. Un conjunto lleva una cabecera que dice cuántos miembros tiene y que no tienen orden, y sus miembros van con viñeta, sin número.
- Un error sale en rojo, con un glifo y (error) delante, y con el prefijo que pone el servidor (WRONGTYPE, ERR…).
- Una respuesta de más de 2000 líneas se corta, y el aviso manda a «Claves», que recorre las claves por páginas.
En un clúster, debajo de cada respuesta se dice quién contestó: el primario de la ranura de la primera clave o, si el comando no lleva clave, el nodo del perfil. Un comando sin clave —DBSIZE, INFO— cuenta sólo lo de ese nodo.
Lo que la consola no ejecuta, y por qué
Cada negativa sale en la salida con su motivo, y el comando no llega al servidor. Debajo, «Lo que no se debe hacer» abre el tema del Manual del DBA que cuenta por qué:
- KEYS recorre todas las claves de una vez y bloquea el servidor mientras dura. Para buscar claves está «Claves», que las recorre con SCAN por páginas.
- MONITOR degrada el servidor mientras dura y no se puede cerrar desde fuera.
- SUBSCRIBE, PSUBSCRIBE y SSUBSCRIBE harían llegar los mensajes del canal mezclados con las respuestas de los demás comandos. Los canales activos y sus suscriptores están en «Servidor».
- SHUTDOWN apaga el servidor.
- DEBUG tiene órdenes que paran o tumban el servidor (DEBUG SLEEP, DEBUG SEGFAULT).
- RESET y HELLO cambian el protocolo por debajo de la conexión que Calíope está usando, y CLIENT REPLY OFF o SKIP dejan de contestar: la orden siguiente esperaría para siempre su respuesta. SYNC y PSYNC convierten la conexión en un enlace de réplica, que recibe todo lo que se escribe en el servidor.
- SELECT dejaría la interfaz enseñando una base y leyendo otra: la base la elige el selector de la herramienta.
- MULTI, EXEC, DISCARD, WATCH y UNWATCH: una transacción vive en una sola conexión, y la consola manda cada línea por la que esté libre, así que las órdenes siguientes podrían ir a otra y la transacción quedaría abierta. Para varias órdenes que se ejecuten juntas, sin nada en medio, está EVAL con un script.
- Un comando que espera un dato —BLPOP, BRPOP, BLMOVE, BZPOPMIN, XREAD … BLOCK, WAIT…— con un tiempo de 0, que es esperar para siempre, o de más de 10 segundos (más de 10000 milisegundos en XREAD BLOCK, WAIT y WAITAOF): mientras espera retiene una de las conexiones que usan todas las herramientas de la sesión. Con un tiempo menor se ejecuta.
Los que piden escribir su nombre FLUSHDB y FLUSHALL borran todas las claves —de la base, o de todas las bases— y no se pueden deshacer; REPLICAOF, SLAVEOF, CLUSTER RESET y CLUSTER FAILOVER cambian la topología, y otros clientes pueden dejar de llegar a sus datos. Para éstos sale una franja sobre el campo que dice qué se va a borrar o cambiar y en qué servidor, con un campo donde se escribe el nombre del comando —sin distinguir mayúsculas— y un botón que no se activa hasta escribirlo. Cancelar lo deja sin enviar, y la salida lo dice.
Todo lo demás se ejecuta, también EVAL, CONFIG SET y CLIENT KILL. Lo que se ejecuta queda en el registro de comandos, con la contraseña de AUTH tapada.
Esta lista vive en el código de Calíope, en un solo sitio, y la consulta todo camino que ejecute un comando escrito por ti: si cambia, este tema cambia con ella.
Qué enseña la topología de una sesión Redis: primarios, réplicas y fragmentos, por qué el retraso va en bytes, qué son las ranuras, qué quiere decir que el clúster falle y por qué Sentinel no está.
Dónde está: Espacio de Trabajo › Herramientas › Topología
Aplica a:Redis
La topología enseña cómo está montado el servidor de la sesión. Con un clúster se ve como Clúster; con un nodo suelto que tiene réplicas, como Nodo suelto con su replicación. Arriba va un resumen: cuántos nodos y cuántos primarios contestan, y los que no contestan, nombrados por su dirección. Debajo, Diagrama dibuja una caja por nodo, agrupadas por fragmento, con el primario arriba y sus réplicas debajo, y Nodos da lo mismo en una tabla. Se relee sola cada 5 segundos mientras está a la vista, y Actualizar la relee en el acto.
El retraso va en bytes, no en segundos
Una réplica de Redis no confirma una hora: confirma hasta qué byte del flujo de replicación ha recibido. Por eso la columna Retraso (bytes) es la posición del primario menos la de la réplica. Calíope lee el primario dos veces, antes de preguntar a nadie y al acabar: lo que avanzó entre las dos lecturas es el suelo, y por debajo de él la réplica sale Al día, porque esa diferencia no se distingue del tiempo que se tarda en preguntar a otra máquina. Sólo por encima sale Atrasada. El lag= que Redis escribe junto a cada réplica en INFO replication es otra cosa: los segundos desde su última confirmación.
Cuando un primario se reinicia empieza un flujo nuevo, y su réplica no tiene retraso medible hasta que vuelve a sincronizarse: la tabla dice En otro flujo de replicación que su primario y el retraso «sin medir (otro flujo)», en vez de enseñar 0 bytes. Si la réplica perdió el enlace con su primario, sale Enlace con su primario caído.
Las ranuras
Un clúster reparte las claves en 16384 ranuras: cada clave cae en una según el CRC16 de su nombre, y cada primario sirve un rango. El número es fijo y pequeño a propósito: el mapa de qué primario sirve cada ranura viaja entre los nodos en cada latido, y tiene que caber en poco. La columna Ranuras dice el rango de cada primario, y el resumen dice cuántas de las 16384 tienen dueño.
Cuando el clúster falla
«Estado del clúster: fail» quiere decir que el clúster ha dejado de aceptar órdenes: hay ranuras sin un primario vivo que las sirva, porque cayó un primario sin réplica que lo sustituya o cayeron varios a la vez. Un nodo que no contesta sale No contesta, con el error técnico al lado, y de él no se afirma nada más: ni su rol ni su retraso.
Sentinel no está
Una sesión abierta contra Sentinel no enseña topología: Sentinel vigila a los primarios y decide el failover, pero no guarda datos ni tiene réplicas propias. Para ver un primario con sus réplicas, abre la sesión contra el primario.
Con VoiceOver, la tabla es la alternativa al diagrama: cada fila se lee una vez, con el nombre de cada columna delante de su valor.
Qué es un reporte de Redis, qué campos tiene y qué le cuesta al servidor: un recorrido de claves en cada ejecución.
Dónde está: Espacio de Trabajo › Herramientas › Reportes
Aplica a:Redis
Un reporte de Redis no lleva consulta: es un recorrido de claves convertido en tabla, con una fila por clave. Se crea con Nuevo reporte en una sesión de Redis, y en vez del editor de texto salen sus campos.
Qué se elige Patrón es un glob sobre el nombre de la clave (app:*, sesion:??, user:[ab]*); vacío son todas. Tipo deja sólo las claves de ese tipo. Columnas enciende key, type, ttl, memory, encoding y length, y salen en el orden en que las enciendes; en Campos de hash cada campo, separado por comas, es una columna más con el valor de ese campo de un hash, vacía en una clave que no es un hash o que no lo tiene. Techo de filas dice cuántas filas como máximo; vacío es el techo del motor.
Lo que cuesta
Cada vez que pulsas Ejecutar, Calíope recorre con SCANtodas las claves que casan con el patrón —en un clúster, en cada primario— y sólo después pregunta por las columnas de las filas que se quedan. El techo recorta las filas, no el recorrido: con un patrón amplio en una base de millones de claves, el reporte tarda aunque pida diez. Detener lo para antes de la siguiente página del recorrido.
La tabla
Las filas salen ordenadas por la clave, así que dos ejecuciones dan la misma tabla; si hay más que el techo se quedan las primeras en ese orden, y la tabla dice que se recortó. memory es lo que contesta MEMORY USAGE: en una colección es una estimación por muestreo. Una clave o un campo que no son UTF-8 salen como 0x… con su longitud, y su columna se marca como binaria.
Parámetros
Un parámetro se escribe $$nombre dentro del patrón y se declara con Declarar parámetros. Su valor se busca tal cual: un * en el valor es un asterisco, no un comodín. Se escribe según su tipo declarado, y un valor que no es de ese tipo se rechaza antes de ejecutar.
Lo demás Exportar lo saca a cualquiera de los formatos del menú, PDF incluido, y Historial guarda cada ejecución, con sus filas o con su fallo. Un reporte de Redis sólo se ejecuta en una sesión de Redis: en otra, la herramienta dice que el reporte no es de esa sesión y no lo deja ejecutar. Programar no sirve con él: sólo se programan reportes de una base relacional, y en cada vuelta el de Redis queda en el historial como Saltado.