Cassandra GUI-Client

[am2]

Etwas OT, aber ein neues Thema dafür zu eröffnen ist m.E. ein Overkill...

Erstmal danke für das Aufzeigen von Cassandra. Ich war (und bin es noch) SQL-Datenbänker. Nach MSSQL kam Postgres, dazwischen war etwas MySQL und jetzt wollte ich mir einfach mal Cassandra anschauen, weil ich neugierig wurde. Nun denn, es ist tatsächlich interessant aber kann mir jemand ein gebrauchsfähiges (Linux-) GUI für Cassandra 2.1.15 empfehlen? So'ne Art PgAdmin für Cassandra? Bis jetzt finde nur kostenpflichtige Sachen, das freie cassandra-gui.jar funzt leider nicht, alle Angebote durchzuprobieren ist mir dann doch etwas zu viel... Ich mag die Konsole, aber Übersicht ist dann doch etwas anderes, wie z.B. im PgAdmin. Kennt jemand 'was?

[TRex]

Etwas OT, aber ein neues Thema dafür zu eröffnen ist m.E. ein Overkill...

Sah ich anders. Verschoben aus dem Postgres-HA-Thread.

[am2]

OK. Danke.

[r4pt0r]

Ich hatte in meinem Testcluster das Datastax OpsCenter benutzt für grundlegendes Monitoring und Management der Nodes. Mehr als in der community-Version braucht man m.E. für nen kleinen Cluster ja auch nicht - DB-Operationen führt man per API oder connector aus der eigenen Applikation/Scripte aus oder schlimmstenfalls manuell per cql-cli-tool.

Ansonsten gibt es auch noch den Cassandra Cluster Admin: https://github.com/sebgiroux/Cassandra-Cluster-Admin
Nie selbst ausprobiert, aber der hat wohl ne komplette GUI inkl buntem CQL-Interpreter.

[am2]

Mache ich da was falsch oder muss man sich bei Datastax registrieren um das OpsCenter (Enterperise) herunterzuladen?

Was ein Cluster für Cassandra ist muss ich noch begreifen aber Cassandra läuft bei mir in der VM auf einem Ubuntu-Server-14.04. Ich habe schon einige erste Schritte gemacht, bin aber immer noch verwirrt. Es kommt aber noch.

Was muss ich denn von github herunterladen? Die zip-Datei? Die darin enthaltene cassandra-gui.jar tut's bei mir nicht (Connection failed).

Sorry für diese Fragerei, aber ich tappe wirklich noch im Dinkeln....

[r4pt0r]

Die Enterprise-Version ist mit einem Supportvertrag (subscription) verbunden, die Community-Edition bringt aber alles mit was man für kleine Cluster benötigt bzw was dort sinn macht. Selbst das deployment/upgrade von cassandra lässt sich darüber managen.

Unter debian ist es am einfachsten die datastax-repos einzubinden und direkt die fertigen Pakete zu installieren.
Genaue Vorgehensweise ist sehr ausführlich im DataStax devcenter in den jeweiligen Dokumentationen beschrieben:
Cassandra: http://docs.datastax.com/en/cassandra/3 ... llDeb.html
OpsCenter: http://docs.datastax.com/en/opscenter/5 ... Deb_t.html

Für eine grundlegende Einführung kannst du dich am besten durch die einzelnen Punkte oben in der Navigation arbeiten (auch die dokumentation auf planetcassandra.org ist sehr ausführlich). Für Cassandra ist absolut essentiell, dass man dessen grundlegende Architektur und Funktion versteht. Cassandra ist KEINE relationale Datenbank und darf auf keinen Fall als solche behandelt werden - sonst schießt man sich ziemlich schnell ins Knie. Das Datenmodell muss auf die Architektur von Casssandra angepasst werden; die Denkweise muss völlig umgestellt werden wenn man von RMDBs kommt! Es gibt z.b. keine joins, die Daten _müssen_ denormalisiert und bereits für die queries optimiert abgelegt werden.
Auch das Verhältniss zwischen Konsistenz, Verfügbarkeit und Partitionierungs-toleranz (CAP-Theorem) muss man Verstehen und an den Einsatzzweck anpassen, sonst wundert man sich mindestens über seltsames Verhalten bei Abfragen oder sogar über (massiven) Datenverlust.
Sehr informativ ist dazu auch die Analyse zu Cassandra im Jepsen-Projekt: http://jepsen.io/analyses.html

