Dazu muss ich ein paar Bemerkungen machen und Benchmarksien dann zeigen, die dann auch zeigen, dass die Formel, die wir verwenden, für den unkomprimierten Tabellenfall gut hinkommen. Ein paar Bemerkungen, die wir jetzt nicht im Detail vorlesen, aber ein paar wichtige Teile vielleicht, die Sie hier finden können.

Es ist mittlerweile so, dass es in Version 3 ich hatte gesagt, die Column Names, also die Inhalte, die Column Names und auch die Inhalte werden nicht für jede Zeile gespeichert. Die werden einmal in den Header gespeichert und dann kann man für eine Zeile in der Tabelle zwei Varianten haben. Dicht und sparse. Dicht heißt, die alle Zellen kommen vor

und werden in den Header geschrieben. Wenn irgendein Wert nicht ausgefüllt wird, dann würde dieser entsprechende Eintrag immer noch ein Byte fressen für den Trenner sozusagen. Im sparsen Falle würde was ähnliches passieren, wie wir es hier gesehen haben. Das angegeben wird wirklich nur, welche Werte irgendwie da sind.

Aber man kann sich hier diesen vorderen Hustle sparen, indem da einfach nur IDs reinkommen. So muss man sich das vorstellen. Das wird automatisch entschieden, wie das aussehen soll. Und was ist dann vielleicht noch wichtig? Ach ja, if a cell has the same timestamp, then it's row. That timestamp is not repeated for the cell.

Und das Gleiche gilt auch für diese Time-to-Live-Daten, die es geben könnte. Timestamps und so weiter sind Delta-encoded. Delta-encoded heißt, dass ich mir pro Partition einen Basiszeitstempel merken kann und dann für die Zeilen des Delta dazu ausrechnen kann. Das sind viel kleinere Werte.

Und sobald ich sowas anfange, könnte ich eigentlich VARINT-encoding betreiben, also Encoding nach Variable-Length. Dieses entsprechende Schema ist RIPE for VARINT-encoding, also RIPE dafür, aber das ist nicht gemacht worden. Könnte es aber.

Und dann kann man sich Benchmarks anschauen. Ich habe Tabellen erstellt, die zur Abwechslung mal bis zu sechs Inhalte haben können, anders als das eine Cons, was wir uns meistens angeguckt haben. Denken Sie an, was hatten wir denn Wirk- und Blindleistung? Drei Phasen hier aufgeteilt, das wären auch sechs Spalten. Also das kann es ja durchaus geben.

Und ich habe etwas Besonderes hier gemacht, was ich sonst nicht tue. Ich habe die Tabellen korrekt konfiguriert, dass wir die Speicherschätzungen auch angucken können, denn sie gelten für den unkomprimierten Fall. Die Kompression, also sowas wie ein SIP

intern über die Daten laufen zu lassen, so ungefähr müssen Sie sich das vorstellen, würde das Ganze möglicherweise noch mal kleiner schieben. Das ist aber schwer vorherzusehen. Deswegen müssen wir, wenn wir die entsprechenden Schätzungen machen, eben für den unkomprimierten Fall rechnen. Es muss sich ja nichts gut komprimieren lassen. So ist es. Und dafür sind entsprechend die Tabellen aber auch konfiguriert, dass wir den direkten Effekt sehen können.

Also komprimiert wären die in unseren Fällen kleiner, aber die Schätzungen können wir nicht gut rechnen. Fürs Folgende merken wir uns, dass diese Tabelle die volle Zeitangabe als Integers in sekündlicher Auflösung hatte. Bevor ich nämlich die zweite Tabelle zeige, müssen wir noch den Primary Key für ein Materialize View ändern, um auch dort

Auswirkungen in der Größe zu sehen. Hier ging es nach Jahr, Monat und Tag. Umgekehrt kann man natürlich wieder das I-House vorweg stellen. Das kennen wir schon. Also nach I-House und Year könnten wir um partitionieren und dafür ist dieser entsprechende Materialize View da mit dem üblichen Grafel.

Nimm bitte alles aus der HMS Tabelle, solange die Eingaben entsprechend nicht Null sind. Trag es ein. Es ist hier die Sending angeordnet, aber das ist für die Größe egal. Und End Compression gleich Enable Doppelpunkt. False wieder. Die Kompression ist auch für den Materialize View ausgeschaltet.

Das muss man übrigens unbedingt bei der Anlage machen. Nachträglich geht das meiner Kenntnis und meiner Versuchen nach nicht. Also direkt bei der Anlage wird das so eingestellt. Bei einer Tabelle selber könnte man es wohl nachträglich machen, aber wahrscheinlich nicht bei den Materialize Views. Geht es naheliegend nicht und wahrscheinlich geht es auch gar nicht.

Darum direkt. Gut, wie gesagt, nun haben wir jetzt den Zeitstampel etwas verändert. Nur ein Integer statt Hour, Minute, Second. Sack of Day einfach nur. Und wir nehmen I-House hier, dann ist zu, dann gedanklich. Dann haben wir nämlich ein NC von 2 und nicht mehr von 4.

