ein paar Bemerkungen zu Fragen bzw. Anwendungen, die immer im Vordergrund stehen und eine diesbezügliche Aufgabe zum Chibotko-Diagramm. Ich mache Bemerkungen, wie man das Beispiel gedanklich weiter ausbauen würde, um es noch praxisnäher zu gestalten. Und dann zum Schluss, hinter 4b gibt

es eine Ergänzung, die sich aber darauf bezieht, und zwar gerechnet konkret für dieses umfangreichere Beispiel. Ich diskutiere die Speicherformate Cassandra 2, 3 und im Ausblick auch 4 und insbesondere zu 3, womit wir uns aktuell ja beschäftigen, gibt es intensive Benchmarks, um sich anzugucken, dass die Formeln, die wir aufgestellt haben, auch in der Tat passen und auch

wie sie zu interpretieren sind. Da werde ich dann noch mal auf komprimiert versus nicht komprimiert eingehen. Ein umfangreicheres Beispiel. Szenario. Sie sind jetzt gedanklich einer der vielen Stromnetzbetreiber Deutschlands. Sie könnten sich vorstellen, sie wären Westnetz, zuständig für

diverse Städte und Kreise. Auf der entsprechenden Seite können Sie sich das angucken. Eine Karte gibt es dann und Informationen, die hier unter dem Link zu finden sind, dass ich aus rechtlichen Gründen jetzt hier natürlich nicht anklicken. Können Sie selber machen. Und wir stellen uns einfach noch mal vor, Sie hätten jetzt diese Netzkennzahlen zu verwalten. Jetzt beziehungsweise

Umspannebene steht in der Spalte hier und die jeweilige Anzahl. Höchst- und Hochspannung 839 Netzteile und so weiter bis zur Niederspannung. Das sind dann richtig viele. Nicht Netzteile, sondern Anschlüsse natürlich zu verwalten. Also immerhin mal im Millionenbereich. Lohnt

sich ja schon. Und für einen solchen Netzbetreiber wollen wir Datenmodellierung vorschlagen. Und zwar für zwei Dinge. Für reale Daten, also Messdaten letztlich und technische Daten. Sowohl als auch für Simulationsdaten, die wir für einen gedanklichen digitalen Zwillingen solcher Netze

ja erzeugen könnten. An realen Daten hätten wir beispielsweise technische Daten zu Anschlussstellen und Netzbetriebsmitteln wie den Trafos, Gistdaten, also Daten aus Geoinformationssystemen für die konkrete Lage von Anlagen und so weiter. Einspeiseprofile vorgelagerter Netze. Das sind

Zeitreihen. Netzbetriebsmittel. Schallzustände. Es gibt Sensordaten, also auch wieder Zeitreihen dafür. Lastprofile der Verbraucher. Auch Zeitreihen. Also hier steppt natürlich der Bär. Da können Sie selber überlegen, dass da richtige Datenmengen anfangen können. Entsprechend in der Simulation

hätten Sie Simulationsnetze zu verwalten. Vielleicht pro Stadt bzw. Kreis ein Teilnetz gedanklich. Sie bräuchten die zusammenfassenden Kenndaten, die Netzdetails wie oben im Grunde die technischen Details und dann die Simulationsinputs, also Schallzustände und so weiter. Zeitreihen wieder hier oben. Und die Simulationsergebnisse für Sensordaten, In- und Outputs ebenfalls als Zeitraum.

Entschuldigung, die Inputs und die Outputs, was gebraucht würde, also was reingeschoben wird und was gebraucht würde, wären die Simulationsinputs und die Simulationsergebnisse hätten dann beispielsweise pro Netzknoten detaillierte Angaben zur Spannung und so weiter. Auf den Kanten dann die

Ströme und so weiter. Also da kommt ordentlich was zusammen. Wir werden natürlich jetzt nicht für all das hier Tabellen entwerfen, aber doch zumindest für die zwei Extreme. Aufgabe 1, erstellen Sie einen ersten groben Entwurf für die folgenden vier Tabellen, zumindest für Tabellen T1 und T4,

die zusammenfassenden Kenndaten beziehungsweise die Simulationsergebnisse. Dabei soll T1 mindestens folgende Informationen enthalten, Name der Stadt, Netzebene, Anzahl Anschlüsse, Länge der Leitung. Gedanklich nochmal für die beiden hier dann Aufgabe 2, bewerten Sie diese ersten Entwürfe

hinsichtlich Partitionsgröße, Gesamtspeicherbedarf hochgerechnet und notieren Sie sich die dabei möglicherweise erkannten Probleme. Je nachdem, wie Sie das anstellen, kann es zu Problemen kommen oder auch eben nicht. Und die folgenden Folien sollten Sie erst nach der eigenständigen Bearbeitung