Ich hatte mir als Einführung für ein kleines Projekt (das aus Zeitmangel auf Eis liegt) "Learning Apache Cassandra" von Mat Brown und "Cassandra Data Modeling and Analysis" von C.Y. Kan geholt; beide von Packt Publishing. Die gab (gibt?) es dort bzw bei o'reilly etwas günstiger zusammen im bundle. Speziell das zweite fand ich sehr hilfreich - mit gut entworfenen Datenmodellen werden die queries erheblich einfacher und damit die Applikation wesentlich schlanker und performanter.
Eine Teilekatalog-Datenbank mit ca 800t Teilenummern, mehreren hundert Modellcodes, -varianten und Positions-/Katalognummern und entsprechend mehreren mio. Kombinationen aus allem konnte ich in 3 denormalisierte Formen übersetzen, die praktisch alle benötigten Abfragevarianten abdecken. Performance ist um Magnituden über jeder relationalen Variante und der kleine Cluster aus damals 3 Nodes (relativ kleine VMs) hatte kaum wirkliche Last: beim Füttern der Datenbank war der bremsende Faktor das skylake i7 6700 System auf dem das Umwandlungsscript lief - was aber egal war, da die Daten mit ~300k rows/sec in knapp 8 minuten im Cluster waren


Ich würde zuerst eine Testinstallation mit einem Node zum lernen der Grundlagen empfehlen, dann erst einen Cluster mit OpsCenter. Für Tests kann alles in VMs auf dem selben System liegen sofern genug RAM vorhanden ist - jeder Cassandra-Node und das OpsCenter laufen in je einer eigenen JVM die mindestens 2-3GB RAM benötigt (und nach mehreren Stunden garbage-collecting locker 4-5GB belegt...). Je nach verfügbarere Hardware ist daher ggf ein single-Node Cluster sinnvoller, wenn man sich nicht mit kaum reproduzierbaren Fehlern durch akuten Speichermangel herumschlagen will.
Für nen einzelnen Cassandra-Node braucht man auch kein OpsCenter, das ist absolute Ressourcenverschwendung - die gesamte Interaktion mit Cassandra geschieht sowieso wie schon geschrieben per cqlsh zum testen, lernen und rumprobieren oder mit einem der vielen db-connectors für die (script-)sprache der Wahl. Für perl gibts z.b. einen 'nativen' und einen für Perl-DBI (mittlerweile vermutlich sogar mehr).

[am2]

Danke für die ausführliche Erklärung und die Links.

Zum Abschnitt 3:
So weit bin ich schon und irgendwo begann an einem dieser Punkte die Faszination. Ich habe auch etwas Literatur von Packt und arbeite mich da langsam durch. Es ist jedoch nicht so groß wie dein Teile-Katalog. Eine Adventure Works wäre nicht schelcht, die hatte ich überall, die kennt man auch.

Bei mir läuft alles in einer VM, die ich übrigens heute in den Sand gesetzt habe. Rückstellung zum letzten Schnappschuss hat alles zerschossen. Egal, shit happens. Dass da Java zum Einsatz ist mir allerdings ein Greuel, als Linuxer ist man eher C gewohnt, wie bei Postgres. Da wird kein Müll gesammelt sondern mit z.B. free() sofort entsorgt. Aber egal, es läuft (wieder)...

[r4pt0r]