Weil Hour, Minute weg sind. Sack of Day ist uminterpretiert. Seconds für den entsprechenden Tag. Kompression ist wieder ausgeschaltet. Nach Jahr, Monat, Tag wird partitioniert. In dem anderen wird es nach I-House und Year Materialize View partitioniert. Und dann habe ich die beiden Tabellen, Sets fertig.

Mit einem größeren, mit einem etwas kleineren Cluster Key und je mit Materialize View. Dann können wir an die Größenordnungen gehen. Wie macht man das? Wie rechnet man jetzt mit diesen Tabellen? Die Tabellen werden schrittweise gefüllt und dann immer wieder beobachtet, was

mit der Speichergröße passiert. Und Achtung, nachdem Werte übertragen wurden, muss man die entsprechende Größe der Data Subdirectories mal summieren. Dann sollte man allerdings im Bindverzeichnis von Cassandra das Node Tool verwenden, um zu kompaktieren. Und danach wieder die Größe der Data Subdirectories

summieren lassen. Warum machen wir das? Damit man sieht, was Cassandra bei erzwungenen Aufräumarbeiten denn dann für eine Größe hat. Sonst sammelt sich da einiges an, was erst beim nächsten Update-Zeitpunkt von Cassandra bearbeitet würde. Und das wollen wir für die Benchmarks natürlich direkt dann entsprechend sehen.

Wie kann man die Größe der Data Subdirectories summieren lassen? Dafür gibt es Windows Befehle, die einem das erledigen. Sonst müsste man es eben mit der Hand machen. Aber es gibt eine entsprechende Sammlung von Tools, für die ich hier aber keine Werbung mache. Die sind frei über die Windows-Seite erhältlich, die einem das erledigen könnten.

Sonst müsste man das eben mit dem Datei Explorer erledigen. Um Daten zu füllen, nimmt man das vor Cassandra HTWDT 10 Houses und kann es unterschiedlich auflösen oder spalten hinzutun. Um das umzuwandeln in Sack of Day, schreibt man ein kleines Skript, um die entsprechenden Daten zu

transferieren. Also aus dem Beispiel-Datensatz, den wir verwendet haben, kann man sich die anderen nötigen Formate selber erzeugen. Das werde ich jetzt hier nicht weiter detaillieren, aber das ist naheliegend, wie man das macht. Und dann benutzt man den Copy-Befehl am einfachsten, um in die Tabelle hinein zu tun. Der Witz ist jetzt, dass man die Daten so aufbereitet.

Es gibt nur eine Messdatenspalte. Nachgegebenenfalls erfolgter Anpassung des Zeitstempels, dieser Umrechnung in Sack of Day, kann ich dann diesen einen Wert im Grunde reinschreiben, wenn die Spalte der neuen Tabelle, wie ich sie haben will. Ich habe Cons1 bis Cons6 und ich kann einfach mit Cons1 anfangen.

Also über die CQLSH werden Daten nur für eine Wertespalte übertragen und das mache ich über diesen Copy-Befehl, in dem ich sage, wo rein die Daten, die in dieser Datei hier stehen, reingetan werden sollen, wie die interpretiert werden sollen. Ich muss also mit dem Copy-Befehl nicht unbedingt alle meine Spalten in der

Tabelle füllen. Ich kann das auch partiell machen und das nutze ich ja aus. Das ist natürlich nichts realistisches, dass man so die Daten rein hätte. Die kämen anderweitig reingeschrieben, aber für den Effekt der Größe reicht das natürlich locker als Test. Danach wird die Größe angeschaut, wir kompaktieren, Größe wird wieder angeschaut und dann machen wir das gleiche.

Ab hier, mit Cons2 bis Cons6 und so weiter und so fort und sammeln die Größen zusammen. Das machen wir natürlich für die mal gucken, für die SAC-of-Data-Tabelle und das machen wir auch für die andere Tabelle, die HMS-Tabelle, analog mit entsprechend produzierten Daten.

Genau das gleiche und dann gucken wir uns die resultierenden Größen der Data-Sub-Directories an. Die kann man dann visualisieren. Das ist der gemessene Speicherbedarf umgerechnet in Megabytes. Also hier maximal, das sind 250, dann sind es hier bei 300, 350, 400, etwas über 400 Megabytes maximal

für Cons1, Cons2, Cons3, Cons4, Cons5, Cons6, jeweils nach der Kompaktierung. Der Speicherbedarf wächst erwartungsgemäß lineal, die Materialized Views sind hier etwas größer als die Original und es war klar, dass SAC-of-Day

erwartungsgemäß etwas Platz gegenüber HMS einspart. Es hat weniger Cluster Key-Einträge. Zwei Spalten für den Zeitstempel sind ja weg. Für den Overhead ist das relativ egal, wie lange der Cluster Key ist, weil es ja nur um den Zeitstempel geht, aber Sie müssen ja bedenken, die entsprechenden

Werte werden ja auch gespeichert. Vielleicht sehen Sie es im Overhead nicht, wie lange der Cluster Key ist, wie viel Spalten er hat, aber Sie sehen es natürlich, wenn Sie die Tabellenwerte anhand Ihrer Datenlängen wegspeichern.