der Aufgaben durchgehen. Sie müssen es mit den Simulationsergebnissen und den Spalten, die Sie dort speichern wollen, nicht übertreiben. Die prinzipiellen Effekte werden Sie sehen, aber sich mit den Zeitstempeln und Messwerten zu beschäftigen, das kommt Ihnen sicher vertraut vor. Das ist ein Ausbaulessnis, was wir schon hatten. Und dann erst gucken Sie sich die folgenden

Folien an. Ich mache hier weiter mit dem Screencast, aber wie gesagt, Sie sollten zuerst einmal erste Entwürfe für die Tabellen bauen, bevor Sie hier reingucken. Hier gibt es jetzt Lösungs-Skizzen für T1 und T4 im ersten Entwurf, wie er bei Ihnen hätte sein können. Die diskutiere ich und nachher

kommen dann auch verfeinerte Entwürfe mit Lösungsmöglichkeiten für erkannte Probleme. Lösungs-Skizze für T1, also diese im Grunde kleine Tabelle, das werden Sie gemerkt haben. Erster Entwurf. Die zusammenfassenden Kenndaten könnten so ausschauen. Ich habe hier mal die

Idee der Stadt ergänzt. Warum? Stadtnamen sind nicht unbedingt eindeutig. Der Primary Key muss eindeutig sein. Das werden Sie gemerkt haben. Wenn nicht, dann sehen Sie es jetzt hier. Das Beispiel Neustadt ist in Deutschland leider real. Neustadt gibt es wirklich mehrfach. Ich habe hier die entsprechenden Netz-Innen nicht hintergeschrieben, haben einfach was ausgewählt, aber das ist ein

ernst gemeintes Problem hier. Wenn Sie also eindeutige Primary Keys haben müssen, Cassandra verlangt das logischerweise, dann werden Sie sich was einfallen lassen müssen und der Klassiker wäre eine Idee zu ergänzen. Eine Zahl, die dann das eine Neustadt vom anderen trennt. Die Anzahl der Anschlüsse ist unterschiedlich, die Länge der Leitung ist unterschiedlich, das sind zwei verschiedene Städte

und so weiter. Dann könnte es in Neustadt in dem einen auch Mittel- und Niederspannung geben als Beispiele mal und so weiter. Wie sieht dann der erste Tabellenentwurf für unsere zusammenfassenden Kenndaten aus? Ich habe mir Spaltennamen überlegt, die enthalten keine Leerzeichen. Wo ich dann

vielleicht eins setzen würde, habe ich einen Unterstrich mal verwendet, um das zu illustrieren. StadtID, Stadtname, Netzebene, Anschlussanzahl, Leitungslänge hier als AE, damit es keinen Stress gibt, je nach System. Und dann überlege ich mich hier Datentypen, Integers, Texts, noch einen Integer und ein Float. Und dann muss ich entscheiden für Cassandra, was Partition Key, was Cluster Key wird.

Und ich sage einfach mal StadtID für den Partition Key, Netzebene für den Cluster Key. StadtID, Netzebene. Ich muss ja irgendwas zum Partitionieren verwenden, dann nehme ich das zu. Und dann noch die Netzebene dabei. Jetzt überlege ich mir Bewertung. Der Primary Key ist gültig aufgrund

der Eindeutigkeit der ID für die Stadt. Sie denken an die Neustadt. Und weil es ja die unterschiedlichen Netzebenen gibt, aber viel mehr Variationsmöglichkeiten gibt es dann eben nicht mehr. Es gibt nicht zweimal Netzebene, aber unterschiedliche Leitungslängen und so weiter und Anschlusszahlen. Also führt das dazu, dass die Tabelle auf jeden Fall gültig ist. Umgekehrt ist

es aber so, dass wenn ich die StadtID zum Partitionieren verwende, es so viele Partitionen wie unterschiedliche Städte gibt. Ich muss Partitionieren in Cassandra. Ich muss hier was reinschreiben. Hier steht StadtID und es ist eben so, so viele StadtIDs wie es gibt, so viele Partitionen gibt es dann. Mal Anzahl des Replikationsfaktors natürlich. Und pro Stadt nach

Netzebene sortieren zu können ist okay, aber man würde auch gerne über alle Städte nach Netzebene filtern können. Kann man zwar abfragen bei so kleinen Tabellen, aber geschenkt. Also es klappt irgendwie technisch schon mal, aber unsere Bewertung ist immer noch Baustellen. Das ist der erste Entwurf. Wir lassen uns nachher vielleicht noch einen zweiten einfallen. Machen wir erstmal

