Diese Seite beschreibt Calíope 1.7, die Version, die ich gerade baue. Die 1.6 ist im App Store für Mac, iPad, iPhone, Apple Watch, Apple TV und Apple Vision Pro. Das Changelog sagt, in welcher Version jede Funktion kam.
Fügt jedem Thema einen Button „In Calíope öffnen“ hinzu. Funktioniert nur mit installierter App.
Wie du CQL ausführst, welche Konsistenzstufe du wählst, wie Seiten und Trace ankommen, was Stoppen tut und was CQL nicht hat.
Wo es zu finden ist: Workspace › Werkzeuge › CQL-Abfrage
Gilt für:CassandraScyllaDB
Die CQL-Abfrage schickt dem Server, was du tippst, über die offene Sitzung. Ausführen (⌘↩) führt den ganzen Text Anweisung für Anweisung aus, oder nur die Auswahl, wenn es eine gibt. Ein BEGIN BATCH … APPLY BATCH geht als Ganzes, und ein ; in einem Literal, einem $$…$$-Block oder einem Kommentar trennt nicht. Die erste Anweisung, die fehlschlägt, hält die übrigen an, und der Fehler sagt, welche es war („Anweisung 2: …“). Ein USE wechselt den Keyspace der Sitzung, und die Leiste zeigt es.
Die Konsistenzstufe
Jedes Datum liegt auf mehreren Replikaten, und die Konsistenzstufe sagt, wie viele antworten müssen, bevor der Server antwortet. Du wählst sie in Konsistenz, und sie gilt für alles, was du danach ausführst:
- LOCAL_ONE, die Voreinstellung, wartet auf ein Replikat im lokalen Rechenzentrum: Das ist am schnellsten, und ein Lesevorgang sieht einen frischen Schreibvorgang womöglich noch nicht.
- ONE, TWO und THREE warten auf so viele Replikate, wo auch immer sie sind.
- QUORUM wartet auf die Mehrheit der Replikate, LOCAL_QUORUM auf die Mehrheit im lokalen Rechenzentrum und EACH_QUORUM auf die Mehrheit in jedem. Ein Schreib- und ein Lesevorgang mit QUORUM treffen sich immer auf irgendeinem Replikat.
- ALL wartet auf alle und schlägt fehl, sobald eines ausgefallen ist.
- ANY gilt nur fürs Schreiben, und SERIAL und LOCAL_SERIAL sind für leichtgewichtige Transaktionen (IF NOT EXISTS, IF …).
Gibt es nicht genug lebende Replikate, antwortet der Server mit einem Fehler, der sagt, wie viele nötig waren und wie viele es gab. Lösung anzeigen führt zum Kapitel des DBA-Handbuchs, das den Fehler erklärt: zu dem über Konsistenz bei diesem oder einer Zeitüberschreitung, zu dem über Rollen und Berechtigungen bei einem Unauthorized und zu dem über häufige Fehler bei den übrigen, die es erklärt, auch einem Syntaxfehler.
Die Seiten
Ein SELECT kommt seitenweise an, und Zeilen pro Seite legt fest, wie viele Zeilen jede Seite anfordert: 200, solange du es nicht änderst. Nächste Seite holt die nächste, solange der Server sagt, dass es mehr geben kann; manchmal kommt die letzte leer an, und dann steht es da: „Es gibt keine weiteren Zeilen.“.
Der Trace
Ist Tracen an, hält der Server fest, wo jede Anweisung vorbeikam, und die Fußzeile trägt den Link zu ihrem Trace.
Was du siehst
Das Raster schreibt jeden Wert wie cqlsh, und der Kopf jeder Spalte trägt ihren Typ. Die Ansicht JSON führt ein SELECT erneut als SELECT JSON aus und zeigt, was der Server liefert; für andere Anweisungen gibt es kein JSON. Warnungen des Servers erscheinen in einem Streifen, „Serverwarnungen“: Cassandra warnt zum Beispiel bei einem count(*) ohne Partitionsschlüssel, ScyllaDB nicht. Die Fußzeile nennt die Zeilen, die Zeit und wie viele Anweisungen liefen.
Was schreibt INSERT, UPDATE, DELETE, TRUNCATE, CREATE, ALTER, DROP, GRANT, REVOKE und ein BATCH laufen zuerst durch den Schutz der Umgebungsmarkierung der Sitzung, der eine Bestätigung verlangen kann. Ein Schreibvorgang meldet „Angewendet. CQL meldet nicht, wie viele Zeilen geschrieben wurden.“: Das Protokoll gibt nicht zurück, wie viele Zeilen er berührt hat.
Stoppen
Während sie läuft, hört Stoppen (⌘.) auf, auf die Antwort zu warten, und die Verbindung bleibt offen. Aber das Protokoll kann auf dem Server nichts abbrechen: Was begonnen hat, beendet der Server. Ein gestopptes UPDATE kann angewendet worden sein.
Was CQL nicht hat
Es gibt kein EXPLAIN und keine Transaktionen über mehrere Anweisungen: Ein protokolliertes BATCH wird ganz oder gar nicht angewendet, isoliert aber niemanden, der währenddessen liest, und der Trace ist das, was einem Plan am nächsten kommt. Eine Abfrage, die nicht nach dem Partitionsschlüssel filtert, lehnt der Server ab, es sei denn, sie trägt ALLOW FILTERING, was ihn zwingt, alle Partitionen zu lesen: Bei einer großen Tabelle ist das teuer, und die Antwort ist fast immer eine andere Tabelle mit einem anderen Schlüssel.
Der Schemabaum, woher die DDL kommt, die Zeilenstichprobe und was sich per Primärschlüssel bearbeiten lässt und was nicht.
Wo es zu finden ist: Workspace › Werkzeuge › Keyspaces
Gilt für:CassandraScyllaDB
Der Explorer liest system_schema und zeigt jeden Keyspace mit seinen Tabellen, materialisierten Views, Typen, Indizes, Funktionen und Aggregaten. Ein Keyspace wird gelesen, wenn du ihn aufklappst oder wählst, nicht alle auf einmal, und eine leere Kategorie wird nicht gezeichnet. Nach Name filtern filtert den Baum nach Namen. Die Keyspaces, die dem Server selbst gehören (system*, und audit in ScyllaDB), stehen zuletzt, zugeklappt, unter „Keyspaces des Servers“.
Der Partitionsschlüssel
In Cassandra hat der Primärschlüssel zwei Teile. Der Partitionsschlüssel entscheidet, auf welchen Knoten jede Zeile liegt: Zeilen mit demselben Partitionsschlüssel liegen zusammen, und eine effiziente Abfrage gibt ihn vollständig an. Die Clustering-Spalten ordnen die Zeilen innerhalb der Partition, in der Reihenfolge, die die Tabelle deklariert (ASC oder DESC). Der Rest sind reguläre Spalten, und eine statische speichert einen Wert pro Partition, nicht pro Zeile. Struktur zeigt jede Spalte mit ihrer Rolle, ihrer Position und ihrer Reihenfolge, den vollständigen Primärschlüssel und die Eigenschaften der Tabelle.
DDL
Die DDL schreibt der Server: Sie wird mit DESCRIBE angefordert, das Cassandra und ScyllaDB für Keyspace, Tabelle, View, Typ, Index, Funktion und Aggregat akzeptieren, und das Panel sagt, dass sie von dort kommt. Die einer Tabelle bringt ihre Indizes und Views mit. Akzeptiert ein Server kein DESCRIBE, wird die DDL aus system_schema rekonstruiert, und auch das sagt das Panel; Funktionen und Aggregate werden nicht rekonstruiert. DDL kopieren kopiert sie vollständig.
Zeilen
Die Stichprobe liest 100 Zeilen pro Seite, ohne WHERE und ohne ALLOW FILTERING, in der Reihenfolge, in der der Server die Partitionen durchläuft – das ist nicht die Einfügereihenfolge. Nächste Seite holt die nächste, und Zeilen neu laden fängt von vorn an. Token der Partition anzeigen fügt die Spalte token() hinzu, die Zahl, die entscheidet, auf welchem Knoten jede Partition landet, und Schreibzeit und TTL von fügt writetime und ttl einer regulären Spalte hinzu: wann der Wert geschrieben wurde, in Mikrosekunden, und wie viele Sekunden ihm bis zum Ablauf bleiben. Das gilt nicht für eine Schlüsselspalte, einen Zähler oder eine nicht eingefrorene Collection.
Zeilen bearbeiten Zeile einfügen… über dem Raster und in jeder Zeile das Menü „…“ mit Zeile bearbeiten… und Zeile löschen… schreiben immer über den ganzen Schlüssel, Partition und Clustering, und mit einer leichtgewichtigen Transaktion: Einfügen ist INSERT … IF NOT EXISTS, ein schon vorhandener Schlüssel wird also nicht ersetzt; Speichern ist UPDATE … IF EXISTS und Löschen DELETE … IF EXISTS, und wenn die Zeile nicht mehr auf dem Server ist, wird es gesagt. Beim Speichern wird nur geschrieben, was sich geändert hat, und Kein Wert (null) leert die Zelle. Was du eintippst, wird vor dem Senden in den Typ umgewandelt, den der Server deklariert: Datum und Uhrzeit in UTC (2026-01-31 10:00:00), ein Blob hexadezimal (0x…), eine Dauer wie 1h30m und eine Dezimalzahl mit Punkt oder Komma. Nach dem Schreiben wird die Zeile neu gelesen und ändert sich an Ort und Stelle, ohne die Seite neu zu laden. Die Löschwarnung nennt den ganzen Schlüssel.
ScyllaDB
In ScyllaDB 2025.1 erlaubt ein Keyspace mit Tablets keine leichtgewichtigen Transaktionen, und das Speichern schlägt mit der Meldung des Servers fehl („LWT is not yet supported with tablets“). Ein mit AND tablets = {'enabled': false} angelegter Keyspace wird wie in den anderen Versionen bearbeitet.
Was hier nicht bearbeitet wird
Eine Collection, ein UDT, ein Tupel, ein custom-Typ und eine statische Spalte werden in der CQL-Abfrage geändert, und das Blatt sagt es. Ebenso wenig bearbeitet werden eine Zählertabelle, die nur Addieren oder Subtrahieren erlaubt, ein Keyspace des Servers oder eine Tabelle, deren Schlüssel einen Typ hat, der sich nicht in einer Zeile schreiben lässt. Es gibt kein TRUNCATE und kein Löschen per Filter: Dafür ist die CQL-Abfrage da. Bei einem Umgebungsetikett mit „schreibgeschützt“ wird nichts gezeichnet, was schreibt, und bei einem mit „bestätigt Schreibzugriffe“ fragt die Schutzfunktion vor jedem Schreiben.
Welche Knoten er zeigt und woher sie kommen, was der Ringanteil ist, woran man einen ausgefallenen Knoten erkennt und was nodetool überlassen bleibt.
Wo es zu finden ist: Workspace › Werkzeuge › Cluster
Gilt für:CassandraScyllaDB
Der Cluster zeigt die Knoten, die der Knoten kennt, mit dem die Sitzung verbunden ist, der Koordinator: seine eigene Zeile aus system.local und die seiner Peers, aus system.peers_v2 in Cassandra (oder system.peers, wenn es sie nicht gibt) und aus system.peers in ScyllaDB. Die Peers werden nichts gefragt: Was man sieht, ist das, was der Koordinator über sie weiß. Oben stehen der Name des Clusters, der Partitioner, wie viele Knoten laufen – die übrigen einzeln mit Namen – und ob alle dieselbe Schemaversion melden; wenn nicht, hat eine Schemaänderung noch nicht alle erreicht.
Der Ring
Cassandra und ScyllaDB verteilen die Daten auf einen Ring aus Tokens: Jede Zeile landet auf dem Token, den ihr Partitionsschlüssel ergibt, und jeder Knoten besitzt die Abschnitte, die an seinen Tokens enden (die Spalte Tokens sagt, wie viele er hat). Ringanteil ist der Teil des Rings, den die Tokens jedes Knotens abdecken, ohne Replikate, derselbe Wert, den nodetool status für einen Keyspace mit Replikationsfaktor 1 zeigt. Ohne Keyspace zeigt nodetool den effektiven Anteil, der die Kopien mitzählt: bei drei Knoten und Faktor 3 je 100 %. Er wird nur mit Murmur3Partitioner berechnet, dem Standard-Partitioner; bei jedem anderen bleibt die Spalte leer, und der Hinweis sagt es.
Status
In ScyllaDB kommt der Status aus system.cluster_status. In Cassandra kommt er aus system_views.gossip_info, und das hat einen Haken: Ein Knoten, der geordnet herunterfährt, verabschiedet sich und erscheint als Ausgefallen, aber einer, der ohne Abschied abstürzt, bleibt NORMAL. Deshalb wird zweimal gelesen, ein paar Sekunden auseinander, und wenn sein heartbeat nicht weitergezählt hat, erscheint er als Ausgefallen: kein Heartbeat. Ein Knoten, der beitritt, austritt oder umzieht, erscheint im Übergang, mit dem Wort des Servers. Und ein Peer, für den der Koordinator keine Statuszeile hat, ist Unbekannt: Von einem Knoten, den man nicht sehen konnte, wird nicht behauptet, er sei ausgefallen. Jeder Status trägt sein Symbol und seinen Namen, nicht nur eine Farbe.
Aktualisieren
Nichts wird von selbst neu gelesen, denn jede Lesung wartet diese Sekunden, um den Heartbeat zu messen: Neu gelesen wird mit Aktualisieren. Scheitert eine Lesung und gab es vorher eine, bleibt die alte stehen, mit dem Hinweis, dass sie nicht aktuell ist.
Die Version in ScyllaDB
Die Peers von ScyllaDB melden eine Kompatibilitätsversion zu Cassandra, nicht ihre eigene: Die Spalte zeigt die des Koordinators, gelesen aus system.versions, und ein Hinweis sagt es.
Was es hier nicht gibt
Die Replikation von Cassandra ist der Ring selbst und wird in diesem Tab gezeigt: Einen eigenen Replikatmonitor gibt es nicht. Der Cluster liest nur: Was Aufgabe von nodetool ist – reparieren, aufräumen, einen Knoten stilllegen oder verschieben, Snapshots –, von JMX oder von der REST-API von ScyllaDB, bleibt außen vor.
Was der verbundene Knoten über sich selbst sagt –Version, Caches, Compactions, Festplatte, Latenzen und Einstellungen–, woher es in jedem Produkt kommt und was nodetool überlassen bleibt.
Wo es zu finden ist: Workspace › Werkzeuge › Knoten
Gilt für:CassandraScyllaDB
Der Knoten zeigt, was der Knoten, mit dem die Sitzung verbunden ist, über sich selbst sagt, gelesen aus seinen virtuellen Tabellen: system_views in Cassandra und die Tabellen von system in ScyllaDB. Alles gehört zu diesem Knoten: Die Peers werden nichts gefragt, und in einem Cluster hat jeder Knoten seine eigenen Caches, Compactions und seine eigene Festplatte. Um einen anderen zu sehen, muss sich die Sitzung mit ihm verbinden.
Oben Version ist die des Servers: die aus system.local in Cassandra und die aus system.versions in ScyllaDB, die seine eigene ist und nicht die Kompatibilitätsversion zu Cassandra. Danach folgt eine Karte pro Cache, mit Trefferquote, Anzahl der Einträge und wie viel seiner Kapazität er belegt: in Cassandra die Schlüssel-, Zeilen- und Zähler-Caches aus system_views.caches; in ScyllaDB der Zeilen-Cache aus der Gruppe cache von system.runtime_info. Ein Cache mit Kapazität 0 ist in der Serverkonfiguration ausgeschaltet –der Zeilen-Cache von Cassandra wird so ausgeliefert–, und die Karte sagt es. Laufende Compactions zählt die, die gerade laufen: In Cassandra kommen sie aus system_views.sstable_tasks, mit ihrem Fortschritt; in ScyllaDB aus system.compactions_in_progress, das keinen Fortschritt liefert, aber sagt, wie viele SSTables hineingehen. Gibt es welche, erscheint darunter ihre Tabelle.
Die Abschnitte
Darunter steht eine Tabelle pro Abschnitt, und jedes Produkt erklärt seine eigenen: Was der Server nicht veröffentlicht, wird nicht gezeichnet.
- Threadpools (nur Cassandra, system_views.thread_pools): die aktiven, wartenden und blockierten Aufgaben jedes Pools. Wartende und blockierte sagen, ob der Knoten hinterherkommt.
- Latenz pro Tabelle (nur Cassandra, coordinator_read_latency und coordinator_write_latency): p50 und p99 für Lesen und Schreiben, in Millisekunden. Es ist die Latenz, die dieser Knoten als Koordinator der Anfragen sieht, die er erhält, nicht die seiner Replikate.
- Größe pro Tabelle: in Cassandra der Speicherplatz aus system_views.disk_usage, auf ganze MiB aufgerundet; in ScyllaDB die Schätzung aus system.size_estimates, pro Tabelle summiert, die einer Tabelle, deren Daten noch nicht auf die Festplatte geschrieben wurden, 0 gibt und die Tabellen einschließt, die ScyllaDB für Indizes und für leichtgewichtige Transaktionen (…$paxos) anlegt, weil sie wirklich Platz belegen.
- Große Partitionen: in Cassandra die größte Partition jeder Tabelle aus system_views.max_partition_size; in ScyllaDB nur die, die beim Compacten den Schwellenwert des Servers überschritten haben, aus system.large_partitions, leer ist also normal.
- Compaction-Verlauf: die 100 jüngsten Compactions aus system.compaction_history, mit dem, was sie gelesen und geschrieben haben, und daneben die Gesamtzahl.
- Laufzeitwerte: die Zähler, die der Server veröffentlicht, mit ihrem Namen: system_views.cql_metrics in Cassandra und system.runtime_info in ScyllaDB, das auch angibt, wie lange er schon läuft, so wie der Server es schreibt.
- Einstellungen: die Konfiguration, mit der der Knoten läuft, aus system_views.settings in Cassandra und aus system.config in ScyllaDB, das zusätzlich sagt, woher jeder Wert kommt. Einstellungen filtern grenzt die Liste nach Namen ein.
Größe, Partitionen und Latenzen lassen die Keyspaces des Servers weg; der Verlauf nicht. Lässt sich ein Abschnitt nicht lesen, wird gesagt, welcher und warum, und die anderen laufen weiter.
Aktualisieren
Nichts wird von selbst neu gelesen: Neu gelesen wird mit Aktualisieren. Schlägt ein Lesevorgang fehl und gab es vorher einen, bleibt der vorherige sichtbar, und es wird gesagt, dass er nicht aktuell ist.
Was hier nicht ist
Der Knoten liest nur. Was Aufgabe von nodetool ist –Memtables leeren, eine Compaction starten oder anhalten, die Protokollstufe ändern, Indizes neu aufbauen–, von JMX oder der REST-API von ScyllaDB, bleibt außen vor, und eine Einstellung wird nicht hier geändert: Sie wird in der Konfiguration des Servers geändert.
Welche Verbindungen der verbundene Knoten offen hat, mit welchem Benutzer, Treiber, Protokoll und TLS, welche zu Calíope gehören und warum sie hier nicht getrennt werden.
Wo es zu finden ist: Workspace › Werkzeuge › Clients
Gilt für:CassandraScyllaDB
Clients zeigt die offenen Verbindungen des Knotens, mit dem die Sitzung verbunden ist, so wie der Knoten sie selbst veröffentlicht: system_views.clients in Cassandra und system.clients in ScyllaDB. Nur die dieses Knotens: Jeder Knoten veröffentlicht seine eigenen, und die, die ein Client mit einem anderen Knoten des Clusters offen hat, erscheinen hier nicht. Um sie zu sehen, muss sich die Sitzung mit diesem Knoten verbinden.
Die Spalten
- Client: Adresse und Port, von denen die Verbindung kommt, mit dem Hostnamen darunter, wenn der Server ihn kennt und er nicht die Adresse selbst ist.
- Benutzer: der Benutzer, mit dem sie sich angemeldet hat.
- Treiber: Name und Version, die der Treiber beim Verbinden angegeben hat. cqlsh stellt sich in Cassandra als „DataStax Python Driver“ und in ScyllaDB als „ScyllaDB Python Driver“ vor und öffnet zwei Verbindungen: eine Steuerverbindung und eine weitere für die Abfragen.
- Protokoll: die Version des nativen Protokolls, die die Verbindung ausgehandelt hat.
- TLS: ob die Verbindung verschlüsselt ist und, wenn der Server es sagt, mit welcher TLS-Version.
- Phase: die Phase der Verbindung, so geschrieben, wie der Server sie schreibt (ScyllaDB in Großbuchstaben: READY).
- Anfragen und Keyspace (nur Cassandra): wie viele Anfragen die Verbindung gestellt hat und der verwendete Keyspace, der einen Strich zeigt, wenn sie kein USE ausgeführt hat.
- Shard (nur ScyllaDB): der Shard des Knotens, der die Verbindung bedient.
Eine Spalte, die ein Produkt nicht veröffentlicht, wird nicht gezeichnet, und ein Wert, den der Server nicht liefert, zeigt einen Strich.
Calíope
Die Verbindungen von Calíope tragen ihre Markierung –ein Symbol und den Namen Calíope, nicht nur eine Farbe– und stehen vorn; die übrigen folgen nach Adresse und Port. Calíope stellt sich dem Server mit dem Namen „Caliope“ vor, und daran werden sie erkannt: Markiert werden alle der App, die dieses Fensters und die jedes anderen Geräts, auf dem Calíope mit demselben Knoten verbunden ist, denn die Adresse reicht nicht, um zu wissen, welche zu diesem Fenster gehört (hinter einem Tunnel oder einem NAT kommen alle von derselben).
Filtern Nach Adresse, Benutzer, Treiber filtern… grenzt die Tabelle nach Adresse, Port, Hostname, Benutzer, Treiber und seiner Version, Keyspace oder Phase ein, und die Zusammenfassung sagt, wie viele von allen angezeigt werden.
Aktualisieren
Die Liste wird nicht von selbst neu gelesen: Neu gelesen wird mit Aktualisieren. Schlägt ein Lesevorgang fehl und gab es vorher einen, bleibt der vorherige sichtbar, und es wird gesagt, dass er nicht aktuell ist.
Was hier nicht ist
Clients liest nur. Calíope trennt niemanden, denn CQL hat keine Anweisung, um die Verbindung eines anderen Clients zu schließen, und die Fußzeile des Tabs sagt es. Das bleibt nodetool, JMX oder der REST-API von ScyllaDB überlassen.
Wie man einen Trace von Cassandra oder ScyllaDB liest, was jedes Produkt zusätzlich veröffentlicht –die langsamen Abfragen von ScyllaDB, was gerade in Cassandra läuft– und wie man das Log langsamer Abfragen von ScyllaDB einschaltet.
Wo es zu finden ist: Workspace › Werkzeuge › Traces
Gilt für:CassandraScyllaDB
Traces zeigt, was der Server über die Anfragen aufzeichnet, die er tracen soll, und was jedes Produkt zusätzlich veröffentlicht: langsame Abfragen in ScyllaDB und das, was gerade in Cassandra läuft. Die Tabs hängen vom Produkt ab, und ein Tab, den ein Produkt nicht hat, wird nicht gezeichnet.
Getracte Sitzungen (beide)
Ein Trace ist das, was der Koordinator und jedes Replikat beim Bedienen einer Anfrage aufgezeichnet haben. Der Server speichert ihn in system_traces.sessions (eine Zeile pro Anfrage) und system_traces.events (eine pro Schritt). Getract wird nur, was man anfordert: Schalte Tracen in der CQL-Abfrage vor dem Ausführen ein, und die Fußzeile des Ergebnisses bringt eine Taste mit der Kennung des Traces, die ihn direkt hier öffnet. Traces verfallen nach 24 Stunden.
Die Liste zeigt die neuesten Sitzungen. In ScyllaDB werden sie über ihren Zeitindex (sessions_time_idx) gesucht, rückwärts ab der Uhrzeit des Servers, und die Gesamtzahl wird nicht gelesen. Cassandra hat diesen Index nicht: Die Tabelle wird bis zu einer Obergrenze gelesen und hier sortiert, und wenn das Lesen die Obergrenze erreicht hat, sagt es der Bildschirm, denn es kann neuere geben, die nicht gelesen wurden. In ScyllaDB schreibt jede langsame Abfrage auch ihre Sitzung, sodass die Liste mehr enthält als die, die du tracen lassen wolltest.
Die Uhrzeit jeder Zeile (Beginn) öffnet ihren Trace: Beginn, Dauer, Befehl, Koordinator, Client, den Benutzer (nur ScyllaDB zeichnet ihn auf) und, wenn der Server sie aufzeichnet, die Konsistenzstufe; die Anweisung, mit In der CQL-Abfrage öffnen; und die Ereignisse der Reihe nach. Jedes Ereignis nennt Vergangen –die Mikrosekunden, die sein Knoten schon mit der Anfrage beschäftigt war–, einen Balken proportional zu dieser Zeit, die Aktivität, Knoten und den Thread. Zwei Knoten teilen keine Uhr: Die Zeit jedes Ereignisses ist die seines Knotens, und zwei Knoten über diese Spalte zu vergleichen führt in die Irre.
Der Server schreibt den Trace, während die Anfrage noch läuft: Ein gerade angeforderter Trace kann ohne Ereignisse oder mit der Dauer nicht beendet ankommen. Beim Öffnen wird er einige Male im Abstand von einer halben Sekunde neu gelesen, bis er seine Dauer mitbringt; kommt sie nicht, wird es gesagt, und es genügt, ihn ein paar Sekunden später mit Aktualisieren neu zu lesen. Zurück zu den getracten Sitzungen führt zur Liste zurück.
Langsame (nur ScyllaDB)
ScyllaDB zeichnet in system_traces.node_slow_log jede Abfrage auf, die einen Schwellenwert überschreitet, mit Beginn, Dauer, Anweisung, Tabellen, Benutzer sowie dem Knoten und dem Shard, die sie bedient haben. Gesucht werden sie über node_slow_log_time_idx, aus den letzten 24 Stunden. Die Uhrzeit öffnet den Trace dieser Abfrage –ScyllaDB schreibt einen für jede langsame Abfrage–, und die Taste am Ende der Zeile bringt sie in die CQL-Abfrage.
Das Log ist ab Werk ausgeschaltet, und weder der Schwellenwert noch ob es eingeschaltet ist, lässt sich per CQL lesen: Beides gehört zur REST-API von ScyllaDB (Port 10000). Deshalb zeigt der Tab den neuesten Eintrag und den kürzesten der gelesenen, das Einzige, was CQL wissen lässt. Um es mit einem Schwellenwert von 500 µs einzuschalten (der Schwellenwert ist in Mikrosekunden), und um seinen Zustand zu lesen:
curl -X POST "http://<knoten>:10000/storage_service/slow_query?enable=true&threshold=500"
curl http://<knoten>:10000/storage_service/slow_query
Der zweite liefert etwas wie {"enable": true, "ttl": 86400, "threshold": 500, "fast": false}. Es wird Knoten für Knoten eingeschaltet, steht nicht in scylla.yaml, und ein Neustart des Knotens schaltet es aus. Calíope erledigt das nicht für dich, weil es nur CQL spricht: Die REST-API ist die Verwaltungstür von ScyllaDB, getrennt von CQL und meist von außerhalb des Clusters nicht erreichbar, und was Sache von nodetool, JMX oder der REST-API ist, bleibt draußen.
Laufend (nur Cassandra)
Was gerade auf dem Knoten der Sitzung läuft, aus system_views.queries: der Thread, Wartend und Laufend in Mikrosekunden und die Anfrage. Das Lesen dieser Liste ist eine davon, und jeder Knoten veröffentlicht nur seine eigenen. Cassandra veröffentlicht seine langsamen Abfragen nicht per CQL: Es schreibt sie ab slow_query_log_timeout in sein Textlog, und die Fußzeile nennt diesen Wert so, wie der Knoten ihn hat.
Aktualisieren
Nichts wird von selbst neu gelesen: Der Tab wird mit Aktualisieren neu gelesen, und die Leiste sagt, wann das letzte Lesen war. Schlägt ein Lesevorgang fehl und gab es vorher einen, bleibt der vorherige sichtbar, und es wird gesagt, dass er nicht aktuell ist.
All das liest nur: Die Traces und das Log langsamer Abfragen schreibt der Server, und sie verfallen von selbst.
Was eine Rolle in Cassandra oder ScyllaDB ist, woher Liste und Detail kommen, auf welchen Ressourcen Berechtigungen erteilt werden, was geschrieben wird und wie das Passwort reist, und warum es ohne Authentifizierung keine Rollen gibt.
Wo es zu finden ist: Workspace › Werkzeuge › Rollen
Gilt für:CassandraScyllaDB
Rollen zeigt die Rollen des Servers und was jede darf, und lässt sie anlegen, ändern, ihnen Berechtigungen erteilen und sie löschen.
Was eine Rolle ist
Eine Rolle ist zugleich ein Benutzer und eine Gruppe. Wenn sie Darf sich anmelden und ein Passwort hat, meldet sich jemand mit ihr an; sonst bündelt sie Berechtigungen und wird anderen Rollen erteilt, die erben, was sie hat. Eine Rolle als Superuser darf alles, auch wenn die Liste nicht jede Berechtigung nennt, und das Detail sagt es.
Ohne Authentifizierung keine Rollen
Rollen gibt es nur, wenn der Server beim Verbinden Benutzer und Passwort verlangt (PasswordAuthenticator). Mit AllowAllAuthenticator, womit Cassandra und ScyllaDB ausgeliefert werden, kommt jeder ohne Anmeldedaten hinein und es gibt nichts zu verwalten: Der Tab sagt es mit seinem Grund und fragt den Server nichts, der mit einem Fehler antworten würde.
Liste und Detail
Die Liste kommt aus LIST ROLES, in beiden Produkten gleich: der Name, Superuser, Darf sich anmelden und, nur in Cassandra, Rechenzentren. Der Filter grenzt nach Namen ein. Wenn Sie eine Rolle wählen, zeigt das Detail Eigene Berechtigungen aus LIST ALL PERMISSIONS OF; getrennt davon Geerbt von den Rollen, denen sie angehört, jede mit der Rolle, von der sie kommt; und Gehört zu aus LIST ROLES OF. Geerbtes wird hier nicht entzogen: Es wird bei der Rolle entfernt, von der es kommt, oder die Rolle wird aus dieser Gruppe genommen.
Ressourcen und Berechtigungen
Eine Berechtigung wird auf einer Ressource erteilt: Alle Keyspaces, Ein Keyspace, Eine Tabelle, Alle Rollen, Eine Rolle oder Alle Funktionen. Die Berechtigungen sind ALL PERMISSIONS, SELECT, MODIFY, CREATE, ALTER, DROP, AUTHORIZE, DESCRIBE und EXECUTE; Cassandra kommt mit SELECT_MASKED und UNMASK für maskierte Spalten dazu, die ScyllaDB nicht hat. Nicht jede Berechtigung gilt für jede Ressource, und der Server lehnt ein unsinniges Paar mit seiner eigenen Meldung ab.
Was geschrieben wird Neue Rolle… legt eine Rolle mit Namen, Passwort und der Angabe an, ob sie Darf sich anmelden oder Superuser ist; ohne Passwort kann sich die Rolle auch mit LOGIN nicht anmelden. Ändern… schickt nur, was Sie ändern (ALTER ROLE); Cassandra lässt das Passwort einer Rolle nicht zweimal innerhalb von 5 Sekunden ändern. Berechtigung erteilen… erteilt eine Berechtigung auf einer Ressource, und Zu einer Rolle hinzufügen… die Mitgliedschaft in einer anderen Rolle; der Knopf am Ende jeder Zeile entzieht sie. Rolle löschen… löscht die Rolle mit ihren Berechtigungen und Mitgliedschaften. Etwas zu entfernen —löschen oder entziehen— fragt vorher nach einer Bestätigung, die die Rolle nennt.
Alles, was schreibt, geht über den Schutz der Verbindung: Mit einem schreibgeschützten Umgebungsetikett wird nichts gezeichnet, was schreibt, und mit einem, das bestätigt, fragt jede Änderung, bevor sie gesendet wird.
Das Passwort
CQL lässt das Passwort nicht getrennt senden: Es reist in der Anweisung (CREATE ROLE … WITH PASSWORD = '…') zum Server, der es als Hash speichert und nicht im Klartext. Im Netz ist es nur verschlüsselt, wenn die Verbindung TLS nutzt. Im Befehlsprotokoll bleibt die Anweisung mit verdecktem Passwort.
Aktualisieren
Nichts lädt sich von selbst neu: Die Liste wird mit Aktualisieren neu gelesen, und die Leiste sagt, wann zuletzt gelesen wurde. Schlägt ein Lesen fehl und gab es ein früheres, bleibt das frühere stehen, und Sie erfahren, dass es nicht das aktuelle ist.
Stichwörter: cassandra, scylladb, rollen, rolle, berechtigungen, benutzer, grant, revoke, create role, alter role, drop role, list roles, superuser, login, passwort, authentifizierung, passwordauthenticator, allowallauthenticator
Was ein CQL-Bericht ist: ein einziges SELECT mit :name-Parametern, vorbereitet und nach dem Typ jeder Spalte gebunden, das alle Seiten bis zur Obergrenze liest.
Wo es zu finden ist: Workspace › Werkzeuge › Berichte
Gilt für:CassandraScyllaDB
In einer Cassandra- oder ScyllaDB-Sitzung legt Neuer Bericht einen CQL-Bericht an: sein Text ist eine einzige SELECT-Anweisung, und er beginnt mit SELECT * FROM demo.productos LIMIT 100. Eine andere Anweisung —ein INSERT, ein USE—, zwei Anweisungen oder ein ? ohne Namen werden abgelehnt, bevor etwas an den Server geht.
Parameter
Ein Parameter wird als :name in den Text geschrieben und mit Parameter deklarieren deklariert. Calíope ersetzt jedes :name durch ? und bereitet die Anweisung vor: Der Server nennt den CQL-Typ jedes Platzhalters, und der Wert wird nach diesem Typ geschrieben, nie in den Text. Eine uuid geht als uuid, ein decimal exakt, ohne Gleitkomma; ein Wert, der nicht zu seiner Spalte passt, wird mit dem Namen des Parameters abgelehnt. Zählt der Server eine andere Zahl von Platzhaltern als Parameter, schlägt der Bericht fehl und nennt beide Zahlen.
Was gelesen wird
Jedes Mal, wenn du Ausführen drückst, liest Calíope alle Seiten des Ergebnisses, je 200, bis zur Zeilenobergrenze des Berichts, und sagt, wenn gekürzt wurde. Stoppen hält ihn zwischen einer Seite und der nächsten an. Die Spaltentypen kommen aus dem, was der Server über das Ergebnis meldet: Ganzzahlen, decimal, float und double als Zahlen, timestamp als Datum und Uhrzeit in UTC, date als Datum, blob als binär und boolean; Collections, benutzerdefinierte Typen, uuid und inet erscheinen so, wie cqlsh sie schreibt.
Der Rest
Was ein Bericht liest, bleibt nicht im Befehlsprotokoll: Es ist ein Lesen des Werkzeugs, keine Anweisung aus der CQL-Abfrage. Exportieren und Verlauf funktionieren wie bei jedem Bericht. Ein CQL-Bericht läuft nur in einer Cassandra- oder ScyllaDB-Sitzung, nimmt kein Skript aus mehreren Anweisungen an, und Planen hilft bei ihm nicht: Nur Berichte auf einer relationalen Datenbank lassen sich planen.