Bester Rat zur JVM: einfach komplett die Finger davon lassen und nix versuchen zu optimieren. Auch Java-spezifische Optionen in der config von cassandra einfach bei den defaults belassen (wie eigentlich fast alle Einstellungen).
Zumindest als Java 7.x "aktuell" war gab es zudem einige bugs mit OpenJDK, da mittlerweile ausdrücklich auch OpenJDK 8.0 in der Dokumentation genannt wird, dürfte sich das aber erledigt haben.
Einfach nur schauen, dass genug RAM (4GB+) zur Verfügung steht und gut is. Ggf ist auch ein Container oder eine VM auf basis von alpine linux (https://alpinelinux.org) sinnvoller - das ist nicht so extrem überladen (vermüllt... ) wie ubuntu und ist speziell für den Einsatz in Virtualisierten umgebungen entwickelt. Spart also Platz, Ressourcen und Zeit beim deployment und der Fehlersuche, weil weniger dazwischenpfuschen kann.

Man muss allgemein bei Cassandra nichts hinter den Kulissen schrauben (oder gar am Java-Code) - am besten/einfachsten nutzt man sowieso fertige containerimages bzw defaultinstallationen/tarballs und behandelt diese container/vm/server dann so weit wie möglich als "stateless". Wenn man ganz paranoid ist baut man sich aus nem minimalimage + tarball selbst das image. Deployment und die nötigste Konfiguration per config-management (ansible, puppet, chef...) erledigen und nur die userdaten (=inhalt der DB) als Einzigartig behandeln. Niemals manuell in nem container rumwerkeln - das führt die eigentliche Idee eines Containers (oder seit neuestem "microservice") wieder ad absurdum.
Zum einen erleichtert das größere (release-)upgrades, zum anderen wird der übergang vom test- zum produktivbetrieb und auch das desaster-recovery erheblich vereinfacht, da system+dienst vollständig reproduzierbar und ersetzbar sind - Stichwort "pets vs cattle". Auch backup wird damit wesentlich einfacher: ein DB-dump reicht, das configmanagement liegt sowieso im cvs/subversion/git repository o.ä. und wird separat gesichert.

Cassandra reagiert (wie alle verteilten systeme) extrem empfindlich auf Zeitabweichungen (commitlog, tombstones, "last write wins" etc!) - das kann auch der Grund dafür gewesen sein, dass das zurücksetzen dir die DB zerlegt hat (?). Am besten einen ntp-server/pool für alle Systeme nutzen und beim system/containerstart einen abgleich erzwingen bevor cassandra gestartet wird, auch wenn der bootvorgang dann 3sek länger dauert, aber dann tauchen solche Probleme nicht auf. Bei verteilten Systemen in mehreren Zeitzonen nutzt man am besten überall UTC und keine Lokalen Zeitzonen, das erspart auch Hirnverrenkungen bei der Fehlersuche (-> timestamps in logdateien...).

[am2]

JVM habe ich noch nie angefasst, Cassandra wurde nur IP- und Host-technisch an die Gegebenheiten angepasst. Ich habe das JDK 8 aus der Cassandra-Doku, es scheint OK zu sein. Ubuntu(-Server) sind überladen (vermüllt), sagst du? Wieso? Sie laufen bis jetzt problemlos auf sehr leisen Sohlen, es sei denn man fordert sie. Alpinelinux werde ich jedenfalls ausprobieren. Ressourcen schonen ist immer erstrebenswert. Basiert alpine auch auf Debian? Das würde die Sache einfacher machen...

Weißt du, wie man bei Cassandra 3.6 JMX aktiviert? Vielleicht geht es dann mit dem Java-Client.

Ich muss aber auch sagen, dass ich nicht unbedingt alles begreife, was du mir mitteilst. Ich bin eben kein großer Deployer, kein Super-Admin. "Meine" MSSQL Datenbank hat 221 Tabellen mit 10 bis 100 Spalten, folgt zu 90-95% der 3. Normalform, ist sehr gut zu handhaben und hat (je nach Kunde) eine Größe zw. einigen Hundert MB und 10 GB.

Verteilte Systeme? Ich weiß, dass es sie gibt. ntp/pool, Abgeleich erzwigen??? Nicht so schnell, bitte Die zurückgesetzte VM hat es so zerschossen, dass nur noch Trümmer eines OS da waren. Das hat mit temporärer Anomalie nicht das geringste zu tun, denke ich. Workstation kann das eigentlich ganz gut mit den Snapshots aber dann doch nicht zu 100%. Vielleicht war der Snapashot hinüber obwohl er korrekt angezeigt wurde. Sch... egal, ich bin beim Wiederaufbau.

UTC ist bei meiner Cassandra schon fest verankert und lässt sich nicht vertreiben. Wir wollen es so belassen. Übrigens, meine Lern-DB ist sehr klein, überall die absolut notwendige Anzahl von Spalten (wg. der Keys), 5 bis 20 Datensätze. Es reicht für den Anfang und wie weit soll man denn nach 3-4 Tagen sein? Mir reicht z.Zt. SimpleStrategy und replication_factor:1.