weiter. Lösungskizze für T4, erster Entwurf. Wie könnten die Simulationsergebnisse aussehen? Das erste was man sich überlegt ist, es gibt die Spalte SenID. Das soll eine ID für den konkreten Simulationslauf darstellen. Wichtiges Ergebnis hier. Ich muss die verschiedenen Simulationsläufe

voneinander unterscheiden können. Messdaten kann ich nach dem Zeitstempel, die kommen, unterscheiden. Ich werde ja nicht verschiedene Messdaten für exakt den gleichen Sendung zu exakt den gleichen Zeitpunkt haben, aber das Simulationsmodell kann ich oft laufen lassen. Dann muss ich mir überlegen, wie ich das mache. Simulation wiederholen und andere Einstellungen

gemacht haben. Ich brauche eine ScenarioID und die schreibe ich einfach mal in die Tabelle mit hinein. Dann brauche ich den Zeitstempel. Wir entscheiden uns hier für Jahr, Monat, Tag, Stunde, Minute, Sekunde. Weiter wollen wir erstmal nicht auflösen. Könnte man ja hier tun. Hab ich ja hier im Griff. Was ich dann machen könnte ist eine ScenarioID einzufügen. Eine Zahl, die eindeutig

meinen Sensor identifiziert. Und im Beispiel hätte ich zwei Simulationsergebnisse Active und Reactive Power. Da haben sie vielleicht unterschiedliche Beispiele gewählt. Was soll's? Okay, zur SenID habe ich schon was gesagt. Jetzt gucken wir uns den Primary Key im Vorschlag an. SenID, Year, Month. Wir müssen auf die Größe der Partitionen achten. Wir versuchen es mal

monatlich zu schneiden. Day, Hour, Minute, Second und SensorID. Jetzt überlegen wir uns, ist das eindeutig dank der SenID und der SensorID? Ja, pro Simulationslauf, pro Sensor, Zeitstempel. Das

gibt eindeutig klassifizierbare Zeilen in einer Tabelle. Wo ist jetzt das Problem? Wie groß werden die Partitionen? Welche Probleme sind damit verbunden? Dann müssen wir uns Anzahlen hinschreiben und unser Tool nehmen und mal durchrechnen, was da passiert. Also Versuch 1,

Primary Key wie hierhin geschrieben. Wie groß werden die Partitionen und Probleme diesbezüglich? Nehmen wir doch mal 1000 Sensoren an. Dann rechnen Sie auch die Anzahl der Partitionen und den Gesamtspeicherplatz ohne Replikation mal hoch. Und als Training für die Prüfung rechnen Sie diese Variante und die untenstehenden weiteren am besten per Hand und mit Taschenrechner selbst

und vergleichen mit den Werten auf den folgenden Folien. Machen Sie es mal hier konkret einmal durch. Sie müssen natürlich anahm machen. Ich würde mal sagen, Sie nehmen 1000 Sensoren aber angenommen. Sie kündige Auflösung an. SenID ist erstmal eins. Es gibt auch nur ein unterschiedliches

Jahr und dann können Sie für das Jahr mal durchrechnen. Dafür sind die Werte gemacht. Sie rechnen Sie, halten hier an. Ich mache den Screencast weiter. Ausrechnen per Hand oder mit dem Skript zum Beispiel für diese 1000 Sensoren. Die Anzahl der Sensoren wirkt sich drastisch schon auf nr aus, was ich hier separat ausgegeben habe, was im Milliardenbereich ist. Nv ist viel zu groß.

Also oberhalb dessen ist nicht okay, was Cassandra so will. ST ist gigantisch. Das sind 10,3 mal 10 hoch 5 Megabytes. Das ist zu groß. Auch hier eine Null. Ich hatte zwölf Partitionen. Warum?

Zwölf Monate. Ich hätte gesagt ein Szenario, ein Jahr. Dann sind das hier zwölf Stück, die man im Jahr eben an Partitionen hat. Und dann wären das immerhin im Ganzen aber nur überschaubare 4,5 Terabytes. Das ist noch nicht shocking. Die 2 mal 12, das geht eigentlich noch. Das ist der

Overall Storage in Terabytes. Also die Anzahl der Sensoren wirkt sich drastisch schon auf nr aus. Das ist ein Problem. Ich habe nur 1000 gewählt. Es werden im wahren Leben sicherlich mehr, je nach Beispiel. Die Anzahl der Werte pro Partition ist zu groß. Die Partitionen sind zu groß. Kann man also

im Ganzen knicken. Dabei bedeutet, sollte man noch mal sagen, in Parts die Anzahl der Partitionen ohne Replikation und OS in Terabyte. Der Gesamtspeicherbedarf ohne Replikation eben in Terabytes. Ja, aber so kann ich das nicht lassen. Da müssen wir uns eben was Neues einfallen lassen.